Sponsored Link •
Not by angry customers suing for damages after security breaches, or by governments breaking up monopolies, but by open source developers and security professionals accusing them of being obsessed by security.
Microsoft is a company we love to hate. In particular, the security of Microsoft products has been the target of fierce criticism. However, in the last few years, Microsoft has made a concerted effort to improve the security of their products. The Windows Security Push was launched in 2002 in the run up to the release of Windows Server 2003. At that time, the seeds of the Security Development Lifecycle (SDL) were sown. This process has since been refined by many more security pushes. I had the pleasure to moderate a panel discussion "Should companies be emulating Microsoft’s Security Development Lifecycle?" on Tuesday at the OWASP Europe conference in Leuven.
The panelists were Pravir Chandra, chief security architect for Secure Software, Alex Lucas, a member of the Secure Windows Initiative team at Microsoft, Andrew van der Stock, OWASP Guide project lead and Dinis Cruz, OWASP .NET project lead.
Relatively little of the SDL is in the public domain at present. This is about to change with the publication of Michael Howard and Steve Lipner's book. Nonetheless, the SDL has apparently already gained some traction outside Microsoft, as Andrew van der Stock reported a successful implementation at the NAB where he is employed as a security engineer. Andrew also blew the trumpet for MSDN Security patterns and practices.
OWASP's motivation for organizing the panel discussion was the announcement of the release of an OWASP process guide: CLASP (Comprehensive Lightweight Application Security Process) was donated by Secure Software to OWASP for distribution and further elaboration. Pravir will lead the OWASP CLASP project.
CLASP addresses the same problem space as Microsoft's SDL. Would it not have been simpler to just adopt the SDL? According to Pravir, the distinguishing feature of CLASP is the opportunity to tailor the process to the needs of the organization. SDL is seen as too heavyweight. Alex Lucas points out the irony of the SDL description fitting into a book of fewer than 300 pages, while the supposedly more lightweight CLASP requires around 600. However, Pravir stresses that the SDL is too rigorous for small organizations who may not be able to afford to work to the same exacting security standards that Microsoft is currently setting. This statement seemed to be endorsed by a significant number of the audience.
So what, if anything, of the SDL is applicable to other companies developing web applications and should be in CLASP as well? There was overwhelming consensus that threat modeling is correctly identified in the SDL as the single most important activity for improving security. However, some concern was raised whether Microsoft's techniques, as described in Writing Secure Code by Michael Howard and David LeBlanc and Threat Modeling by Frank Swiderski and Window Snyder, pays sufficient attention to rating the risks. Not all threats need to be addressed as some level of risk is acceptable. How much risk can be absorbed is specific to the organization.
Alex emphasizes the importance of security awareness, and beyond awareness, openness and willingness to discuss security problems.
The inevitable discussion about the relative merits of open and closed source for security follows. Dinis makes the classic case that many eyes make all bugs shallow. While this may sound attractive, for the overwhelming majority of open source projects, security reviews are not taking place. Moreover, many open source applications are being written by developers who are poorly security educated and unwilling to compromise on features for the sake of better security. Both Andrew and Alex recount reporting security bugs in open source software, only to be ignored.
Has Open Source lost the security edge and is it now being superseeded by the products and practices Microsoft is introducing?
|Johan Peeters is an independent software architect who spends a lot of time plumbing and generally fixing leaks.|