How do you account for the escalating number of security flaws in Microsoft software?
We actually have no more vulnerabilities than any other piece of software doing the same functions, and we get hit a lot. But it's not an excuse, it's just the current reason. The more interesting message than the number of attacks, and the visibility of Microsoft, is the additional responsibility we have by virtue of market success. You can say the number of attacks is a result of market success, which is true. Or you can say the obligation to have fewer attacks is an obligation of market success. And I think that's the attitude that the company has about this.
Is Microsoft more vulnerable than other companies because it's such a big target?
Almost by definition [it is]. If you've got millions of lines of code - and let's say our code was five times as good as everybody else's is but we had 10 times as many people out there hitting it - the chances are that we'd see less pure vulnerabilities but we'd see more attacks and successes, simply because people would find the holes.
Microsoft has so many desktops and networks so have you lived up to your responsibilities? Microsoft is retraining its engineers on security best practice. Isn't it a bit late in the process?
This is a learning process. We don't sit there going, "To hell with security, let's just go put some features out. We don't care about users." This is a process. Could we have reacted sooner? Possibly. Would other companies have reacted sooner? I don't know. I think we have a tremendous sense of obligation to our users and we've always fulfilled it by delivering more functions at incredibly good prices and incredibly good speed. And now, there's another knob they want turned.
We owe them that, and we have a bigger obligation to do it. With the benefit of hindsight, we could have changed everything. But I'm not sure it was either practical or possible.
Focusing on the technology, in Windows XP, for example, there was a problem with Universal Plug and Play (UPnP). Explain the problem and what's been done about it.
UPnP. It was a buffer overrun problem and that's increasingly common, where someone can program and send a long piece of data that is long enough to overwrite the stack in memory ... and it can do things like send bad e-mails. That particular technique has been a feature in a few bug exposures recently, and two [in America Online's software] in recent weeks. The good news is we can go back and locate them and fix them. That, amongst others, is one thing that we're examining in the code.
After the NIMDA virus hit last autumn, Gartner warned users about security vulnerabilities in Microsoft's Internet Information Server and was critical about the number of security patches that Microsoft issues. What is going on there?
First of all IIS is not any more error-prone than any other Web server. In fact, some versions of Apache or Linux have had more exposures. It's not a code quality issue per se. There are two issues: One is [that] IIS by default provided access to a lot of services. And the reason we did that was to make the system easy to deploy and easy to use. Generally, if you asked users if they wanted that, they would have said yes.
However, if they provide any type of exposure, you find out that there are a lot more systems because of the number of IIS's out there. One of the first things we did was issue a tool which allows you to lock down IIS, then turn off and then turn on selectively the services that you want, which dramatically drops the door on the exposures.
Secondly, with respect to hot fixes, yes, if there are a number of security exposures developed, we immediately put out a fix for them. As a result, you could have cumulative maintenance and with a large deployment, it can be time consuming to determine which one to apply in sequence or just go through them all, particularly if you haven't been keeping up with maintenance. So we also put out a cumulative pack, which took all previous fixes.
Secondly, we put Windows Update in place, which will automatically alert people of priority fixes, so you're one click away from getting the fix downloaded. And then [there's] Windows Update Corporate Edition, which will allow corporations to deal with the practical issues of keeping fixes up-to-date and, of course, educating people on [Microsoft's System Management Server], which is a mechanism for validating fix levels across systems.
What about .net? Windows .net, including Visual Studio .net, was recently delayed for a security audit.
It was part of the ongoing scrutiny of security. We're pretty open as a company in terms of saying what we're doing and when we're doing it. If there is a reason for a delay or change in schedule, we explain why.
The extra scrutiny of .net was well worth the time and money. Many of the design elements of .net, particularly the sandboxing of applications, will reduce security exposures dramatically. It features signed code and the ability to apply permissions to code. So a piece of code actually has assigned to it information about who wrote it which is impossible to steal.
It has a digest, so if [you] modify the code, even if signatures are intact, the digest won't be the same. You can actually tell that code is modified. So that there are a number of checks in the Common Language runtime, which allows isolation of the applications and a very strong checking of the access rights of code. It will be a long while before that is pervasive. But that is exactly the kind of fundamental change that needs to be made to produce secure environments.
Is the audit is complete?
Yes. [The tools] were available on the Web last week.
Are security fears overshadowing your Windows XP and Windows .net products?
The fundamental issue is that we want to get computing as safe as using electricity and as reliable. And anything that stops that is a problem for us.