Silicon Valley Speaker Series: Microsoft Security Customer Road Map 2003

CARTER MASLIN: Good afternoon. I'm Carter Maslan. I'm in the Platform Strategy and Partner Group here at Microsoft and thanks for joining us for the January Speaker Series. Today we've got Mike Nash with us from the Security Business Unit. He's a corporate vice president heading that unit and he's going to give us an overview of some of the trustworthy computing initiatives we've got, as well as just what you can expect in the way of security over the next year from Microsoft.

I'd just give you a brief background on Mike. He joined Microsoft in 1991 and he's held various positions in Windows marketing. He's the first product manager on the original NT marketing team, who prior to his current position Mike was corporate vice president of the Content Development and Delivery Group and served as the general manager for Business Windows Product Management, including Windows 2000, NT and other infrastructure products at Microsoft including SMS, SNA and Proxy Server. In this role Nash was responsible for the launch of Windows 2000.

Mike holds a Bachelor's Degree in computer science with honors from the Cornell University College of Engineering and an MBA with distinction from the Wharton School of Business where he was a Palmer Scholar.

So now it's with great pleasure that I introduce to you Mike Nash.

(Applause.)

MIKE NASH: Well, thanks, Carter, and to everyone else who took the time out, and I'm sure it's a busy Thursday, if it's Thursday afternoon, down here in the Valley. I really appreciate the opportunity to spend some time with you to share some of the thoughts we have up in Redmond and to really make sure that we have the opportunity to listen to you and be part of what I know is a great community of great thought leadership in the Valley.

As Carter mentioned, I've been at Microsoft for a while. My most recent job, before Security Business Unit, was working on the Content Development and Delivery Group, a very complicated name for basically a group that was responsible for helping customers with content to be successful with our products. The courseware and training group reported to me. The TechNet and MSDN programs for IT pros and developers respectively reported to me.

One of the other things that I had in my organization was responsibility for both the content, but more interestingly the operations of Microsoft.com. I'm sure a lot of you spend a lot of time on Microsoft.com, I hope. Interestingly, Microsoft.com is, I guess, now the third largest Web site on the Internet, number one with end users, with IT professionals and developers.

About two years ago almost to the day and as I was packing I found a plaque commemorating this event, but about two years ago to the day Microsoft.com was hatched and the way I became involved in that is I was driving to work one day and my boss at the time, Jim Allchin, who's the group vice president for the Platform Division, called my cell phone, and he'd never called me before, and he said, "Mike, I think Microsoft.com is down." And I said, "Jim, Microsoft.com cannot be down because if Microsoft.com was down I would know about it." (Laughter.) And I said, "It must be a problem with our proxy servers or with the network but I'll go check it out and I'll get back to you." And he said, "Mike, if it is just our proxy servers then the New York Times is having the same problem because I can get to their site and it says that we're down." (Laughter.)

So I scooted into the office and I found my guy Todd, who ran Microsoft.com and still does today, and Todd was in sweatpants, baseball hat on backwards -- life was not good in Todd's office. And I said, "Todd, what's going on." And he said, "We seem to be off the grid, Mike, and we can't figure out why."

So we brought together in the situation room to understand what the issue was the Microsoft.com operations folks, people in our IT organization to understand what was happening and apparently the night before at about 6 pm our routers, we'd stopped making our DNS servers accessible. We had about a four-hour time to live in our DNS names. It turns out not just Microsoft.com but essentially every property we had at Microsoft was inaccessible because we were not keeping our domain names up to date on the Internet.

And we identified the issue and found what appeared to be a Denial of Service attack against our routers that we have at the edge of our network and we spent time talking to the press and really understanding what was going on and explaining how unfortunate it was that someone could be attacking, exploiting one of our routers at the edge and it was just a terrible, terrible thing and for the life of us we could not figure out where it was coming from. We sort of understood the flaw but could not make the problem go away for all of our efforts.

About 6 pm that evening, after spending the better part of the day trying to understand what was going on, explaining to the press, working with all of our partners, a guy came strolling in from the data center and said, "Hey, guys, what's going on?" And I'll tell you, I still don't know this person's name. And we said, "Well, you know, we've been off the Internet for a while. We're having a problem with our routers being under an attack and can't get the DNS servers anymore." And he said, "Wow, that's so interesting because last night right before I went home I changed the access control list on those routers." (Laughter.) And we said, "Well, did you log it?" And he said, "Well, you know, I was going to do that first thing tonight." The guy worked on the swing shift.

So we basically undid what he did and amazingly all the traffic came back and the lights came back on. By the way, Microsoft.com was never down; you just couldn't get to it. In fact, if you knew the IP address you could get to it.

I think the key thing we learned from that experience and for me as a Microsoft person was really what it's like to be on the customer side of a security issue. We, in fact, thought we had a security issue. It turned out what we had was a configuration problem. But for me as someone inside Microsoft who's spent a lot of time talking to customers and working on products it really focused me on what some of the core issues that customers face when they use Microsoft and other people's products and in this case it very clearly was a cross-vendor issue that we had not looked at the problem holistically enough and we learned a lot about changing our processes to make Microsoft.com a more reliable and trustworthy place for people to go, especially people who depend on that site and on that content.

So what I want to do today is explain to you some of the things and share with you some thoughts we have around trustworthy computing in general. Out of curiosity, how many of you have read Bill's memo from about a year ago? Okay, the rest of you should read it by the next time we meet. (Laughter.) But really, to share with you and give you kind of the quick version of what you'll find in that document, which I think is very, very instructive, but also to drill down on some of the things we've changed at Microsoft in terms of the way we secure the products that we build and really look at some of the areas we're looking to invest in at Microsoft and with some key partners to make sure that we can at the end of the day give customers a platform that they can really depend on from a security perspective.

Very clearly, and I mentioned trustworthy computing briefly already, trustworthy computing is about making sure that as software becomes a more significant part of people's lives, and I use that very broadly -- that can include a consumer who's using software or an online service to figure out what movie to go to or to do online banking, or for a large enterprise to do business-to-business transactions. In order for them to have the ability to depend on those systems in the way that they would depend on other systems or other processes in the past really implies they have to have the ability to trust these systems.

And as Bill put together these thoughts last year, trustworthy computing really was about four core tenets: security, privacy, reliability and business integrity. And I think on some level the vision here is to make sure that software can be as trustworthy as a modern public utility, you can depend on it without thinking the way you would a modern public utility.

When I do this talk around the country, I found that in the state of California using the electric company as that modern public utility -- I don't totally get it but apparently there's not a lot of trust there, so I'll choose another utility because I want to respect the local situation, but we'll choose the phone company. (Laughter.) Is that safer? I know in Seattle I can't trust the cellular company, so let's work with it.

Let's imagine -- in fact, we're going to work through it. You live in Seattle and you trust the electric company and let me tell you why we trust the electric company in Seattle, because we know that power is going to be delivered to our house in a secure way, that I know that people are not going to be able to interrupt the power. I trust that the electric company as a consumer will make sure that power is delivered to my house in a very secure way.

We also trust the electric company, even though they have information about how I use the power, when I use the power, when I have more of a peak load, that even though they have information that helps them perhaps to deliver a better quality of service to me as a consumer of the electric company that they're going to respect my privacy and not share that information with other people unless I authorize them to do that.

It also means that as a consumer of the electric company that from a reliability perspective I can expect, I have high expectations of the reliability of the service they're going to deliver to me.

A part of that is availability. I know with many numbers of nines that if I go into my house and flip the light switch the lights are going to come on, but reliability is more than availability; reliability is really about also making sure of the quality of what's being delivered. I know when I walk up to a power socket -- in Seattle anyhow -- when I plug in I'm going to get about 110 volts of 60 cycle AC current and I don't worry about that because I trust that they're doing a very good job there.

And lastly, from a business integrity perspective, and this may be part of the issue down here, I'm not sure, but the electric company in Seattle does a very good job of billing me on a regular basis, they don't change the rates without telling me and when we have a big wind storm that even if a tree falls on their wire to make it so that I wouldn't otherwise have a high level of reliability the electric company sends a person out to put that wire back up even though it's not their wind and it wasn't their tree.

And really the goal of trustworthy computing is to make sure that from a software perspective as an industry, although I'll talk a lot about what Microsoft is doing, that we do things to achieve these very same goals.

From a security perspective, making sure that our software is more resilient to attack but also in particular protects confidentiality, integrity of both the data, the applications and the systems that we run using our software.

From a privacy perspective, very similar to the power company, the goal is to make sure that as an individual and as a customer of a Microsoft product or a service that I control how information about me is used and that even in the case where the software learns things about me to do a better job of providing that support that I control how that information is being used and it's not used except in ways that I explicitly authorize, although I have the opportunity to opt out of privacy if I want to.

From a reliability perspective, again the key thing here is about dependability and overall about no surprises but making sure that not only is the software available, that it's compatible and does things that I expect it to do in a way that I expect to do it.

And lastly, business integrity helps customers to make sure that they find the right solution, that we're only suggesting that the product be used in the way that it was designed and we give customers guidance around how to make those decisions. It also means that have to have policies in the way we do business from a support perspective, from a licensing perspective and we can do a great job of helping to achieve those customer expectations.

A couple observations about these four tenets: When you look at them, what you realize is that each one of the four is absolutely necessary and, in fact, there are many cases where as you look at them you can say, "You know, I can see things in business integrity that might really be a part of reliability and vice versa," but the realization is that while all four are absolutely necessary no three of them are sufficient, even though there may, in fact, be some overlaps here. And we look at this very holistically so we can make decisions in the broader context of trustworthy computing.

And the other thing to realize is that for each one of these four tenets it is very clear and really the point of the memo is that Microsoft and, in fact, the industry has work to do to make improvements about the way we build products, the way we support products and the way we make decisions that will help us to collectively make software more trustworthy, whether it comes in the form of a product or in the form of a service, and I think that really is the vision of what trustworthy computing is about.

Very much we see this as a journey, and we're about one year into the journey, but the key thing here is to make sure that the right changes are happening. I talked about changes in process. Well, one of the things we've learned at Microsoft is a lot of this has to do with changes in culture, to make sure that when we think about these problems we're teaching the people that are involved in making it happen at Microsoft and with our partners as well to make decisions in a way that really prioritizes trustworthiness not as priority one but actually almost as priority zero; it comes ahead of things that are priority one and we really use this as our guiding light to make decisions.

One of the key things relative to this was, as we talked about security, and I've spent a lot of time over the last year or so that I've been in this job talking to customers to understand the core issues that they face, and on some level what I always wanted to do was to be able to carry customers around with me so I could share with you some of the things they've shared with me.

I made the decision last summer to go off and do a video to capture different people, just people on the street, IT professionals that I found, developers, end users to get their perspectives on what trustworthy computing meant, what they trusted, what they didn't trust, really what security meant to them.

I went downtown to Seattle. We were going to shoot this at the Pike Place Market. You've all seen the postcards. And as we were getting ready to shoot the video a cop came up to us and said, "What are you doing here?" And we said, foolishly, "We're shooting a video about security." (Laughter.) And the cop said, "Actually, you're not." So we went to a different part of Washington and didn't tell anybody what we were doing and we shot the following video that I think will give you some perspective on things that we've seen.

(Video segment.)

MIKE NASH: The two most instructive things about that video for me were the two women at the very end, the last one, who literally followed me down the street after we shot the video, because she really did want me to help her -- (laughter) -- and the thing that we realized was really from a Microsoft perspective as a leader in this space, as a vendor providing so much of the solution, that there is an expectation amongst these customers that we're going to make the investments and both show them how to make their systems more secure but ultimately make the systems more secure without them having to know very much about it: make security much more straightforward.

The woman just before her also had very interesting comments in the sense that her relative level of trust of her telephone and her computer was different because of the experience and the fact that it was based on older technology. And really one of the goals of trustworthy computing is in some sense to close the gap between the goal of innovation and the needs from a stability and a reliability perspective and really the thesis here is that if we think more as we make decisions about trustworthy computing and use that as our guide it will help us to both innovate but make that innovation happen in the context of reliability.

I think the key thing here from an industry perspective, you know, we've had the microeconomic look with those individual customers, but from a data perspective the threat is very clearly real.

This is a survey from last year that looks at data during 2001, but in essence the feedback is that almost every customer saw some form of computer security breach. About 40 percent of the systems saw penetration from the outside, which was significantly up from the year before, 2000.

Eighty-five percent of customers detected some form of computer virus and when I shared this data with some of our partners in the anti-virus space their feedback was, "All that means is 15 percent had a computer virus and didn't know they had it," so certainly a very big issue especially during calendar 2001.

From a certain perspective, they went through and looked at the data to understand the root cause of many of these issues and the feedback says that in almost every case it was a configuration issue and it was a configuration that caused the breach. A configuration issue on some level means it could have been avoided, and my example of my early experience being the customer on Microsoft.com really showed that configuration can cause many of the issues that end up manifesting themselves as security issues. What this means is there's an opportunity for Microsoft and our partners to work to improve the overall securability of our systems.

I think the other important thing that we looked at when we first sat down to understand what was going on from a security perspective was certainly an issue that Microsoft faced and recently got a lot of feedback from the industry and from customers that we needed to do better. The first thing I had to do was to go look to see how we were doing on one of the measures that customers were using to compare us, and that was the number of vulnerabilities that Microsoft issued bulletins about from our operating systems. And I went to look at that for 2002 comparing Microsoft to other major vendors in the operating system space. The key thing we realized as you look at this data is you can't compare vendor to vendor per se; you have to compare operating system to operating system. Microsoft versus a pure OS vendor is not a fair comparison. You've got to look at Windows versus Windows. The second observation was you must look at the vulnerabilities that exist on a per operating system basis.

So the data here shows the relative number of security vulnerabilities. This is sourced from data on the vendor Web site and it shows that last year Windows XP had 34 vulnerabilities that we delivered patches for, Windows 2000 had 37, Sun had 86, Red Hat had 87.

And I think the key thing here we realized is that on some level this is just one measure and really in some senses as much as it measures the quality of the operating system it also measures the amount of focus that researchers and customers have on identifying issues and reporting them back to the vendor so the vendor can fix them.

I think the key thing here we realized is that our number, 37, while it may appear to be relatively good, it's about 37 higher than we'd like it to be. The real goal as a security team is for us to make sure that we can reduce these vulnerabilities and eliminate them in our products so the customers never have to experience them.

The other view is data from CERT, which is the clearinghouse for security information at Carnegie Mellon University. And what CERT advisories report is situations where there is a significant threat either to Internet infrastructure or to clients on the Internet, and in this case when you look at the relative numbers, again, a similar situation where Microsoft operating systems had five such advisories last year, Red Hat as an example of open source had 12 and Solaris had 12 as well.

And again, as you look at these numbers and compare the number of vulnerabilities or advisories that existed for Windows versus other vendors in this space and you look at that compared to the number of units of Microsoft products installed, on the one hand you could say, "Wow, our numbers are better, we should feel good." The other way of looking at it is we have a whole lot more customers using our software, the need for it to be better is greater. And on some level that's the motivation behind making this investment on behalf of our customers, to make sure that our products get better. But we really realized that there's a lot of work for us to do here in the context not so much of the competition but in the context of what the customer expectation is.

So our response when you sort of look at this a little bit historically over the last three years really began with the release of Windows 2000 back in February of 2000. The key thing we focused on in this release was making sure that we added the right set of security features so that customers could build a more secure connected infrastructure based on our platform.

The key thing that we learned after that was that we had a lot more work to do in addition to simply adding features around security. In fact, security was about more than features; it had to do with the quality of the code and the product.

So we created a team that was focused on the Secure Windows Initiative and their focus was to go in as a S.W.A.T. team and look at individual products, individual components of the operating system, focusing primarily on the base kernel of the operating system to make those improvements and make those corrections through code review, delivering those fixes in the form of a service pack.

What we realized was that it was not a scalable solution. In fact, we needed to make the review of this code more mandatory, and simply looking at the base of the operating system wasn't enough. And one demonstration of that was the fact that our Web server IIS that's part of Windows 2000 really became a point of exploit. So here we have a non-security feature, which becomes the source of security vulnerability.

Someplace in the middle of this came Code Red. What was interesting about Code Red was as a result of the Secure Windows Initiative. We'd actually identified the vulnerabilities that were later exploited in Code Red and actually had made patches available for those exploits. The question is if that was true, how could it possibly be the case that anyone could have been exploited by the Code Red virus? And it turns out that, in fact, while the patches were out there the customers who had deployed those patches never were impacted by Code Red. Sadly, it was the customers that hadn't deployed those patches that were infected and, in fact, we realized that most customers, even though the patches were six or seven weeks old, had not deployed the patches and therefore were exploited.

So we went back and realized that we needed to have a program to help customers with tools to improve the probability that they'd have the latest and greatest patches installed. The Secure Technology Protection Program or STTP was the result of that. The goal here was to make sure we gave customers tools to keep their systems secure in deployment and we realized that we had a lot of investment to do rather than simply making the patches available but to make it easy and in some sense to reduce the friction it takes to stamp down security patches.

So then what happened is two months later NIMDA comes along and the interesting thing about NIMDA was that again just like Code Red, although it was a little bit more complicated, the complete set of patches that corrected for it and, in fact, would have kept the customer free of the NIMDA virus, had been available for in this case I guess about five weeks before NIMDA was first found in the wild. Interestingly, NIMDA exploited multiple vulnerabilities in the operating system but again customers that had the latest patches installed never had an issue.

We went back and talked to the customers that we'd given the stern lecture to around Code Red and the feedback was that about half of them, even though they'd just heard from us in July about the importance of staying up to date, weren't up to date when NIMDA happened, so we realized we had work to do, we had to fundamentally change the way we build software and we had to begin that with Windows.

And we began a process with Windows Server 2003, which at the time was Windows .NET Server, to focus on a push. It meant that every person in the group had to be trained on what it meant to write secure code and that we had to make sure we went through all parts of the operating system to make sure that we could be much more confident in the way the system worked and I'll talk about how some of that works.

The key thing that we realized was that it wasn't simply about adding security features or doing a review, because you couldn't have a person come in and fix security after the fact, you had to have people that were really making sure that at the very beginning of the process security was a core part of how the system was architected and as the product became code complete we could do a review to make sure that we actually achieved those goals. The key thing here is that we had the realization that everyone needs to be a participant in the process of securing the operating system.

And really when it came down to the customer issue behind all this, when you sit back, there's five things customers told us that we absolutely had to do. The first was we had to reduce the number of vulnerabilities in our products before they shipped. So we should be able to find what you would otherwise experience before you experience it.

And the second thing is that as the products are used in new ways and in new configurations and new scenarios that more can be learned about what it takes to secure the platform and therefore Microsoft must continue to review and study and test our products from a security perspective even after they ship and then issue security fixes based on things that we learn before a customer ever experiences the issue or it's seen in the wild.

The third thing is the realization that even though we'll do a good job at one and two in the best case there are still going to be situations where new vulnerabilities are found by researchers using our products in scenarios that we did not identify. The idea is to reduce the number of things but the reality is there will still be these kinds of vulnerabilities identified. And therefore the expectation from the customer is that we ship timely, high quality patches in response to these finds.

The fourth point is that as these fixes become available either proactively or reactively it's imperative that we reduce the amount of friction and the process and the cost it takes to deploy patches. Two reasons here: One, to reduce the cost from the customer perspective and secondly to reduce the time lag between the time that a patch is available an the patch is installed in the system. That healthy ecosystem of PCs is what protects us from situations that could be avoided like Code Red and NIMDA.

And lastly, an opportunity for us to create more tools to help customers to be sure from a software perspective their systems are configured properly, but at the same time guidance to help make sure that we provide both the information and the expertise to make sure that people have a very highly secure environment wherever possible based on Microsoft platforms.

So to do this, we realized we needed to really change the way we measured and managed our development of the organization. I show this slide a lot to customers, to journalists, to analysts, but the reason we created this framework of secure by design, secure by default, secure in deployment and great communications around security was really about changing the way that we were going to measure and manage the people that build the software to make sure we used this as a framework really to achieve the five goals the customers gave us in the previous slides.

Secure by design really is about making sure that first and foremost we have an architecture that's designed for security. Security is not an afterthought; it must be part of everything that we do. The realization here is that in many cases the vulnerability that enables the exploit may be in a feature that has nothing to do with a security feature but, in fact, a place where we had a quality issue in a non-security feature, which later becomes an exploit. So it also means that we have to have security aware features to protect against that but fundamentally it means we have to reduce the vulnerabilities in the code.

And in some sense this began with a retraining of all the engineers and developers at Microsoft. We realized very quickly that while as students graduate from computer science degrees and other programs that teach software engineering that there are some great curriculum around what it means to built security features in a distributed environment, how to prove algorithms are correct for using in variant methods, but there were not a ton of courses and therefore not a lot of individuals graduating with formal training on what it meant to write secure code.

So the first thing that we did was to take all the engineers in Windows, and ultimately across the company, and bring them through a training on what it means to write code from a security perspective, what it means to verify algorithms, how to use tools to check source code and ultimately looking at ways that we can use new techniques like threat modeling to reduce the number of flaws in the code and to see how our products will perform under attack.

Secure by default was really about reducing the attack surface area, the realization that you want to turn on the minimum set of functionality that's necessary for a user to complete what they want to do with that system and we want to avoid situations where the system would otherwise be exploited by a thing the customer wasn't using.

We had a lot of cases where we simply said, "Hey, new functionality, let's give it to the customer." Good decision from a product packaging perspective, but turning it on was probably a step too far. And again there was a cultural change that we had to force into really everyone that was involved in the design, development and support of products to make sure we thought through the implications of those kinds of design decisions.

Security in deployment was really about creating tools to essentially protect, detect, defend, recover and manage configurations based on the extent of the Microsoft platform. I'll talk quite a bit about that later on in the presentation, but the key thing here is making sure the technology is there, but also making sure the information is there so that as we're doing design work, as we're getting ready to ship the product, we document not just the feature set but actually document the how to be successful from a security perspective in individual scenarios.

And lastly, communications. First and foremost, making sure we have a clear security commitment so people know what they can expect from us from a security perspective but also making sure that we are listening and taking feedback through the Microsoft Security Response Center and through community, and frankly, through interactions like this where I can not only share what our plans are but also have a chance at the end to hear feedback on where you're still seeing issues, where we can be doing better. In some cases I hope to be able to clarify things that we're already doing but I also realize in a lot of cases I'll be leaving here with new ideas and opportunities for us to focus as a company.

In terms of where we are from a progress today perspective we've now trained over 11,000 of the engineers inside Microsoft. Windows Server 2003 has gone through an extensive security push as well as a security audit as we get closer to ship. As a part of that, we've developed threat models for the major components of the operating system, we have done extensive pen testing both as a diagnostic tool but also as a way for us to validate the quality of the work that we did, doing this with a combination of Microsoft internal pen testers, using third party contract pen testers and some individuals in the government that have helped us out to attack our products from a white hat perspective.

We also have changed some of our development tool processes in a sense that we now compile our products with buffer overrun checking turned on in the compiler as well as doing source analysis using tools that were developed inside Microsoft Research to look for coding constructs like buffer overruns that would typically correlate with a security vulnerability.

From a secure by default perspective, really this is about changing the way products behave out of the box, and in some sense it's simple things like not installing sample code. In the case of Windows Server 2003 not turning on the Web Server by default. It's easy to turn it on. It's in the box. But in the case that the customer isn't using that piece of functionality, why have it turned on? And that really was a key learning for us over the last couple years.

From a secure in deployment perspective, it's really about having tools to address the primary issues that customers were facing and in particular it was about patch management, so using the auto update feature of Windows Update to automatically and proactively get patches out to customers. They have to opt into it but the idea here is if you're a small business or a home user -- I do this at home myself -- getting patches automatically increases the probability that I'll be up to date on patches.

We heard feedback from medium sized enterprises that said, "You know, we like the idea of automatic patches but we have real issues and concerns about compatibility. We want to be able to test those patches and control which machines get which patches at the right time." So we created a service that was released as a part of Windows Server last summer called Software Update Service and Software Update Service is all about making sure that we can give essentially a valve at the edge of the network that a network administrator can use to control which patches go in and which patches don't go in based on testing that they've done. From the client perspective or from the server being managed perspective it feels just like Windows Update but it gives the administrator that level of control.

And from a larger enterprise perspective we had many customers that used our Systems Management Server product to do both software inventory and distribution and they asked us to give basically the functionality of Software Update Services inside the infrastructure they'd already invested in. So the Feature Pack 1 that shipped last November for Systems Management Server enables you to get that same level of patch distribution using the infrastructure you've already invested in.

And from a communications perspective, one of the things we're doing now is our technical account managers now proactively call accounts when new security fixes become available. We got a piece of feedback back in the spring that said, "You know, we know that you're going to have patches on a regular basis. We'd like to know when they're coming on a more regular basis. So if you could do them the same day every week that would help us out a lot as well." So we responded very directly to that feedback and changed our behavior such that now we only deliver patches midweek, typically, actually exclusively on Wednesday. The exception there is if there ever was a critical issue we could go quicker there but we give the customer, the enterprise customer in particular a regular schedule. The odds of them being able to include that as part of their regular process improves the likelihood that machines will be up to date and that really is at the end of the day the primary goal here.

I think it's also important to realize that there's been some other progress of things that have been going on, even before we formally created the trustworthy computing initiative and in particular a focus here on Common Criteria over the last three years or so. Those of you that haven't heard of Common Criteria, and it surprises me, how important this is yet there really is an opportunity for broader awareness. Common Criteria is an independent evaluation and certification of software products. Today it's required, in fact, in some cases required by law, to have Common Criteria certification in order to make it legal for that government to purchase a product. Not only does it talk about a particular certification of software product, but also talks about deployment and operational guidance so that not only can we certify a particular configuration, we can give the guidance that we used to get that certification so the customer can experience the same benefits as the operate the system.

Windows 2000 platform, both client and server, has achieved the broadest set of scenarios evaluated by any commercial operating system. We have EAL Level 4 with credit for flaw remediation. What that means is that through the evaluation process it was identified that patches were a fact of life, and the work that Microsoft does to both listen and get feedback but also to provide tools to get patches out, there was a key reason that would make systems running Windows 2000 more secure.

We also not only tested the core operating system but focused on a number of key customer scenarios to prove and to demonstrate and ultimately to certify that the Windows 2000 platform was a great platform and in directory and user identification, in VPN and single sign-on and our encrypted file system space.

I think the key thing here is it really is a combination of not only code review but extensive penetration testing to make sure the product achieves the levels required for the certification.

And all the content to help a customer to experience the same configuration is available on Microsoft's TechNet site.

From a process perspective the key things we did, and the focus was primarily on Windows, is an investment of about US$200 million in improving the security of the Windows platform that will first be delivered as part of Windows Server 2003 but we also back-ported a number of those fixes to other operating systems. For example, Windows XP Service Pack 1 had many of the vulnerabilities that we learned about through the security process. Windows 2000 Service Pack 4 will similarly back-port, as appropriate, things we learned about in that push. The key thing here is really an investment in an installed base of engineers at Microsoft that know what it means to write secure code.

We then went off and documented this. In fact, there is a book that existed for about a year called Writing Secure Code by Michael Howard and David Leblanc and we were very fortunate to have these folks on staff at Microsoft. But the things that they learned as they mentored other groups through the security process over the last year have now been documented and they've actually updated the book and it's now available: Writing Secure Code, Second Edition. That really encapsulates many of the things we learned in our security push.

As I've said, we've trained over 11,000 engineers. We're also working with a variety of hardware and software partners to make sure they learn what we've learned. We can share that. We now have assigned module ownership, which means that in the Windows operating system, every component of software has a developer who is accountable for the security quality of that component. We also for every binary generated by that source have a tester who is accountable for the quality of the test harness and ultimately the quality of the binary to make sure that we're eliminating security issues in the product.

We have security pushes now for all the products we build at Microsoft and have used threat modeling as an important tool to help us verify and validate the approach that we've taken.

We've also done a number of recent audits to make sure that we have had the impact we're looking to have by making these investments in Windows in particular.

And the security review, which in the past was something that we happened to begin doing after the product cycle was already underway, with new products being developed security pushes and reviews are part of the standard Microsoft product development cycle. They're no longer going to be something we have to add into the process. And I think what that really says is that it's something that everyone has to build into their plans so that no longer will it be something that we do as an extra thing.

From a tools perspective, I talked a bit about this earlier, but essentially tools to enable a secure deployment, in this case the tool called the IS Lockdown Tool and URL Scan, and effectively these were tools to help us enable customers to achieve the equivalent of secure by default for products that we're already shipping. So basically tools to help verify and correct the configuration to make it as secure as possible based on the way the customer was using the tool.

The Microsoft Baseline Security Analyzer similarly is a vulnerability assessment tool that can be used to make sure that the machine is configured in ways at the base level anyhow that is appropriate for various kinds of uses. Both of these are part of the Windows Products.

Making Windows Update available with the auto update feature for customers of Windows 2000 and Windows XP so we can proactively get those patches out to customers without any user intervention if they don't want that to be there, and again as I mentioned before the enterprise version of Windows Update, is something called Software Update Service that really helps customers in larger enterprises where there is an IT staff to control what's getting out to those machines, clients and servers from a patch perspective. And as I mentioned, the one product that's actually a free part of the Systems Management Server -- the feature pack -- essentially takes the logic and intelligence of Software Update Services and leverages the infrastructure and investment customers may have made in Systems Management Server to get patches out there proactively as well.

I will talk briefly about a product that we have from Microsoft called ISA Server. ISA Server is Microsoft's cache and application level firewall. We recently released a feature pack for ISA Server earlier this month that really helps customers to secure their environment more at the edge with ISA Server. One scenario is securing Exchange and Web Servers with an application firewall to protect e-mail publishing when you're publishing off an Exchange Server, but also to secure the Web presence. The key thing here is as we've improved security we've also improved the overall level of performance by using that edge product to take some of the load off of the enterprise infrastructure that would be running using Web Server or Exchange Server.

Lastly, making sure that we can provide a secure edge gateway to provide much more cost-effective site-to-site remote access using ISA Server on top of Windows 2000.

I think it's interesting also as we sort of look at the secure in deployment part of the SD-cubed plus C model we spend a lot of time talking to customers in various segments to understand what are the key issues that they face from a security perspective, what are they looking to have the industry, not Microsoft -- these are not a list of things that Microsoft will on its own go off and do, but really a list of things that Microsoft and its partners must do to help customers and they expect progress in all these spaces. At the end of the day it's our progress on these areas that we know, because they have told us, that customers are going to use to measure our success.

I think one of the things that they told us was they wanted a model or a framework, in addition to the model we had for the work we were doing inside Microsoft, but a model or a framework that they could use as they operate software and applications and solutions based on the Microsoft platform.

And really, when we looked at the input they gave us that was captured in the previous slide, the phases that they were looking to have solved is really reflected in this security view: protect, detect, defend, recover and manage. Protect is really about making sure that from a configuration perspective the system is set up to run in a way that's designed for security. I guess the analogy in my house would be when I lock my door.

But at the same time while protection is great, the ability to detect when those policies have been broken is important as well, so if someone intrudes my network from the outside or from the inside or does something they shouldn't be allowed to do, I want to know about it, I want to be alerted and I want to detect that breach. In my house I have an intrusion detection system, a burglar alarm that tells me when someone has done something they weren't supposed to do, like break the lock that I had locked.

Defend is really about what you do in response to a situation where someone breached your security policy, and essentially it's the way you can absolutely take a change in configuration to respond and ultimately to do real time protection after you've identified an issue.

And recover is in some sense what happens when all else fails. You want to put the system back to the way it was before it was compromised, and really the opportunity here is to build technology to help the customer get it back to as close as the way it was before the problem happened.

I often draw this slide with manage in the middle and essentially management is about how we provide tools to protect, detect, defend and recover in a more comprehensive way.

The opportunity we see at Microsoft and working with the industry is ways that we can integrate these individual phases so that as we protect we can implicitly be informing the detection system. At the same time, when the detection system sees something new it can go back and automatically change the way things are protected.

And the idea here is really to balance complexity around security. If it's too hard to use people might not use it. And if it's too hard to use they may use it inappropriately. So on the one hand they may configure it in the wrong way and have a false sense that they've become secure. At the same time there's probably an equal risk that if it's too hard to use they won't use it all and they'll simply turn it off, which is also bad from a security perspective.

The key thing that we've realized is that from a directional perspective that there are things we need to build into our products to make them more secure and I've talked a lot about secure by design, secure by default, secure in deployment and great communications. That really is at the base level what we need to do to build into our products and we're going to be doing more and more of that over time.

It's also clear there are things we need to do to provide specialized security capabilities in the form of technologies like MBSA but also in the form of products like ISA Server to help provide the foundation upon which protect, detect, defend, recover and manage can happen and there are some examples here on the slide.

It's also pretty clear that there are things we need to do in other applications that perhaps at the face level don't seem to be about security. My best example here is VPN that when I started working at Microsoft, VPN was networking technology, but today we all know that VPN, in fact, is also a security technology and in many ways more security technology than anything else. So the need for us to build those extensions where communications and management really are part of the way we look at security is very, very essential.

I think the other important thing about this is making sure that when we build these solutions that we do it with a mind to provide hooks and interfaces so that third parties who have expertise in particular areas of security can make their solution part of the global solution that the customer can experience. We don't think this needs to be or should be a Microsoft only solution. It has to come in partnership with third parties who have great expertise in various aspects of security.

And lastly, to that point it really is the observation that we want to make sure we have an architecture and a roadmap that has room for and really takes advantage of the opportunities we have to help make the customer's experience with security be better using technologies from companies besides Microsoft.

I think one example of all this in action -- I'll talk a little bit about this from a secure by design, secure by default, secure in deployment and great communications perspective -- is the work we've done around Windows Server 2003. From a secure by design perspective it really was not the first product to go through this process -- in fact, Visual Studio went through this process about a year ago -- but it was certainly the largest product we ever took through this process.

And it's a very valuable thing on a couple levels. The first was from a learning perspective, the opportunity for us to learn how to do this properly was something that there were not a lot of models out there to follow. We had to do a lot of the innovation and learning on ourselves at this level of scale. It was important also because we built a base of developers that knew how to do this.

But on some levels, one of the long-term values here is that the technology represented by Windows Server 2003, while a great product on its own right, really becomes the foundation upon which future versions of Windows can be built. So we know we've made progress in this release; we know there's more work to be done after that. Trustworthy computing is certainly a long-term journey. One of the things that we've realized is that, you know what? There's going to be a security push for Longhorn and for versions of Windows after Longhorn. It's part of everything that we do and we now have a much better understanding of how to do that.

From an engineering perspective, we made changes like changing the architecture of IIS to make it more secure, to make it less of an issue for customers that use that as their Web Server. We knew there were places we could do better.

From a secure by default perspective a lot of this was turning things off and thinking through scenarios and dependencies on different components. One example back in the NIMDA timeframe was the fact that one of the ways that NIMDA exploited the Windows system was the result of a vulnerability in the ISAPI filter for the index server. And you may or may not know or care what the ISAPI filter is for the index server but my guess is that if you explicitly turn the index server off you wouldn't expect to be attacked by the ISAPI filter in the index server. And it turns out that in Windows 2000 Server even if you turned off the index server the ISAPI filter was on and you could be exploited if you weren't patched. So we had to think through much more about how we did that, and I think Windows Server 2003 is a great example of us making sure that we understood those dependencies and only turned on the minimum set of features that customers needed.

We also realized that for Internet Explorer there were things we could do. While it's a very powerful tool from the end user perspective, on a server we wanted to control exactly how it could be used. So now by default when Windows Server 2003 is installed, IE is set up in a locked down, limited way so it can do everything it needs to do to manage a Windows Server but not the other kinds of things that could potentially, if used improperly and not managed, be a source of exploit. So it's really a balance between functionality and security, which really at the end of the day is what the vision of trustworthy computing is all about.

From a secure in deployment perspective, here is a list of just the subset of the new security features in Windows Server 2003. I won't spend a ton of time on that. Things that include some enhancements to our PKI infrastructure, some work that we've done around role-based authorization with more levels of granularity of security level.

At the end of the day things that are not only great in terms of managing Windows Server better in deployment but as you build layered solutions on top of Windows Server, it becomes a platform to drive secure in deployment for products that ride on top of these products.

We also did quite a bit of work on prescriptive guidance. The realization was if we could test the products more in deployment they would be more secure. At the same time, as we have those learnings and learn the best practice to drive towards security, why not document that and make that information available to customers so they can have a higher probability of having a highly secure Windows Server based environment.

And lastly, communications. And in this case, a lot of it is about sharing what we learned. I mentioned before Michael Howard and David Leblanc's book, Writing Secure Code, based on our learnings in Windows Server 2003. We also have a course, a Microsoft Security Clinic, that's really based on what it takes from an expertise perspective to run Microsoft products more securely and we've done some architectural Webcasts by Michael Howard and others on what it means to design for security and are valuable to people building layered applications on top of the Microsoft platform.

The key thing here is from a trustworthy computing perspective in general, and from a security perspective in particular, as a leader we realized that we have work to do to improve our security but as we learn things we feel we also have a responsibility to make sure that those learnings are available to everybody out there, a customer, a developer, an ISV, anyone who wants to benefit from this experience at scale it really is our responsibility as a member of the industry to share what we learned and new techniques so that everyone can benefit from those so we could have a much healthier system so that software can be trusted more than it is today.

There are a number of resources that we have from Microsoft and certainly at a high level things that are reasonably obvious. We have a Web site for security for general business users and end users at Microsoft.com/security . The idea was to have an easy to remember URL. Security resources that you can find directly from that first link that hang off that on the security Web site.

We also have a site that focuses primarily on IT professionals. One of the things we've learned around security over the last year is that the context of how you talk about security is super important, and the way we talk to end users and the way we talk to developers and IT professionals, you use a different language because of the different perspectives. We have a special site that gets more technical for both IT professionals at Microsoft.com/technet/security and one for developers at MSDN.Microsoft.com/security . And as I mentioned before, some great training coming out around security on the Training and Certification Web site.

Lastly, and I used to sort of be afraid to do this, but I'm not longer afraid: if you have direct feedback on security and we don't have a chance to talk about it during the Q & A here today or it's something you don't want to share as broadly or you don't like speaking in front of a big crowd, send me mail. My e-mail is mikenash@Microsoft.com. I'm pretty good at getting back to you. In most cases I will get someone who usually knows more than I do to help make sure that we understand and address your issue, but as much as I want to help you with issues feedback on things we could be doing that we're not doing today is super appreciated and many of the things we've talked about this afternoon came really as a direct result of the feedback that people either gave me in a talk like this, gave me in a one-on-one or sent me over e-mail, so I encourage you to send actionable feedback to me as much as you can.

What you can expect: I talked in the beginning about the five things that Microsoft heard from customers. I think one of the things that we're focusing on first and foremost is security push and process on new products from Microsoft. We see that as a key thing that you should expect that we've done what we can to reduce vulnerabilities before you see the product.

Also, that we continue to enhance proactively the security of existing products as appropriate and make those patches available to you as security fixes in the form of service packs.

Making sure that we're very responsive to externally reported issues and implicitly here, but I'll be explicit in my words, that we're doing this with a very high level of quality and making sure that we can verify to the extent possible that we're both correcting the issue but also not introducing new issues with these fixes.

Number four, making sure we have continued improvements in the patching process, in some sense, in making sure that we're making it easier to get patches out there, reducing the friction with the end goal of making sure that with the highest level of probability you as a customer of Microsoft software have the latest and greatest patches available.

And also, number five, making sure that where it's appropriate working to develop new technologies and tools in the form of software and content to make sure that you have what it takes to both get secure and stay secure on the Microsoft platform.

It's interesting, as much as this is the two-year anniversary of my experience in securing a Web site as a customer of Microsoft, working inside Microsoft it's also just about a little bit more than the one-year anniversary of trustworthy computing, and we've had a lot of time with analysts, with press and with customers asking, "So what was the first year of trustworthy computing about and what's the next year of trustworthy computing about?" I'd say looking across all the four pillars of trustworthy computing, the primary things that we focused on first and foremost were issues where we could make changes to reduce customer pain, and I think there are some great examples of that in terms of how we build patches, what we've done in our investment with Windows Server 2003, things we've done to change the patching process, more content, changes to the severity rating system.

The second thing that we've spent time on though was making sure we made investments in things at the foundational level, both in terms of process and technology that would help enable trustworthy computing in the long term, and that's really a big deal for us in 2002 that in many cases will actually bear fruit for you in 2003 as Windows Server becomes available and other products become available. And I think the key thing we realized is this is an ongoing process, not something that's sort of a one-year initiative. It's also very different from other things I've worked on in Microsoft in the sense that each of the four pillars for Microsoft have executive sponsors that are really both responsible and in a position of authority to make change happen in process and in culture, but at the same time individuals like me, I'm the person on security, that feel a tremendous amount of accountability to our customers, to our leadership and to our stockholders to make sure that we're doing a great job of improving security.

But at the end of the day, if there's one thing that we measure our success on in this space, it is the quality of the customer experience around all these four tenets of trustworthy computing, and making sure that at the end of the day people not only don't have an issue with Microsoft from a security perspective but, in fact, our goal is to make sure that customers choose Microsoft because of the work we've done around security.

So we have I guess about 25 minutes or so left I think, if I'm telling time properly, and I am. So I'd like to open it up for questions and answers. And there are people with microphones that are here to make sure that others can hear you. I probably can hear you without them but I want to make sure that everyone has a chance to participate in both sides of the conversation.

QUESTION: Okay, do you have any comment about Palladium in trustworthy computing?

MIKE NASH: Yeah, I absolutely do. The question I guess you all heard really is about Palladium. We see Palladium as a very important technology really for the long-term foundation of security. I think the key thing we realize around Palladium is that it is something that is in development and that there's going to be a real adoption cycle for that.

That said, making investments like that to realize what the expectation is going to be further down the road are appropriate.

The key thing we're looking at is understanding how all of the work being done around security at Microsoft can be thought of more holistically and how all those systems could take better advantage of the great work being done by the Palladium team.

We also realize very seriously that there are some things we've got to do to improve both the experience and the capability even prior to the availability of Palladium and developing a roadmap that takes those needs into account and then addresses them with a successive series of technologies, well ultimately you could think of Palladium more as in some sense a security kernel for the long term.

Other questions? Yes. By the way, the commute, the cars that are there now, they'll be there at 2:00 so don't feel you need to rush out of here.

QUESTION: In the initial part of the presentation you have presented data that 95 percent of the breaches are due to misconfiguration. Is Microsoft doing something that if I install a product whatever configuration I select it gives me the details about what are the possible attacks so as an owner of the software I can imagine that these are the potential attacks possible for me and others so I can better configure the software?

MIKE NASH: Yeah, it's a great question and essentially what we're doing, in fact, it probably will be shipped as a quick update to Windows Server 2003 right after it launches, we have something called Secure Server Roles, which when you install the system it lets the administrator tell the system how it's going to be used and therefore configure it appropriately.

Where we've documented what you've asked for is probably more in the configuration guides, where as we're providing guidance for how to use the system in various scenarios we share some of the considerations and potential issues if you configure it one way versus the other.

It's less about vulnerabilities, because ideally the vulnerabilities are removed from the product, and more about surface area and the potential exploit of that service area, not because of the flaw or not because of the flaw but because of the need to configure it properly, and you'll find that primarily in a lot of the documentation we've done there; less explicitly at setup time but it's interesting feedback I'll bring back to the team.

QUESTION: Because the problem is that when you select a particular security it might make you less secure but it doesn't explain what are the kinds of attacks that are possible so you can take a more informed decision on that.

MIKE NASH: It's very good feedback. One of the other things we hear is that the way we do that on an end user product like Windows desktop versus an IT product like Windows Server needs to be very different. One of the things that we've made some changes on and it will be getting even better over time is situations where we ask an end user to make a trust decision where they don't have the information or the knowledge or perhaps even the expertise to effectively make that trust decision. So it's one of those okay-cancel decisions that we need to provide better context around, so it's very good feedback.

QUESTION: How do you see the competitiveness of ISA Server right now?

MIKE NASH: It's a great question. I think what we found is that there are many cases where customers are using existing level four firewalls and where ISA Server is being used is in many cases as a compliment to that because there's a lot of confidence in that other product.

I think we're looking to understand areas where we can improve ISA Server but we're certainly finding cases where perhaps more in the small business space where ISA Server is being used both as the level four firewall and as the application level firewall.

One of the key things we released last month was the Feature Pack for ISA Server to deal with some of the hard configuration issues that customers face as well as tools to make it easier to install key application level configuration issues. And really what it came down to was a lot of customer feedback that we got on how we could do better and that was the focus for Feature Pack 1.

We're also working on a next version of ISA Server that I think is really designed to address many more of those customer scenarios so that the product will be an even better choice for customers that want to use it for application level firewall and beyond.

Where we're having a lot of success with ISA Server today and where a lot of the larger enterprises are using it is also as a caching server and the combination of the caching capability and the firewall capability is really going to be the long-term reason to choose the product.

QUESTION: You talked a lot about the Windows and the infrastructure related security initiative. To what degree are these initiatives extending into business decisions, business decision applications?

MIKE NASH: It's a great question. I should be clear, and I wasn't that clear about it at the beginning, my role in the Security Business Unit is I'm responsible for both technologies like ISA Server and MBSA that are designed to help security, to enhance security but at the same time my primary job actually is around the process of trustworthy computing from a security perspective across the product groups of the company. I actually physically or organizationally sit in the Windows division, but my responsibility extends to other products across the company. And while I talked probably too much about Windows today, it's a great case study, we also are doing the same process with the Office team, with the SQL team, with the Exchange team to make sure that we deliver a consistent level of experience. So it really is pretty universal.

In fact, one of the things we did was work with the Xbox team as they launched Xbox Live, kind of at the edge of what you might think about, but at the same time we realized it's part of the infrastructure that people have and it needs to have the same level of consideration.

QUESTION: What role do you see of security-specific hardware devices, for instance like a biometric security removable media, where one model could be even having people's personal information included on a device that can only be accessed each time by sticking your fingerprint in it, something like that where it removes it? It's not just in the realm of software, of course, as a solution combining the two. How do you see that evolving?

MIKE NASH: It's very, very important and I think about this in the context of security but I also think about it in the broader context of trustworthy computing because you can make very similar sort of observations about reliability and device driver signing and in that context privacy has some implications there as well.

I think what we realized very clearly is Microsoft is a software company, but first and foremost we're a platform company and our vision when it comes to security-based hardware, as you described, is making sure that we can enable that and make it possible to extend the security platform using hardware. And obviously there are some implications of that around Palladium, but for things like biometrics as well making sure that we make it easy to integrate, make it easy to expose and integrate the customer experience so that the application doesn't need to be aware of a new authentication system, biometrics have an interface that the application sees as the same as other authentication mechanisms, and it really comes down to having an architecture, which we're working on, which can extend security to those devices.

Some of that is already happening today and things like the ability to replace these with different credential methods. At Microsoft, for example, today we use smart cards as part of our remote authentication system and what we learned there was while architecturally part of the system from an IT perspective it's very difficult, and therefore on some level the litmus test of success of the architecture is our ability to make an application use it transparently, from a developer's perspective, make it possible for the end user to use it from the application transparently and from an IT perspective the ability to manage it as part of the larger system. That really is the focus of where that goes, but it's a super important part of the solution.

QUESTION: How has shared source affected development of your end products but also interacted kind of the way Windows interoperates with third party products and in the way customers turn out their own applications? Has that kind of helped or hindered? And also how do you kind of feel, how does Microsoft feel about sending out that code so now people can actually get into the guts of the thing and has that created kind of concerns about are we showing too much or not enough of those kind of issues?

MIKE NASH: Yeah, the issues around shared source or the goal of shared source, not an issue, is really about making sure that we could address customers' concerns of the need to review our source so they'd have more confidence in the product but also in some cases a feeling from customers and from partners that they needed to know more about the source to do a better job of building hardware that supported or software that used it. We've also found that a number of governments needed to have the source as a way to build confidence in the Windows platform.

From the interoperability perspective, I think it's probably less of an issue because our primary focus and approach on interoperability is to embrace standards and to publish protocols for places where we develop the standards.

I think when it comes to the actual protection of intellectual property in the source, that's probably the biggest thing that differentiates shared source from other source models in the case that we want to make sure that people that need access to the source have access to it, but at the same time provide the ability to protect the intellectual property and to have respect for the hard work that developers do. And I think certainly it's that respect for that hard work that enables and pays for the innovation and I think it's a model that in some sense balances the need to allow access to the source with the need to protect intellectual property.

QUESTION: (Off mike.)

MIKE NASH: Yeah. The question is have we learned things in the form of feedback that we've gotten from governments and from third parties, and absolutely I think, in particular having people that can review our source from a quality perspective, give us feedback on the approach on different techniques that are used in the source, helping us to get feedback from a security perspective, doing external threat modeling and other testing from governments, from some contractors we have worked with, from partners and frankly from academia as well has been very valuable for us.

A lot of it is starting to happen more and more with governments and I expect that we'll even have more learnings as we go forward.

QUESTION: You mentioned identity management and role-based authorization as part of your secure deployment enhancements for Windows 2000. Should we expect to see significant changes to the user and administrative model going from Win 2K to Win 2003?

MIKE NASH: The key thing there is to make sure we have infrastructure that can scale more to more solutions. I think from a programming perspective it's probably a richer set of APIs to do more. One of the key things we want to do is to minimize the amount of new things that an administrator has to learn as they use the product. And where you'll see changes there, they're mostly focused on simplification. One of the things that we wanted to make sure we did a better job of was making it easier to provide better tools to simplify the deployment and management of the infrastructure in general and security in particular and that really is the focus for that release.

QUESTION: Two questions: The $200 million investment I'm assuming is for Microsoft coders to kind of work on that, is that correct?

MIKE NASH: Yeah. What $200 million includes -- actually it's a bit more than that, so I'll be precise -- it's what we spent to have developers at Microsoft look at the code, it includes money that we paid to external groups that came in to help us with education. It also includes money that we spent with some external penetration testers that helped us to improve the quality of the product, so it's an all-of number.

QUESTION: So as far as your partners, are you going to leave it up to them to spend their own monies or are you going to be making the investments in their sort of crossover platforms?

MIKE NASH: Give me an example so I understand the question.

QUESTION: I don't really have a specific example. I mean, a company that you would partner with that would be working on, say, the server or the Office security --

MIKE NASH: So you're really building a layered product.

QUESTION: Exactly.

MIKE NASH: Great question. So in that case I think the primary place where it's appropriate for us to have impact is on education information and we're being very active in sharing training with those partners with what we've learned and making that available more face-to-face in the case of more structural training, but also in terms of online content on MSDN and on TechNet.

When it comes to the actual investment they make in changing their products that's appropriate for them to be paying their R & D budgets.

QUESTION: And the last question on the choice to open some source code to governments, why the Russians first? (Laughter.)

MIKE NASH: It's a good question and I don't know the answer. I think it may have been more coincidental versus anything else but I think we're working, trying to be as fair as possible across multiple governments. I'm not sure the Russians were actually first. I think the U.S. and China came -- I know the U.S. came first. I don't know where other countries came. Perhaps Russia was just one of the ones that was more noteworthy. But if you want to follow-up with me afterwards I can get the facts and share them with you. I'm not totally positive what the order was there.

QUESTION: One of the most important trends in application development today is the use of third party components, so is there any initiative to support reliability and security issues on third party components?

MIKE NASH: Yeah, from a reliability perspective I think it's a very, very good example of an opportunity for us to work well together. It's something that we began probably in earnest in Windows 2000 and it started to have impact in Windows XP, which was the logo program around Windows. And it used to be back when I first worked on Windows 11 or 12 years ago and the focus was on doing the logo program so we could have a lot of people building products for Windows because that really was the goal. Over time, the logo program has provided much more guidance and in some sense a series of tests to help drive quality, and from a hardware perspective and from a software perspective in Windows XP getting that logo program implied that you did a certain number of things to improve the quality, where you put DLLs, whether or not you signed device drivers and then the ability to pass a test.

And the experience that you'll have on a machine that's running all signed drivers versus a machine that may or may not be running signed drivers typically will vary pretty widely because you'll have more confidence because more work was done in products that were logoed versus products that weren't.

It's a very big change, and it's something that I think we continue to innovate on but for which the awareness of why you should pick a logoed product versus a non-logoed product for Windows is not probably as broad as it should be. If you each tell five people we'll get in better shape.

QUESTION: Just one more question about security, in terms of, can you talk about Passport as an application developed on the Microsoft infrastructure, you know, should I bet on that and what are the plans regarding Passport in the context of security?

MIKE NASH: I have to admit that from a Passport perspective I am probably not the best expert on that, so I will, after we are done here, take a card from you and get you in touch with the right people at Microsoft. It is something that we certainly are investing in going forward with and it's something that we're using as a basis for our online services. But in terms of the core strategy, with Passport there are people that are far more expert than I am and I'll get you in touch with them. And I apologize for not having more information with me.

Yeah? George, how are you doing?

QUESTION: Hey, Mike. Just a question on like the Software Update Service and then I think it was a product or a patch that was going to ship after Windows 2003 Server about analyzing configurations for different scenarios. Is there ultimately a business for Microsoft in essentially providing an ongoing service to the customer, essentially charging for an ongoing service for this threat analysis and continuing updates?

MIKE NASH: I think when it comes down to where the business model is I certainly see different customer requirements, different opportunities, different things people ask for. Right now the focus is on making sure that the set of issues that exist out there today where there's a lot of customer pain getting patches out there, doing base level vulnerability assessment, those are things that we need to do to help customers have a better experience with the software that we ship and therefore things like MBSA are products or technologies like Software Update Service are things that are part of the license for Windows in the case of both those technologies.

Over time there may be other cases where Microsoft will be able to build security products and offer those technologies. A great example of that is ISA Server, where it really is our single big product right now in the security space that is sold under a separate license for a separate price. And we're looking at areas where we may be able to help customers in that space.

Very clearly though the priority is around trustworthy computing, and trustworthy computing really is about some of the fundamental things in the way we build our current products, and right now that is where the emphasis is from a security perspective at Microsoft because it's the right thing to do for the customer and that really is us being responsive to the place where they're feeling the most pain.

QUESTION: How do you see the impact of security on the development of cross-platform and distributed systems? It seems hard enough to build a secure system or a secure application in just a native platform so is this going to slow down things and is it going to prove to be an advantage to stay within a native platform?

MIKE NASH: I think there will always be tradeoffs both ways. The reason to go cross-platform is that when people decide to do them they're very real. There are other advantages to being on a single platform. I think the key thing that we see as a strategy to address those issues is cross-platform standards and some of the work we've done with IBM around WS Security is to make sure that we can build standards that allow applications that transcends platforms.

On some level from an architectural perspective, while the standards are great and we're always going to embrace them, the ability to have the entire application running on a more homogeneous environment does have some advantages, but I think in the case of security, like many other issues -- you could make the same statement for performance, for reliability, for a feature set -- there are tradeoffs both ways between single platform and multi-platform that really depends on the business model of the people building the software.

One of the things that Microsoft has done and continues to do with our layered applications, with a few exceptions, is to focus on the Windows platform and I think we've found an advantage for us to do that. Certainly it's something that anybody else who wants to do that could do that as well and we've seen the advantages there and so have many of our partners.

QUESTION: Hey, Mike. A quick question: What's Microsoft's sort of direction moving forward in terms of integrating, developing and enhancing its anti-virus capabilities, especially given your slide where the two catalytic events on your sort of timeline slide was Code Red and NIMDA?

MIKE NASH: That's a great question, and I think the key thing we realize is that patching is great but in some senses there are other tools that we can use with partners to prevent or to mitigate those issues. Some of the key things we've invested in so far in that space is really working closely with the anti-virus vending community to make it easier for them to build, create anti-virus products of even higher quality. If you compare the quality of an anti-virus engine on Windows XP to only back a few years ago to Windows 95 or Windows 98, the reliability is up dramatically, the performance is up dramatically and we've realized some major changes there.

I think going forward the opportunity is for us to do even more to make it easier for those developers of those products to integrate engines into Windows and to make a greater set of protection available on the platform.

QUESTION: (Off mike.)

MIKE NASH: I'm sorry?

QUESTION: (Off mike.)

MIKE NASH: I think the key thing here is with partners, they have the ability to make scanning an integral part of the experience that the customer has and there is some great work being done there. And I think the key thing we've learned is there's more and more for us to do to help those vendors both in building higher quality engines of higher performance to help make anti-virus more effective in more places.

STAFF: I think we only have time for one more question.

MIKE NASH: One more question.

QUESTION: Besides the basic steps you've outlined, what is Microsoft looking at around improving its security in messaging, specifically e-mail and instant messaging spaces?

MIKE NASH: The key things here at the base level are products like the next generation of Exchange Server, codenamed Titanium, going through the kind of security push that we talked about for Windows Server 2003. Feature-wise I don't know of anything in particular that they've announced for Exchange Server except continuing support for client to server security protocols and use of other base technologies in the operating system as they become appropriate.

One more or are we done? The woman in the back but maybe one of two women who has asked a question so we're going to show diversity here. (Laughter.)

QUESTION: In terms of development tools that you're using for the secure development, before you actually ship product, have you built a tool, are you planning to productize that for your developer network, have you bought any tools to do this?

MIKE NASH: There are a couple of key tools that are probably most essential in security. I think the first is the common language runtime and the .NET framework as a foundation upon which to abstract and simplify some of the security decisions from the developer.

The second is some of the capabilities built into Visual Studio like buffer overrun checking and compile time that at some level were always there but where CPUs were in the past, you could never afford to turn them on because the performance was too great and now there's room to turn those on.

The third is some technologies that were known internally as Pre-Fixed and Pre-Fast, which were tools that you've probably heard about for a while, especially if you've been following Microsoft from a reliability perspective. They're tools, source analysis tools that we used back in the Windows 2000 timeframe to verify code quality from a reliability perspective that apply equally well in the security space.

We don't have a plan now to make those more generally available, but it's really something we're looking at and there are challenges of how to do that in sort of the greater context of developer tools, but those were key tools for us to improve securability.

The other important tool is really a lot of the knowledge and know-how and I think you'll see that become available in three core forms that I'll talk about. One is online for MSDN and TechNet, in books for Writing Secure Code and other books like that from Microsoft Press and elsewhere, and then training and certification to both teach the expertise to developers, IT professionals and end users but also to certify and to measure the expertise.

Okay, I'm getting the hook. So I'll be around for a little bit afterwards I think. I do again want to thank you for the time you took this afternoon to share some ideas. If you have other ideas you want to share or have a question my offer to my e-mail address is very real. I'll do as great a job as I can of getting you a quick response. If being a response is "I don't know" that's what you'll get, but I'll find out what I can though. But again thanks for taking the time out. I know you have busy schedules and I want to thank you for spending some time with Microsoft today. Thanks.

(Applause.)

Top of page