Cryptogram Judges MS Security

johnfoobar writes "The latest issue of Bruce Schneier's Cryptogram has a section entitled 'Judging Microsoft' which aims to "provide a list of measurable recommendations, so that the community can judge Microsoft's sincerity." Required reading if you use Microsoft products." Update: 02/15 18:15 GMT by M : A better link is Schneier's first essay this month, which is about Microsoft's "Trustworthy Computing" initiative.

Comments

trust

[ryusen]

a friend of mine once said, "trust is a funny thing. you never really know if you can trust someone, till you find out you can't."
microsoft, right now, is in that stage. people have just started discovering that they can't trust microsoft. wheather they can or not is not the issue, but the perception of trust is ruined. it will take a long period of dilligence and commitment to prove themselves worthy of trust again. on the other hand, i kind of wish many other companies would make an honest attempt to regain our trust

Re:here goes...

[swagr]

what took them so long
why are they caring about security now, etc.

Hey who cares why or how

Microsoft cares about security becouse Microsoft cares about profit. When lack of security and stability meant lower profits, Microsoft cared.

Recall when Microsoft went after Java (the language, not the platform). Didn't work. And how's their VM compatability with 1.4 now? If "security" doesn't work out for them, what makes you think they won't switch gears and worry more about drop shadows?

Where to start.

[Matey-O]

Hoo boy, this is a good article, but these guys are spending waaay too much time in a vacuum.

Microsoft is already moving towards signing code files. While we recommend that Microsoft continue this practice, we also recommend that Microsoft not rely on code signing for security. Signed code does not equal trustworthy code, something the security community graphically demonstrated through the many ActiveX vulnerabilities. Microsoft should drop the code-signing security paradigm in favor of the sandbox paradigm.

While that's nice and all, it's hard for an operating system to do operating system things from within a sandbox, and with the single exception of a guy getting a Verisign key with the name Microsoft on it (nominally a Verisign problem, not a Microsoft Problem) I haven't seen a problem lately with microsoft signed code.

All other Microsoft features should be evaluated for resilience. Those that are too risky should be removed until they can be rewritten and secured.

The NonM$ loving folks will LOVE that soundbite, unfortunately, it's got all the likelihood of happening as having everybody shift from IIS to Apache. In any production environment, security is balanced havily with cost of implementation. NO company with any amount of entrenched custom code is going to pitch it because a security guy say they oughta. The fact that you cannot overwrite a system DLL in XP seems to be ignored. (There's a Key library, a backup directory of DLL's and the DLL in the system folder, if any of those are mucked with, the OS reacts trying to restore a safe version of the DLL, if a safe version isn't available, it prompts for a CD.)

We recommend that Microsoft add strong auditing capabilities to all products, both operating systems and applications software. We recommend that Microsoft provide configuration tools along with its operating system, as well as tools for an IT department to manage the configurations of its computers.

Granular auditing exists now! The problem with enhanced auditing is the storage requirements for that auditing. I get 'the application log is full' messages NOW, what happens when every bit written generates five bits of log? Are YOU going to have a Terabyte server to store 200 mb of data and 800 mb of granular logs?

We recommend that all protocols and interfaces used in Microsoft software be immediately published, and a one-year moratorium be placed on all non-security modifications to those protocols. We also recommend that Microsoft publish any new protocols or interfaces at least one year before implementing them in products.

Microsoft's been in bed for YEARS with the W3C. The protocols are generated there, and Microsoft is often the first to market to implement them. Asking them to hold off a year before using a new protocol is business suicide and not something they'll be willing to do.

Be careful what you ask for

[sulli]

Also give credit to the increasingly loud calls for software liability. More and more experts and industry groups and advisory panels are supporting the notion that software be held to the same liability rules as any other consumer product. It makes no sense that Firestone can produce a tire with a systemic flaw and be liable, while Microsoft can produce an operating system with a new systemic flaw discovered every week and not be liable. I think Gates sees this liability juggernaut on the horizon, and is doing his best to dodge it.

Software liability would be a disaster for free software, right? Okay, everyone wants Microsoft to have to pay for Nimda/CodeRed/Melissa/ILOVEYOU, but I don't suspect that the authors of Sourceforge (for example) would want to be liable for someone losing his code due to a buffer overflow. Schneier is right on many things, but he is 100% wrong on this one.

Security through Monopoly

[stevenj]

A point that doesn't seem to be raised much, but which I think requires the vigilance of consumers, is that Microsoft may use "security" as an excuse to further entrench its monopoly.

• Want to install a non-Microsoft program?
• Send an attachment in an open format (as opposed to MS Office)?
• Buy something from a website that doesn't use Passport?

You'll get:

Warning: this program/file/site is INSECURE and may contain a virus. We recommend consulting two programmers, a lawyer, and a priest before opening it.

Of course, Microsoft won't make it too hard to have third-party software (as long as it doesn't compete with Office). You'll just have to pay a small fee for a MS-certified crypto signature. (Oops, free software can't pay the fee? Gee.)

Re:MS02-005 cumulative patch

[Florian Weimer]

This is a cumulative patch that, when installed, eliminates all previously discussed security vulnerabilities

This is vendorspeak; "previously discussed" means "confirmed by the vendor" and not "discussed on BUGTRAQ". The phrase "all known security defects" means "all the defects we have admitted so far", and so on.