Security 101: Part 3

An Introduction To The Microsoft Security Development Lifecycle (SDL) (Concluded)

Just before we jump into the second half of this introductory article, did you know that the Microsoft Security Development Lifecycle has its own blog? Written by an 8-strong team of SDL / security development managers, this is probably the best place available to keep up to date with the latest news regarding the lifecycle itself, and the tools and resources available to help us with its integration and day-to-day use.

Phase 3: Implementation

"During the implementation phase, the product team establishes and follows best practices for development then enforces the best practices during software development."

• Specify tools
• Enforce banned functions
• Static analysis
  

Take tools, for example. There is available, a constantly expanding array of second- and third-party tools which can help secure development; build tools, code analysis and coverage tools, and so on. Microsoft use and recommend a set of FXCop security rules (actually different sets, depending on your development environment version). It's one aspect of best practices, to keep up to date with what's available in these areas. Similar remarks apply to the available guidelines on the use of these tools.

Choice of a managed code language and environment is another such aspect. When this is not an option, one way in which Microsoft has tried to reduce the vulnerable surface area, has been to ban certain frequently exploited APIs - such as unsafe string buffer handling functions - in unmanaged C or C++ code. Published lists of such recommendations are available.

Rules to prevent SQL injection attacks are also included in this development phase. In a similar vein, JavaScript developers should generally avoid the use of the eval() function!

Web Development

The current MSDN documentation for this area of the SDL contains many additions labelled "(New for SDL 4.1)", and it is interesting to see just how many of these relate to web development - it's a very high proportion. This is still more interesting in the light of a recent SANS Institute Report, which found that most organisations presently focus on OS patching, whereas 60% of all attacks are on web apps.

Documentation

Trustworthy Computing mandated that the default configuration for a software package, landing on a user's desk (or lap!) for the first time, should be a secure configuration. However, users also need the ability to mess with their security settings, for example to change their defaults to something that better suits their particular environment. Documentation of the security settings, in both configuration and deployment, therefore becomes a deliverable, allowing such decisions to be made in a safe and informed way.

Phase 4: Verification - Fuzz is the Buzz

"The verification phase is the point at which the software is functionally complete and is tested against security and privacy goals outlined in the requirements and design phases."

• Dynamic/Fuzz testing
• Verify threat models and attack surface
  

To ensure that code meets the security and privacy targets set in earlier phases, we require thorough security and privacy testing, and a security push, followed by a privacy review of the release candidate. Here we are concerned with the classic CIA of information - Confidentiality, Integrity, and Availability.

Only the test process is capable of guaranteeing that the system will remain secure in the wild, and one key to this process, given some emphasis in the MS scheme, is Fuzzing. Once again, there are tools available which will randomly generate more test data than you ever wanted to see, and do it intelligently and with expert knowledge of the type of channel: command line, file, database, URL, script, image, and so on. That's what fuzzing's all about. There are RPC fuzzers. There are ActiveX fuzzers (yuk). I could go on...

This SDL blog article contains a link (.zip) to a simple file fuzzer, suitable for use by novices. It also has another to the "BinScope Binary Analyzer", which MS teams have used in one form or another since 2002. This little beauty checks for loads of security-related stuff in your binaries, and integrates well with both VS2008 and Team Foundation Server. That, and the price tag (it's free), should just about sell it.

Phase 5: Release

"The release phase is when you ready your software for public consumption, and you create plans for post release servicing of the software."

• Response plan
• Final security review
• Release archive
  

The product is subjected to a final security review, and a final privacy review, prior to its release. The results of these activities are fed into a Response Plan - that's the plan of action implemented when post-release vulnerabilities are discovered.

[Don't you mean "if"? - Ed.] [Only joking. - Ed.]

The privacy review may take its structure from a preset SDL Privacy Questionnaire. It may require validation by a privacy advisor or legal representatives, and the drafting of a privacy disclosure statement or statement of compliance.

The Final Security Review should be a timely (say 4-6 weeks before release) and comprehensive review of known threat model vulnerabilities.

Response Planning

Even when your release is into a world containing no particular threats to your new system, such threats can emerge later. And similarly, the privacy goalposts can be moved by the emergence of some new privacy advocacy. In short, you have to plan for contingencies.

Know and document publicly who is responsible for dealing with the different types of issues that may arise. Have a policy in place to handle cases where these issues involve third-party code components rather than your own.

Don't forget to lock all the doors, and cancel all the holidays.

Response: Examples

For examples of security response at Microsoft, visit the Microsoft Security Response Center (MSRC) Website: http://www.microsoft.com/security/msrc/default.aspx

Next time, and for the remainder of this series of articles, I'll be looking at some particular vulnerabilities, some quite public and occasionally spectacular, and their responses. I'll also be covering various security- and SDL-related tools and other resources. This is where it starts to get really interesting...