Which Secure Software Development Practices do you Employ?

Question

I work on a project known as the Security Development Lifecycle (SDL) project at Microsoft (http://microsoft.com/sdl) - in short it's a set of practices that must be used by product groups before they ship products to help improve security.

Over the last couple of years, we have published a great deal of SDL documentation, as customers ask for more information about what we're doing.

But what I'd like to know is:

1. What are you doing within your organization to help improve the security of your product?
2. What works? What doesn't work?
3. How did you get management to agree to this work?

Thanks.

Answer 1

We pay bloggers to tell people our software is secure. Its works well, and its ends up costing us less money than actually patching our garbage software.

Answer 2

We think before we code. Strangely enough, it avoids many bugs, including those which are exploitable by adverse parties and henceforth known as "security holes".

Part of the trick is not letting anyone near a keyboard unless he has a solid amount of experience and expertise.

Answer 3

Honestly, Reading your book was a good start. :-)

Responding to your questions:

1. Crypto is a hobby of mine that I sometimes blog about (e.g. on TLS and AES). After writing my own implementation of AES, I learned enough to know beyond a reasonable doubt that I should never use my own implementation but rather use the ones written by the CryptoAPI and OpenSSL guys.

2. • Code reviews where people that are good at security issues are marked as required.
   • Having a class on-site with labs to raise awareness of issues mentioned in your book as well internal mailing lists discussing new issues.
   • Several folks listen to the Security Now podcast to keep current on what types of issues are out there and what is getting attacked. This indirectly affects design.

3. Except for an on-site course and buying the code review tool, none of these require management approval.

Answer 4

Hi, I'm an indie mac developer, but also a platform security evangelist: I'm the author of Pro Cocoa Application Security published by Wrox. In that book I champion the secure dev technique I use myself: it's based on the Swiderski and Snyder threat modeling, but with two changes. I make it lighter weight by considering which entry points access which assets without using DFDs. I also put more focus on identifying users and misusers, which I think makes it more applicable to shrinkwrap software.

As far as tool support is concerned, I use the Xcode static analyzer (based on clang), but have found it doesn't detect some common vulnerabilities. I did file bugs though :-). I also always use the gcc _FORTIFY_SOURCE macro. There aren't good Mac risk analysis tools but I'm working on that... ;-)

I've spoken on security to Mac devs at conferences and in podcasts and gotten plenty of feedback, if you want me to clarify anything I've said or are interested in the community feedback please ask in comments. Private questions are welcome to (though I'd prefer to stay on the forum): iamleeg at securemacprogramming dot com.