The document outlines 10 rules for developing software with security in mind. The rules are: 1. Learn about security or it will teach you the hard way through vulnerabilities. 2. Security knowledge becomes obsolete quickly, so keep learning. Have a security expert on your team. 3. Befriend security researchers and let them test your software for vulnerabilities. 4. Expect to ship software with security bugs despite your best efforts. 5. Have security response plans to quickly address issues that arise. 6. Security and usability will always be in tension so aim for good, not perfect. 7. Have open conversations about security with users and researchers to build trust. 8. There may

1. Developing Software with Security in Mind Scott Blomquist CTO, Vidoop

2. Format This session is: 10 useful rules for developing with security in mind Not just mine: feel free to interrupt at any time This session isn't: A talk about specific security pitfalls, development techniques, etc.

3. Rule #1 Learn about security or it will teach you.

4. How my security education began July 2001: Code Red slows corporate networks to a crawl September 2001: Nimda does it again February/March 2002: Windows Security Push January 2003: This time it's Slammer Summer 2003: Work begins on "Springboard" August 2003: Blaster terrorizes the world

5. Rule #2 Learn about security or it will teach you. Security knowledge goes obsolete quickly.

6. Security trends Tools, languages, development practices get better Static analysis tools Safer versions of C run-time functions Input fuzzing tools Stack attack detection So do the badguys Tools advances may help them, too New techniques are discovered all the time ALL: favorite examples of either of these?

7. Rule #3 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more).

8. Passions get the best attention Security geek doesn't have to be a full-time job. You might already work with one (or might be one). To get started, you just have to make it a point to read about and talk about security. With luck, it will just "fit" for someone.

9. Rule #4 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more). Befriend the security researchers in your field.

10. Security researchers: symbiotic parasites We have great local resources here in Tulsa. Spend time poking holes in your project over coffee or beer. Suggest exciting research projects. Make sure they know how to reach you if they have an interesting thought. Despite how bad it feels when a flaw in your project gets published, you want them to find the flaw.

11. Rule #5 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more). Befriend the security researchers in your field. Despite knowledge, you will ship security bugs.

12. Software is never defect-free No one would claim to be unbreakable (okay, except Oracle) But many projects sure act like they are.

13. Rule #6 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more). Befriend the security researchers in your field. Despite knowledge, you will ship security bugs. Have security response plans in place.

14. Emergency response plans How to know when to respond Web products and boxed products are different. How to disseminate the response Everyone needs an update process. Sometimes you need damage control levers, too.

15. Rue #7 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more). Befriend the security researchers in your field. Despite knowledge, you will ship security bugs. Have security response plans in place. Security and usability will always be in tension.

16. Secrity vs. Usability "The most secure computer in the world is in a concrete and steel vault, protected by armed guards, and not plugged in to the network or even power. But it's not very useful, either." --Various

17. Rule #8 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more). Befriend the security researchers in your field. Despite knowledge, you will ship security bugs. Have security response plans in place. Security and usability will always be in tension. The perfect is the enemy of the good.

18. A case study: OpenID First, what is OpenID: OpenID According to Dave Many OpenID objections center around how it doesn't solve as many problems as pick-your-favorite-heavy-crypto-based-auth-protocol. Despite those strong objections, OpenID is poised to be an Internet phenomenon.

19. Rule #9 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more). Befriend the security researchers in your field. Despite knowledge, you will ship security bugs. Have security response plans in place. Security and usability will always be in tension. The perfect is the enemy of the good. Have open conversations about security.

20. Open conversation You want to know at least as much about your security as everyone else. Sometimes conversations will be uncomfortable, but you have to learn and your users have to be reassured about their future with your software. Who to talk to: Users Researchers

21. Rule #10 Learn about security or it will teach you. Security knowledge goes obsolete quickly. Your team should have a security geek (or more). Befriend the security researchers in your field. Despite knowledge, you will ship security bugs. Have security response plans in place. Security and usability will always be in tension. The perfect is the enemy of the good. Have open conversations about security. Sometimes there is no rule #10.

22. No rule #10 Security is unpredictable. Be ready for anything.

23. Additional Resources More information about Microsoft's security turning point Inside Windows XP SP2 Inside the Windows Security Push

24. Questions? Slides available at http://Scott.Blomqui.st