The document discusses core security principles for developers, including the three pillars of security (confidentiality, integrity, availability), common vulnerabilities like buffer overflows and injection flaws, security mindsets and architectures, and tools for testing applications. It provides an overview of the OWASP top 10 security risks and recommends resources for further learning about secure coding practices.

1. Break it while you make it writing (more) secure software Leigh Honeywell HackLab.to [email_address] http://twitter.com/hypatiadotca

2. About Me Co-Founder and Board Member of HackLab.TO

3. Advisor to the SecTor Security Conference

4. U of T student

5. Malware Operations Engineer at a major anti-virus vendor (who I am not speaking as a representative of)

6. Why I'm here To talk about the core security principles developers need to know

7. To get you thinking like the people who will try to break your app

8. To show some nifty tools

9. Maybe to scare you a little?

10. To get you breaking your own apps :)

11. #3hotsecurewords There are three core “pillars” of information security: Confidentiality

12. Integrity

13. Availability

14. Confidentiality Only allow access to data for which the user is permitted.

15. The user may not be permitted anything!

16. Sometimes called secrecy or privacy

17. There are real consequences for failing at this – PIPEDA, HIPAA, PCI-DSS, and various other acronyms.

18. Integrity Ensure data is not tampered with or altered by unauthorized users.

19. Availability Ensure systems and data are available to authorized users when they need it.

20. Without this, the others don't matter.

21. Anyone remember Friendster?

22. Vulnerabilities

23. Vulnerabilities A vulnerability is an error made in a program, causing unintended behavior of the program in a way that affects security negatively. FIRST defines a vulnerability as: “a bug, flaw, weakness, or exposure of an application, system, device, or service that could lead to a failure of confidentiality, integrity, or availability.”

24. Vulnerabilities Examples of vulnerabilities: Weak passwords

25. Insecure permissions

26. Directory traversal

27. Buffer overflows

28. Cross-site scripting and request forgery

29. Exploits

30. Exploits An exploit is a specific example of triggering a vulnerability. If the vulnerability is a missile, the exploit is the warhead.

31. Exploits Examples of exploits: Morris Worm Almost everything at http://www.milw0rm.com/ http://www.example.com/displayfile.php?../../../../etc/passwd

32. Exploits Easy way to think about it: If typing “ perl –e ‘print “A” x 10000; ” makes it crash, you’ve found a vulnerability If you end up with this, you’ve got a working exploit: bash-3.00# id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest), 45(utmp)

33. The Security Mindset How many security features are there in a grocery store self-check-out?

34. How can you break each of them?

35. What did they forget to think of?

36. Bruce Schneier on the mindset: http://tinyurl.com/2sj365

37. The Security Mindset How many of you opened that tinyurl? What if I'd just dropped a Firefox 0-day on you?

38. I didn't, don't worry. That would get me fired.

39. This is why I suck at programming

40. Finding Balance “Not all "harmless failures" lead to big trouble, but it's surprising how often a clever adversary can pile up a stack of seemingly harmless failures into a dangerous tower of trouble. Harmless failures are bad hygiene. We try to stamp them out when we can.” – Ed Felten, Freedom to Tinker http://preview.tinyurl.com/c6ewzv

41. Security Architecture The OWASP Secure Coding Principles puts it thus: “ Security architecture starts on the day the business requirements are modeled, and never finish until the last copy of your application is decommissioned. Security is a life-long process, not a one shot accident.” http://www.owasp.org/index.php/Secure_Coding_Principles

42. Right from the Start When starting a new application or re-factoring an existing application, you should consider each functional feature, and consider: Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?

43. If I were evil, how would I abuse this feature?

44. Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature?

45. (also from OWASP)

46. Security in the Bones Software design, as well as implementation, must consider the three pillars of information security. Otherwise, you're going to fail.

47. 10 Principles Minimize attack surface area Establish secure defaults Least privilege Defense in depth Fail securely Don’t trust services Separation of duties Avoid security through obscurity Keep security simple Fix security issues correctly The OWASP guide gives 10 principles for writing secure code:

48. 10 Principles Minimize attack surface area

49. Give the attacker the absolute minimum possible to work with when trying to discover an attack. By reducing complexity of an application, the number of possible vulnerabilities is also reduced.

50. Establish secure defaults

51. If a variable level of security is desired, have the default be high, and leave it up to the user to make the decision to lower it. This prevents “out of the box” insecurities.

52. 10 Principles Least privilege

53. Any component of a system should have only as much privilege as necessary to function properly. This is best known for permissions on user accounts, but also applies to software components.

54. Defense in depth

55. Adding on more security methods is a good thing, but they must approach the problem in different ways.