Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Steve Lipner here. By late 2001, our security teams had been reorganized and I was managing both the Microsoft Security Response Center (MSRC) and the “Secure Windows Initiative” (SWI). MSRC handled Microsoft’s reaction to vulnerabilities and their exploitation, while SWI provided training, guidance on best practices, and consulting for product groups. The Code Red and Nimda worms and a series of widely-publicized product vulnerabilities had made 2001 a very difficult year for Microsoft, with at least one well-regarded industry analyst advising customers to stop using our IIS web server. My team took the heat of the negative reaction by customers and the press.
Michael and Glenn talk about some of the internal milestones that led to Trustworthy Computing and the Windows security push. The November executive review with Bill Gates and senior executives conveyed both customers’ concerns about our products’ security and the code-level problems that were the underlying cause. My team offsite shortly after that review came up with the “crazy idea” of stopping Windows development until the security problems were solved – or at least until security was going in a different direction.
Some of my most vivid memories are of planning and internally “selling” the security push. Michael and I met with one of the program managers who ran the Windows Server 2003 product, and he advised us that he agreed that security should be a priority and that he could see accommodating a two-day stand-down” in the schedule. Michael and I said we had a little longer duration in mind – and kept on planning.
The Common Language Runtime team had pulled together its security push across a single large team. We had to figure out how we’d organize, train, and manage the Windows push across a large number of product units and make sure that no group got left behind. I spent a lot of time in December 2001 developing plans and schedules that would provide product units with specific enough guidance to stay on board, but enough flexibility to accommodate their specific technologies and threats. I kept presenting our plans to higher and higher levels of management expecting some pushback, but all I heard was “OK, keep on planning”.
By January, we were committed to the security push. Jim Allchin, then our group vice president, kicked off a meeting with the 200 or so top managers in Windows, and we briefed them on the objectives and organization of the security push and what we were trying to accomplish. We told each group to develop an implementation plan for its participation, and my team reviewed the plans and provided feedback and suggestions. Jason Garms still has a mail message that refers to our spending our entire weekends reviewing plans – one of Jason’s messages was sent at 4:00 am on a Monday morning!
By the end of January, the plans were in place and we rolled out training – ten four-hour sessions focused on developers, testers, or program managers. Each training session was kicked off by one of the vice presidents in the Windows division, and each filled Microsoft’s largest conference room with about 950 people. Each attendee received a copy of Writing Secure Code first edition.
Beginning in February, we spent our time (probably 13-16 hours a day) attending the Windows ship (then “war team”) meetings, meeting with product teams, answering questions, and reviewing bugs. Although we’d done a lot of planning, this was definitely our first time, and a lot of what we were doing was ad hoc. I still remember the complaints about how vague and hard to implement our threat modeling guidance was – my answer then was “do what you can”, but I still remember those complaints and think about how far we’ve come when I look at the SDL Threat Modeling Tool.