Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Insecurity in Information Technology - Full Length Version


Published on

A lot is expected of software developers these days; they are expected to be experts in everything despite very little training. Throw in the IT security team (often with little-to-no knowledge of how to build software) telling developers what to do and how to do it, and the situation is further strained. This silo-filled, tension-laced situation, coupled with short deadlines and mounting pressure from management, often leads to stress, anxiety and less-than-ideal reactions from developers and security people alike. This talk will explain how people's personal insecurities can be brought out by leadership decisions in the way we manage our application security programs, and how this can lead to real-life vulnerabilities in software and other IT products. This is not a soft talk about "feelings", this is a talk about creating programs, governance and policies that ensure security throughout the entire SDLC. No more laying blame and pointing fingers, it's time to put our egos aside and focus on building high-quality software that is secure. The cause and effect of insecurities and other behavioural influencers, as well as several detailed and specific solutions will be presented that can be implemented at your own place of work, immediately. No more ambiguity or uncertainty from now on, only crystal clear expectations.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Insecurity in Information Technology - Full Length Version

  1. 1. Insecurity in Information Technology Tanya Janca OWASP Ottawa Chapter Leader OWASP DevSlop Project Leader @SheHacksPurple
  2. 2. The “I’m Qualified” Slide Tanya Janca: Application security evangelist, web application penetration tester and vulnerability assessor, trainer, public speaker, ethical hacker, OWASP Ottawa chapter leader, OWASP DevSlop project leader, effective altruist, software developer since the late 90’s. I’m extremely concerned about application security, and you should be too. Let me tell you more. About Me
  3. 3. Thesis: People make stupid decisions when they feel insecure. Conflict between security and development makes some people (employees) feel insecure. When this happens, insecure software is often the result. Changes are required to solve this problem.
  4. 4. Warning: This is not a talk about “feelings”. This talk is about the bottom line, getting the job done, and making software secure. However, it might get uncomfortable at times. Try not to feel too defensive.
  5. 5. The Fine Print: Although I relay all examples in the first person, as though I was there, these are not all my personal examples. They are from multiple members of the InfoSec community.
  6. 6. Talk Outline: • Problem(s) • Solution(s)
  7. 7. Problem: The way many IT shops are run can create feelings of job insecurity in employees.
  8. 8. Security testing is performed so late in the game that developers 1) Don’t fix anything 2) Resent security for presenting last minute challenges
  9. 9. • Do security testing without the security team, making them feel unrequired. • Don’t cooperate with the security team to enable security testing, claiming they have no time/implying security is low priority. • Ignore security advice from security reports and do not implement any or most of the mitigations. • Do not take/ask for advice from the security team. Developers
  10. 10. The security team quotes policies at developers, or sends them an unvalidated 500 page report. Security
  11. 11. • Does not give usable security guidance to the developers when asked. • Acts or is seen as a gate, slowing down the SDLC. • Adds project requirements without explanation, “because security”. • When revealing issues, they make developers feel incompetent. Security Team
  12. 12. All of this creates the feeling of insecurity about people’s jobs and how to do them well. This leads to: • deviant behaviour, • moral disengagement, • reduced job involvement, • risk taking behavior, and • reduction of organizational citizenship behavior (positive workplace activity and involvement).
  13. 13. All of this bad behavior leads to insecure software. Is everyone on board with this? Questions? Are we on the same page? More examples?
  14. 14. The Plan: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Repair relationship. 3. Do not accept ‘bad’ behavior anymore.
  15. 15. 1
  16. 16. 1 Start Security Earlier! Requirements Design Code Testing Release Pushing Left, Like a boss!
  17. 17. 1
  18. 18. 1
  19. 19. 1
  20. 20. 1
  21. 21. 1
  22. 22. 1
  23. 23. 1 Break security testing into smaller pieces
  24. 24. 1-2
  25. 25. 1-2
  26. 26. 1 Provide free training to developers 1-2
  27. 27. 2
  28. 28. 2
  29. 29. 2
  30. 30. 2 Job Shadowing
  31. 31. Give Developers Security Tools! 2
  32. 32. 2
  33. 33. OWASP: Your new BFF The Open Web Application Security Project 2
  34. 34. 3
  35. 35. 3
  36. 36. 3
  37. 37. 3
  38. 38. No more “we’re screwed” keynotes. A message for conferences
  39. 39. Summary: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Repair relationship. 3. Do not accept ‘bad’ behavior anymore.
  40. 40. Tanya Janca OWASP Ottawa Chapter Leader OWASP DevSlop Project Leader @SheHacksPurple ANY QUESTIONS?