November, 2008

A recent article titled "NSA posts secrets to writing secure code" caught my eye in part because the words "writing secure code" always get my attention! But also because anything that can advance the science of securing software is of interest to me.

There is another reason why the article got my attention; my manager, Steve Lipner, is one of the few people to have designed and built a TCSEC A1 assured system and lived to tell the tale. None were sold, but they built one!

The NSA-directed project, the Tokeneer ID Station (TIS), involved building a low-defect system that conforms "to the Common Criteria requirements for Evaluation Assurance Level 5 (EAL5)" in a "cost effective manner." I'm all for this, because building high-assurance solutions is not cheap.

There's a paper with more technical detail about the project that is worth a read.

In my opinion, the project is only a science project, an experiment, for the following reasons:

• It's tiny. Weighing in at a little under 10 KLOC.
• It's only a very small portion of a much larger solution which has not been developed using the same rigor. This bit of context makes the solution as a whole moot. Call me cynical, but my question is "can the entire solution be built with same rigor in a ‘cost effective manner'?" Perhaps it can, but that is not what is presented.
• It sits on top of many operating systems (Windows, Mac OS X and Linux) that are not EAL5 certified. So it would be a little like having an EAL5 certified CharMap application running on EAL4 Windows Vista.
• It's written in a subset of Ada called SPARK, and SPARK skills are not common in the marketplace. Interestingly, SPARK makes use of annotations to help drive the static analysis process. While not a total analog, we also recommend Microsoft development teams use annotations (SAL) to help drive the required static analysis process.
• The application has a large number of dependencies that are not part of the project:

In the SDL we call these files ‘giblets' because they are components needed for your application to operate, but they do not belong to your team. Some of the files look old and highly vulnerable, such as libpng-3.dll from 2001! OSVDB lists 23 vulnerabilities since 2002 in libpng!

In summary, the TIS project is very interesting to a small number of important but specialized customers, such as the NSA, for whom this kind of research is critical. I too found it interesting, but the process is far from a set of "secrets to writing secure code" and the tools are certainly not within reach of day-to-day applications and not applicable to developing complete solutions.

Bryan here. The SDL team is well represented in the annual security issue of MSDN magazine – we have three articles that might be interesting to you, given that you read the SDL Blog!

First up is a code review quiz, “Test Your Security IQ”. Put your C/C++/C# security skills to the challenge by reviewing ten tricky code snippets that Michael and I devised. As an added incentive, I’ll post public congratulations here in the SDL blog to the first person who reverses the insecure hash found somewhere in the exam (not to give too much of a hint).

Next up, we have “Agile SDL: Streamline Security Practices for Agile Development”. I’ve been talking about web application security issues in the SDL blog (and in the September issue of MSDN magazine, if you missed it). However, while it’s essential to make sure that web-specific issues are covered in the SDL, it’s equally important to make sure that web development teams – and other Agile development teams – can use the SDL effectively, and the classic, phased SDL approach is not always a good fit for these teams. This MSDN article is the first public look at the new SDL/Agile methodology that we’ve been working on for the last year. This process is currently in beta with some internal Microsoft product teams and online services. We’d love to get some external feedback on it before we release it to the entire company, so please send us your thoughts.

Finally, be sure to check out Michael’s Security Briefs column “Threat Models Improve Your Security Process”. Regular readers of this blog know how important threat modeling is to secure development. This article describes methods of using threat modeling not just to identify security vulnerabilities outright, but how to use it to make other SDL activities such as fuzzing and reducing attack surface more effective.

Three articles are more than enough for one team for one month! But be on the lookout for more articles from the usual SDL suspects in the near future. As always, keep watching this space for details.

Hello all, Dave here…

I am in Barcelona, Spain with Michael Howard and Adam Shostack at the TechEd EMEA: Developers Conference.

In addition to teaching and attending security sessions, we are in Barcelona to formally announce the launch of the SDL Optimization Model, SDL Pro Network and the Microsoft SDL Threat Modeling Tool Beta!   For those of you who are unaware of these initiatives here’s a description of each…

SDL Optimization Model: The SDL Optimization Model was created to facilitate gradual, consistent and cost-effective implementation of the SDL in development organizations outside of Microsoft. It allows development managers and IT policy-makers to assess the state of the security in development and create a vision and road map for reducing customer risk.

Specific objectives of the model include the following:

·         Enable organizations outside of Microsoft to create more secure and privacy-enhanced software by successfully implementing the SDL

·         Allow organizations to self-assess current software development security practices and create a strategy for gradual improvement

·         Provide SDL Pro Network service providers with a consistent and effective framework for providing SDL services

SDL Pro Network: The SDL Pro Network is a group of security service providers that specialize in application security and have substantial experience and expertise with the methodology and technologies of the Microsoft SDL. SDL Pro Network service providers will guide and support organizations in implementing the SDL into their environments.

The primary focus area for all members, both now and in the future, will be to deliver on the program’s commitment to make the SDL available outside Microsoft, specifically focusing on these issues:

·         Protecting the customer - Helping customers adopt the SDL or general secure coding practices.

·         Improving the SDL - Leveraging member knowledge to understand how the SDL is used by customers, what needs to be modified and what customer needs must be met in the future.

SDL Threat Modeling Tool Beta: The Microsoft SDL Threat Modeling Tool Beta allows for structured analysis, proactive mitigation and tracking of potential security and privacy issues in new and existing applications.  Microsoft developed the tool and we use it internally on many of our products. This tool offers a threat modeling methodology that any software architect can lead effectively — in contrast with other processes, which are more expert-dependent. A few quick notes about the features:

·         Automated guidance and feedback in drawing threat diagrams

·         Guided analysis of threats and mitigations based on the STRIDE taxonomy

·         Integration with bug-and issue-tracking systems like Visual Studio Team Foundation Server

To learn more about these, visit the SDL portal, http://www.microsoft.com/sdl.

By the way, if you are in Barcelona and want to stop by and chat, the session list is below:

SDL Theater Sessions:

·         Getting started with the new SDL Threat Modeling Tool                             

Adam Shostack, Theater 1, Tuesday, Nov. 11, 15:20 – 15:40

·         You could do that but it would be wrong – a discussion of pros/cons of threat mitigations

Michael Howard & Adam Shostack, Theater 1, Thursday, Nov. 13, 10:20 – 10:40

General Sessions:

·         DVP308  How I Learned to Stop Worrying and Love Threat Modeling      Nov. 12, 10:45 – 12:00

·         DVP309  How to Review Your Code and Test for Security Bugs                  Nov. 13, 3:15 – 4:30

·         DVP312  Top Ten Strategies to Security Your Code                                       Nov. 14, 10:45 – 12:00