It’s probably a good thing my favorite software developer prefers to meet me at sushi restaurants, because when a security nerd like me starts debating a code jockey like Adam [name changed to protect the guilty] it’s best if there are no sharp utensils handy. “What do you mean, ‘Security isn’t your problem?!’ What do you meeeeean ‘That’s stuff to deal with later?’” I squeal, while my friend placidly chews and swallows and explains that where he works, they build the software first and iron out “the bugs” later — including any security holes that turn up.
And then he orders more sake, while I wonder whether I should be more afraid of bad sushi or Adam’s software.
Fortunately for most of us, Adam doesn’t work at Microsoft. Back in 2004, Microsoft — after years of pounding from security researchers as well as those with less savory motives — made it a company-wide policy that security processes are baked into software from the moment someone starts scribbling on that first whiteboard. Windows 7 is the second version of the company’s flagship operating system to undergo the complete process, known and maybe even loved at the company as the Microsoft Security Development Lifecycle.
Loved? Accepted at least, according to David Ladd, principal security program manager of the company’s Security Development Lifecycle (SDL) team, who says that the process is “entrenched” in development teams throughout the company. Security scrutiny is woven into all six phases of the software development process.
1. Requirements. As the developers begin to figure out what features belong in the new software, projects are registered with Microsoft’s Secure Windows Initiative team, which in turn provides security advisers to the development crew.
2. Design. The new software’s requirements and structure are fleshed out, while security folk work out security architecture and design guidelines for the product, review potential attack surfaces, and model possible threats. Ladd says that in the years since Windows Vista’s development, the company has increased its emphasis on bringing security into this phase of the process — that is, early — since it’s the phase at which potential security problems are easiest and most cost-effective to resolve.
Threat modeling is in many ways an exercise in creative thinking equal to the design process itself, since the security folk are attempting to predict threats to any software feature that might have security or privacy implications (again, at the same time the larger development is thinking up the features themselves). Ladd demurs from giving specifics, but says that the team came up with “dozens of threat models of varying complexity” for Windows 7.
3. Implementation. Coding is well and truly underway at this stage. As the code flows from the developers, the security folk are doing their best to break it, conducting code reviews, running code-scanning tools that seek out buffer overruns (a popular attack vector for malware) and the like, applying coding and testing standards, and running other security-testing wares including “fuzzing” tools that can catch API-related problems. With Windows 7, the fuzzing tools got a more thorough workout than they did with Vista; Ladd says that since Vista, the SDL’s list of banned APIs has expanded significantly, locking down a number of potentially exploitable avenues of attack.
Mitigations — techniques that make it easier for developers to counter hacker attempts to exploit a vulnerability — figure prominently in the SDL at this point. Defense-in-depth-based techniques such as preventing the exploitation of user mode heap corruption vulnerabilities, integrity checks for safe unlinking in the kernel pool, and filter improvements to XSS filters in Internet Explorer 8 (the default browser in Windows 7) are making their first appearance in Windows 7, according to Ladd.
4. Verification. The software is now functionally complete and ready for beta testing. For security folk, the Security Push (yes, that’s this phase’s official name) is on as they expand their efforts from the high-priority attack surfaces identified in the Design phase to — well, everything. No code is safe now as the security team looks at not only the new material but at legacy code re-used from earlier versions of the software. Penetration testing is also underway, and the team — with the general public just over the horizon — prepares a security response plan for after the software’s release. Which, after a final security review…
5. Release, followed immediately and for the life of the product by…
6. Support and servicing, which includes necessary patches and fixes.
Microsoft started revamping their security approach in earnest with the launch of its Trustworthy Computing Initiative back in 2002. That said, give credit where credit is due: The SDL is less a bout of original thinking from Redmond than an aggregation of proven security processes developed both inside and outside Microsoft, and designed for both client/server applications development (well-trod terrain for Redmond, obviously) and for applications based online or in the cloud.
To give back to the larger security community (and to encourage third-party developers to pursue a similarly rigorous security-aware approach to development (are you listening, Adam?), the company has been remarkably open about the mechanics of the process, which it describes as “non-proprietary” information. To that end, the SDL process guidance, updated regularly, is available online. What Ladd describes as “a slew” of SDL tools are also freely available for download, including BinScope Binary Analyzer, a build verification tool; !exploitable, which automates the process of bug triage; and an updated Threat Modeling Tool. Additional tools such as a basic fuzzer are available in the SDL Tools Repository, and there’s also a free training kit including multiple “Virtual Labs” demonstrations for those just getting started.
So — the SDL being a living process, constantly under review and revision — what did the Windows 7 team learn during development? What astonishments and surprises did the team encounter? Ladd says there was “no revelation at all — which is the ideal experience when it comes to the SDL.” Or, most security-oriented tech folk would add, for getting to know and understand a fresh operating system.
Want more like this? Sign up for the weekly IT Expert Voice newsletter so you don’t miss a thing!