You guys got beaten up pretty badly on security issues last year, and you've made a lot of changes this year. How do those changes affect the development cycle?
What we did in the first six to seven months of this year embodies a lot of the things we want to do going forward, but it was still something of a rapid response. In the aftermath of Code Red and Nimda, we launched a lot of initiatives about making security more manageable. One of the deliverables of that was the Software Update Services and the SMS Value Pack. As the year wore on, we still felt that XP wasn't where we needed it to be, so at the end of last year we started to review our options to make a significant difference in the security of the next versions that are coming out. We had actually done something similar to this with the .NET Common Language Runtime in November and December. That gave us confidence that we could try this. We trained about 8,500 people -- from February on, they didn't do anything but security work. Programmers focused on threat model development, understanding how to make systems more secure by default. Developers focused on code driven by the threat models to some extent, and they were basically looking for things either to make code safer or looking for vulnerabilities to eliminate. Through February and March what we did was "file bugs." This is a problem recorded from a database as a work item – this is a change we need to make by actually fixing the bugs and implementing design changes. How did you know when to stop and say "it's secure enough"?
That was a process metric. When have we got all the threat models? When have we done all the code reviews to the level dictated by the threat models? But that presumed that doing threat models and code reviews helped us find security vulnerabilities and made the products better. We think it does, but we're trying to get some more direct measures. Is this an ongoing process?
In many cases, the "file bug" process extended later into the spring. So we made the changes -- Windows XP Service Pack 1 is a true service pack, but we did an evaluation of all the bugs fixed for .NET Server and picked up the highest-priority ones as well as the design changes. Basically everything that was found was fixed in .NET Server. We're just now in the process of ramping up for the exercises of porting the vulnerability elimination changes to Windows 2000. How will the work on Windows .NET Server 2003 affect the vulnerabilities in Windows 2000?
The improvements we made in .NET Server will not completely solve the problems of NT 4.0 or Win2k systems that are still out there. The thing that we did for the Windows security pushes were quickstart initiatives. Given time to plan, we will do things differently, namely pulling the threat modeling and what we call "attack surface reduction" (changing the behavior of a product to make it less susceptible to attack and provide more of a degree of defense in depth) earlier in the design phase. Then we'll probably continue with something that looks a lot like the test and code review phase of the security push late in the product cycle -- sometime around beta -- for future versions. Did other divisions in the company go through the same process?
SQL Server, Exchange, Office, Commerce Server, and Visual Studio all did similar processes in the spring, but the Windows process was clearly the most massive. XP SP1 will be the first thing out the door with the changes. Windows .NET Server 2003 will have the changes. So will a future service pack for Win2k, and we've been talking about doing a further security rollup for NT 4.0. How many Microsoft employees were involved in making these changes?
We trained about 8,500 people. Beginning from February on, they didn't do anything but security work. When Bill Gates talks about $100 million (the amount of money spent on Trustworthy Computing), that's got to be a low figure when you do the arithmetic on 8,500 people times two months of work -- that's a lot of money. What kind of communication do you have with the community that tests your security in the field? What's your position on publishing vulnerabilities?
We like them to send those reports to us while we build a fix. Updating fixes in 28 languages for current and prior service packs -- for maybe two versions of a product -- takes longer to build than some of them might think. We'd like them to wait until we release (a fix), then we'll acknowledge that they worked with us in the security bulletin. We'd like them never to release exploit code. People may say, 'If I release it, people can protect themselves,' but we have an obligation not only to customers who're reading BugTraq every hour, but also to customers who barely know to click "yes" when XP Auto Update comes up and says 'do you want me to install a new patch?'. It's a matter of protecting all of our customers -- even those who aren't proactive about security.
FOR MORE INFORMATIONBest Web Links on security