Interview With Microsoft's Chief of Security 245
Paul Coe Clark III writes: "I interviewed Howard Schmidt, Microsoft's head of security, questioning him about, among other things, cyberterrorism and Redmond's responsibility for insecure features in the wake of many virus attacks.
/. readers might find it interesting. They can find it here."
USA Patriot Act (Score:3, Informative)
Full Bill:
http://www.politechbot.com/docs/usa.act.final.1
EFF Analysis:
http://www.eff.org/Privacy/Surveillance/Terrori
Re:Contrary to popular belief (Score:4, Informative)
Ironically, you can find a lot of good information about this in a Microsoft Press book: Writing Solid Code by Steve Maguire. As Maguire points out, leaving your bugfinding to the testers is folly.
Re:They're trying (Score:5, Informative)
You think they are making strides to clean this up? Looks like patching the PR to me. Take a look at this...
MS rolls out security obscurity bribe program [theregister.co.uk]
[microsoft.com]
Code of Conduct:
Microsoft Gold Certified Security Solutions Partners are leaders in the security industry, not only in their products and solutions, but also in their standards of behavior. All Microsoft Gold Certified Security Solutions Partners shall follow a code of conduct regarding the responsible handling of security vulnerabilities. This code of conduct is intended to allow a product vendor to address any individual vulnerability and issue a patch, workaround or other response to the public. Microsoft Gold Certified Security Solutions Partners shall take reasonable steps to ensure that they do not publicly disclose details that would directly allow an outside party to develop or execute an attack exploiting the vulnerability.
Nail on the head. (Score:3, Informative)
So...who cares if there are problems. We'll find them eventually - as soon as someone exploits them and we hear about it.
Precicely.
If you want bug-free code you need to start at the architecture/design process (avoiding bug-prone choices), then debug as you go. It's like growing a perfect crystal - you push the impurities out as it solidifies, so only the boundary needs attention. The longer you wait, the larger your search space for each bug, and the bigger the hive of ofspring each bug has produced as new code was added to buggy code.
Security issues are a special case of "bugs", with more than the typical amount of effort needed at precoding stages to avoid building unfixable problems into the basic architecture.
I wonder if they release their code like that for QA as well. It's a matter of identifying bugs once the product is released.
My impression is that Schmidt is completely unaware that software QA, or any other pre-release potential for (securyty) bug suppression, exists. At a minimum his statement implies that Security as a department doesn't participate in architecture, design, code reviews, or QA, and that its leader either feels no need to do so, or is deliberately directing attention away from an inability to affect those stages.
That the head of security for Microsoft could emit such an answer is appalling. But it also goes a long way toward explaining the security problems in Microsoft products.
Re:The obvious full disclosure question (Score:2, Informative)
Re:Contrary to popular belief (Score:3, Informative)
I find the USS Yorktown [sciam.com] still a pretty good example when people start thinking about using Windows in a mission-critical application.
Re:The obvious full disclosure question (Score:2, Informative)
How people *feel* about this issue is irrelevant. Full disclosure, for all its faults, has worked better than just telling the vendor or a select few. Generally what has happened when vulnerabilities were kept quiet was that the vendor sat on the problem or took care of it at its leisure, leaving systems open for crackers who could and did silently exploit the vulnerabilities. Full disclosure 1) lights a fire under the vendor so that it actually *does* something, and 2) allows others a chance to find ways of coping with the vulnerability until a fix comes.
This is not theory; it has been shown to work in practice.
comparing Microsoft's performance over the years (Score:5, Informative)
The last 3 security vulnerabilities for XP relate to IE, Windows Media, and USB plug and play feature.
I should say that the products of Microsoft are just becoming mature right now. It is unfair for Linux and Unix since they I believe they have been ages before Microsoft introduced Windows. So it terms of maturity, Linux took years just as Microsoft is.
Like in service packs, the Windows 3.51 had around 13 (or more if I remember correctly.) Windows NT4.0 had 6 (the 7th was not released officially.) Windows 2000 now has 2 (and they are releasing SP3 Q1 2002.) There is WindowsXP although there is no SP around (I believe it may be in the alpha stages.) The number of service packs that is released actually decreases due to the maturity of their products. And most people even some *nix guys say that WindowsXP is actually more stable than ever.
It is also noteworthy to say that the base OS of Windows is getting more secure. It is just the apps integrated with the Internet that have most of the security threats like IE, Outlook, Office. For the servers in W2K, the services are the ones problematic and the user has the freedom to deactivate some and use an alternative. Like in Linux, the same thing applies where a server may use the services from different publishers.
I am not saying that Microsoft is good or anything but I say that comparing Windows (PRO/HOME) and Linux/Unix is like comparing apples and oranges. They are built for different purpose thus designed differently.
In the server arena, I think that it is only in Windows 2000 that they released their 1st server OS and not in Windows NT 4.0. Their Windows
Re:The obvious full disclosure question (Score:3, Informative)
No need to discuss that point on bugtraq, everybody in the web industry knows about it.
I found that bug (or feature, according to MS), months ago (even years maybe), when trying to generate on-the-fly pdfs as part of the web application i was working on. I think that almost any engineer or prgrammer working on web sites should know it. This is not a problem of security by obscurity, but a problem of unsecurity by stupidity (from MS).
In fact, this is an argument to null the whole "security by obscurity" strategy. When every engineer or programmer knows about the bug, then there's no obscurity anymore. And with many of the security bugs found on MS OSes, it's what indeed happens, sooner or later. In fact, i think this is what happens with most software, not only MS', and that's why it's not responsible from them to use such a strategy.