http://www.pcworld.com/news/article/0,aid,63784,00.asp Kim Zetter, PCWorld.com Thursday, September 27, 2001 Scott Culp is program manager for Microsoft's Security Response Center, which investigates reports of security holes in Microsoft products and oversees the creation and distribution of patches and security bulletins for users. We spoke with Culp about the increasing problem of security holes in software and about the steps Microsoft takes to test products before releasing them. PCW: Tell me what Microsoft does to produce secure software. Culp: You start off with security in the design. Then you're relying on good coding practices and on compiling tools to help you catch as many errors as you can. Once implementation is done, you have testing of the whole. PCW: Is there a built-in timeframe for testing? Culp: Actually there isn't. That became implemented with Windows 2000. What we did with Windows 2000 was we said, if it says "security" anywhere on the bug, then ship-schedule be damned. PCW: Are you saying that in the past, you shipped previous versions of Windows with known security bugs? Culp: I wouldn't say that, but what I would say is that there are always trade-offs between the schedule and the quality bar. Any software vendor is going to make a call at some point about: Have we achieved a sufficient level of quality? And understand that you'll never get to zero bugs. At some point you have to cut the cord and ship. What we said with Windows 2000 was that we were exempting security bugs from that engineering trade-off. The right number is zero, and we won't ship until we get down to zero. PCW: But from that statement about Windows 2000, one would assume that in the past you did ship with known security flaws. Culp: There are different degrees of security bugs. [You have to ask] is this a bug, for instance, that allows someone to take control of a system? That's obviously a serious bug. Is this a vulnerability that can only be exploited if I can put my hands on the machine that I want to attack or can I attack it from across the Internet? In the past what we did was put all of those factors together and we said it is acceptable to ship with a certain number of low-severity, very-difficult-to-exploit security vulnerabilities. Starting with Windows 2000, if it says security on the bug, it's got to be fixed before it goes out. PCW: If you're now taking more time to test, why can't your staff of well-trained testers and coders catch the bugs that hackers and bug hunters catch? Culp: Accurate security testing is very difficult--not just for Microsoft but for anybody. You can't rely on code review alone to know that you've got the security of a system right. The only thing you can do is to try to emulate usage patterns and identify bugs that way. There are people who will use the product in ways that we just didn't conceive. That's how many of those bugs are found, in very unusual scenarios. PCW: But hackers tend to try the same types of exploits over and over again. Why can't Microsoft emulate the way hackers think and figure out what they would do with the product? Culp: We actually do. PCW: Then why aren't you finding the bugs that they're finding? Culp: There are always going to be tests that we miss, there are always going to be implementation errors that we're making. We learn from people like [hacker and security consultant] Rain Forest Puppy; we work with them to find out what they're trying that we haven't been trying. We incorporate that into what we're doing moving forward. What we do that is different from virtually every other vendor is that we don't hide them. If we make a mistake, we tell the whole world about it. PCW: Isn't it more the case that you've been forced not to hide it? Without full disclosure about holes, Microsoft in fact, has been silent in the past about problems with its products. Culp: Not for an awful lot of years. The response center is about four years old. You can make an argument about what our practices were before then, but the whole point in creating the response center was recognizing our responsibility to our customers and that our position in the market incurred a certain amount of extra responsibility. I can give you a couple of examples. We had a vulnerability--I think it was in bulletin #36--that could allow someone to change a password under some fairly restricted conditions on a Windows 2000 server. The way we learned of that issue was that a customer sent a note to Russ Cooper, who runs the NT BugTraq mailing list, and said he found something that looks like a security vulnerability. Both Russ and the customer said, "I don't think you should make it public. You should fix this thing transparently in the next service pack and include this fix as a patch for a different issue." But if we fold this issue into a patch for a weenie issue, there are people who are going to read the bulletin and say "I don't need it" and they're not going to get the protection that they need. The second example is one that we found internally, in Windows 2000. We were the only ones who knew about it. We fixed it in Service Pack 1 for Windows 2000, and a lot of people were picking it up. But there are people who don't pick up the service packs. For instance, they may have long testing requirements in their organization before they roll a service pack out into their network. And we decided that this vulnerability was sufficiently serious that we would rather write a bulletin, issue the patch, and tell the world about a vulnerability that no one in the world knew about, rather than taking the chance on some customers not getting the service pack. PCW: There are some bug hunters who say that when they've reported vulnerabilities to Microsoft, the company has ignored them. Culp: We answer every e-mail we receive at secureat_private ... Sometimes we check out reports and we say I'm sorry, this is not a security vulnerability. And sometimes they disagree with us. And then we have a discussion. Sometimes we wind up agreeing to disagree. But we never ignore any report that comes in to us. PCW: There is concern among the public that there are a lot of safety regulations for other products on the market--drugs, cars, and so on--but that there aren't the same kinds of quality and safety standards applied to software. Culp: Even something that we've been doing for a very long time still has a failure rate. Even cars, that we've been building for well over a hundred years, still have problems every so often with the engineering. We've been building operating systems and computer software packages for about 35 to 40 years. Not very long at all. And they are the most complex things that humanity has ever tried to build. PCW: A rocket scientist might disagree with that. Culp: One of my computer science professors was really fond of a study that announced the three most complicated things that humanity had done at that time were: Number three was the Apollo moon shot, number two was the Bell switching system, and number one was the PL1 compiler. [Programming Language #1; a compiler is a program that translates a high-level computer language into instructions a PC executes.] PCW: So if operating systems are the most complex things that humanity has ever built and we can't expect them to be secure, then what do we do? Culp: You build a response process like what we've got. You say I'm going to make this product as good as I can. I'm going to constantly improve my engineering practices and be state-of-the-art in terms of engineering and in testing my product. And I'm going to recognize that I'm never ever done--that this product, during its entire lifetime is going to have additional bugs, and I've got to repair them. In Office XP there are two features that are also going to be in Windows XP. If Office crashes on you, it says it would help Microsoft build better products if you wouldn't mind sending data on this crash to Microsoft. It won't send any personal information. That will let us figure out what the problem is and make the product better. The second thing we do is that we have an automatic update that comes out every month and includes all of the fixes that we've found because of all of those bug reports that are now being automatically sent in. So once a month you can get an automated notice that says we've got the July Office XP update, would you like it? If you want to see everything that it fixes, here it is; otherwise, if you just want to take it, just say yes and we'll drop it down. We're heading toward the idea of self-healing software. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Thu Oct 04 2001 - 03:58:48 PDT