Developing Software with Security in Mind

Scott BlomquistCTO, Vidoop

FormatThis 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.

Rule #11.Learn about security or it will teach you.

How my security education beganJuly 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

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

Security trendsTools, 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?

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

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.

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

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.

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

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

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

Emergency response plans

• How to know when to respondo Web products and boxed products are different.

• How to disseminate the responseo Everyone needs an update process.o Sometimes you need damage control levers, too.

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

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

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

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.

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

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:o Userso Researchers

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

No rule #10

• Security is unpredictable.• Be ready for anything.

Additional Resources

More information about Microsoft's security turning point• Inside Windows XP SP2• Inside the Windows Security Push

Questions?

Slides available at http://Scott.Blomqui.st