This article discusses:
Figure 1 Mapping SDL onto a Generic Process
Figure 2 Recommended Security Books
Figure 3 Attack Surface Reduction
void *function( char *buffer, DWORD cbBufferLength);
void *function( _in_bytecount(cbBufferLength) char *buffer, DWORD cbBufferLength);
Other tools and requirement at Microsoft include:
Figure 4 Sample Banned Functions
A very useful testing technique for finding security defects is "fuzzing," which means taking valid data, morphing that data, and then observing an application that consumes the data. In its simplest form, you could build a library of valid files that your application consumes, and then use a tool to systematically corrupt a file and have your application play or render the file. Run the application under application verifier with heap checking enabled to help uncover more errors. Examples of morphing data include:
Once the end of the project draws near, a very important question must be answered: from a security viewpoint, is the software ready to ship? The Final Security Review (FSR) answers this question. It's performed by the central security team with help from the product team, but not by the product team alone. It's usually done a few months before the software is complete and includes:
List all the protocols you fuzzed.
There are two major parts to this process. One is responding to security defects and working with people who find security issues in your code. The other aspect is learning from these mistakes. At Microsoft, we have dedicated staff whose job it is to perform root-cause analysis of defects. These documents are then used to influence future iterations of the SDL. Each postmortem doc includes:
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.