What can Diaspora learn about security from Microsoft? (FIRST DRAFT)

It’s counter-intuitive to think of Microsoft as a poster child for security.  But the progress they’ve made since 2001 along with the challenges they continue to face have a lot of lessons for anybody in this space — including Diaspora, the “privacy-aware, personally-controlled, open-source, do-it-all social network”.

Several of the comments on my previous post Diaspora: what next? were from former colleagues at Microsoft, and they made excellent points.  Here’s my attempt to build on the list that Adam, Jason, and Alem started off.

1. Train the developers — and the designers and quality engineers too.  Secure software  is everybody’s responsibility.  Secure programming still isn’t covered in any detail in most undergraduate or graduate programs, so just like Microsoft discovered a decade ago, most developers don’t know the basic practices.
2. Inspect the code.  Formal multi-role code reviews are very expensive, but fortunately Diaspora’s code base is small.
3. Do threat modeling.   If you don’t know what the threats are, how can you claim that your system protects privacy?  It’s fun, too!
4. Use the tools — and develop ones that don’t exist.  There are some excellent specification and unit testing tools in the Ruby environment (Cucumber, RSpec, Selenium).  There are also some holes, for example static analysis, fuzzing, and attack surface estimation.  This is a great chance for the broader Diaspora community to get involved and supplement the core team.
5. Include security in the software lifecycle.  As Wayne Ariola pointed out in a comment, Diaspora’s current “find-and-fix” approach mirrors industry mindset … and it doesn’t work. Microsoft’s SDL, which has been steadily refined over the years (see last fall’s discussion of Agile SD), and projects using the SDL from the beginning are noticeably more secure.  There are other secure development processes as well which may be a better match for Diaspora.  The important thing is to choose one and then take it seriously.
6. Be wary of legacy code.  If security isn’t designed in up front, it’s incredibly expensive to retrofit it and you’re going to miss a lot.  Given the gaping security holes in the developer preview release, and the small code base so far, Diaspora should consider a rewrite rather than incrementally trying to make it work.
7. Reach out to the security community.   Microsoft used to treat security researchers as the enemy, and minimize communication about security issues.   By engaging with their critics, and providing a lot more information, they’ve learned a lot about how to improve their security — and also helped shift others’ perception of Microsoft.  Diaspora’s in a completely different situation, of course, an outsider with zero market share facing a powerful incumbent, so they won’t be hosting events like Blue Hat any time soon.  Then again unlike Microsoft back in the day, a lot of people are rooting for them and want to help.

Obviously this first cut is biased by my experiences and perspectives, so I’m very curious what others think.  I’m working on a short presentation on this and will post it her once it’s ready.

Thanks!

jon