You’d have to be a serious security curmudgeon to try to pick holes in the Microsoft SDL. The company’s security development lifecycle grew out of the Trustworthy Computing initiative, which turned 10 years old this year, and in many organizations, it sets the standard for secure development practices. At a minimum, it put secure development into the consciousness of many organizations and inspired a lot of companies to adopt bits and pieces, if not all, of the SDL.
No program is perfect, however.
Two security program managers working in the Microsoft Security Response Center (MSRC) shared a story during the SOURCE Boston Conference last week that’s worth sharing. It seems not too long ago, a security researcher reported a fairly serious vulnerability to Microsoft via its email@example.com email address. Turns out, however, that Microsoft’s spam filter kicked in and the vulnerability sat in limbo for months in a spam folder (sometimes it’s the simplest details that get ya.)
The researcher waited a responsible, er, respectable period of time, and eventually went public with details on the vulnerability, thinking Microsoft had ignored the researcher’s efforts. Once the details went full disclosure, Microsoft had to rush an out-of-band fix for the vulnerability; the two program managers refused to reveal the flaw last week.
“Don’t trust spam filtering,” said Jeremy Tinder, one of the managers. “This one was a crisis. Now we read them all (up to 500 a day). We have dedicated individuals to this triage stage of our security response.”
Tinder and his colleague David Seidman explained the MSRC’s role in the SDL at Microsoft and how vulnerabilities are handled once reported—and suggested these are minimal steps that organizations building their own software could follow. It’s a well-reported process that involves several stages:
· Triage—Microsoft determines whether vulnerabilities are security issues, or, for example, a coding or configuration error.
· Reproduce the issue –Microsoft tries to reproduce the security bug with the information provided by the researcher who reported it.
· Analyze the root cause—Once the MSRC is able to reproduce the issue, it determines how much user interaction is required to trigger it, and whether it’s a configuration that’s widely used by all customers.
· Planning—Schedule a fix and move forward after determining the scope of what needs to be fixed and any variants that could also trigger the vulnerability.
· Variant testing/investigation – This is a critical stage where all possible variants are tested before releasing a fix; the last thing the MSRC wants to do is release a fix and then have to re-release it.
· Implementation stage – The MSRC starts developing fixes immediately, and tests in parallel. They test whether other fixes cause regressions.
· Verification—Functional and regression testing is done here to ensure the patch fixes all attack vectors, doesn’t revert previous patches and doesn’t break applications.
· Release: More than a click of a button, Tinder and Seidman said. Involves having the infrastructure in place to push automatic downloads of patches, or give enterprises the ability to choose when and how to apply fixes.
Ultimately, the MSRC shoots for 60 to 90 days to turn around a patch, depending on testing and any issues that could arise and cause a regression forcing the MSRC to start over.
And oh yeah, check those spam folders.