Slashdot Mirror
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.
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
I believe sex is highly over rated... unless it involves me
Nobody wants to have a secure product in which you have to manually enable all the great features because of which you bought it in the first place! Secondly, no-one has time to keep up with all the security alerts. That's why an automatic patch system is absolutely necessary.
Microsoft is being realistic. The author of this article is not.
The owls are not what they seem
This was the first I'd heard of it, though I've gone to microsoft.com and asked to be put on Microsoft's mailing list for security alerts. About three hours later, the email finally arrived from Microsoft, four days late:
What Microsoft didn't mention was that, before I got its security alert, someone had posted to bugtraq this assessment of their patch:
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?
-... ---
See this story in the San Jose Mercury. Even now, Microsoft is still treating security as a public relations problem. Their response to the discovery of security holes in their products is still, in too many cases, to deny it.
How do we know they are really going to make an effort? Microsoft PR has been full of shit since the first press release. From the Windows 1.0 release "just two months away"(when it was really a full 18 month development cycle from completion), MS PR makes promises it doesn't intend to keep, and often lies outright ("Windows ME is the fastest, most reliable Windows 9x ever!").
Btw, remember the last time MS went after something with a vengeance? I do.
Yeah, it was on slashdot yesterday. Bribing politicians with a vengence. Too bad they can't do the same thing to their customers (think "Windows is more stable...and here's your kickback to prove it!")
It's been a long time.
Everything in the article is sounds advice for security minded software and not just for Microsoft. Seperation of "data" and "code". Seperation of "package" and "protocol". Extra software is bad. Etc.etc.etc.etc.
.Net then they have the embrace the possibility they'll have to delay releasing it. How many are willing to believe MS will do this?
The overwhelming point is that this stuff is often contrary to what MS has in mind for its future software development. If they are really serious about putting security 1st in
When it comes to business vs design decisions, MS has always gone for biz.
The last time they went after something with a vengeance (the net) it was just another matter of shovelling internet features into all their products, in the gonzo MS style. Like Bruce says, security *cannot* be reached using this method. It requires a radical turnaround in attitude, method and implementation, something that might be beyond the company... simply because it's contrary to their core ethos. Securing products costs money, it slows you down, and it doesn't score points with the feature-hungry consumers.
Hoo boy, this is a good article, but these guys are spending waaay too much time in a vacuum.
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.
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.)
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?
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.
"Draco dormiens nunquam titillandus."
If your application gets labeled a "public nuisance," it doesn't matter how much the users like those features. Not if they want to interoperate with others.
This may seem like a harsh judgement, but the cost of Outlook and IIS bugs is rapidly getting to the point where a lot of admins are ready to take drastic measures to protect their own networks. That's why many sites are stripping executable attachments - and the crap like that "begin" bug discussed a few weeks ago are pushing some sites to outright Outlook bans because it's proving too costly to try to work around Microsoft's ongoing indifference to security.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Just to back you up, here's the old article
Security Community Reacts to Microsoft Announcement
by Hemos with 471 comments on Friday January 25, @11:25AM
The Counterpane article is the same as the earlier Security Focus article.
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.
sulli
RTFJ.
Microsoft is going to have to say things like: "We're going to put the entire .NET initiative on hold, probably for years, while we work the security problems out."
First of all.... Microsoft said they were going to prioritize security. That doesn't necessarily mean put all new features on hold until they are 100% secure. You can make security a priority without doing the OpenBSD nothing but security route.
Analysts like Gartner have recommended that enterprises switch away from Microsoft IIS and delay installing Windows XP, both because of security concerns.
I would like to point out that the precipitating reason they changed their recommendation was due to MS's new licensing policy. Security problems are just more fuel to the fire.
MS's security policies annoys the hell out of me but lets at least hold our points to realistic ones.
-pos
The truth is more important than the facts.
-Frank Lloyd Wright
You'll get:
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.)
If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared. S. Augustine
Look, as much as I hate Microsoft, it's not easy to write secure code, and it's impossible to write bug-free code. Because they're not currently generating revenue with bugfixes, I have a hard time believing they're intentionally writing crappy code just to reap the bugfix revenues. Yes, they always claim every new version of Windows is more stable and secure than the last, but almost nobody ever believes them anymore..
Their business model requires them to get people like us to upgrade our existing products to the latest versions every couple of years. Since you're not really getting a more stable product when you upgrade, and since features aren't the upgrade-enforcers they used to be, MS is trying to find a way to force you to upgrade. Witness their newest licensing/protection racket: Upgrade to the current version, or when the next version comes out, you'll pay full price to upgrade to it.
Until they change their business model to allow them to generate revenue for producing secure, stable code, they will never succeed in generating secure, stable, well-architected products.
"Remember the last time MS went after something with a vengeance?"
There's a big difference between putting Company ABC out of business and producing highly secure software. The former can be accomplished by the book, or by crook. The latter can only be accomplished by the book. It remains to be seen how willing Microsoft will be to do things this way, considering how unconventional they have become.
I think Microsoft has realized that their own software needs to be addressed first and foremost if they are to win the war against Linux. Of course, like in "War Games", the game can't be "won" per se. The only victory is NOT to play. Thus, the sooner Microsoft stops trying to "beat" Linux, the better for everyone.
Some consider it irrelevant that until recently, Microsoft could have cared less about security. They have hidden behind UCITA and their monolithic EULAs, all the while reducing security by increasing programmability. Their oversimplification, while giving developers more control, also gave hackers more control.
Choose to ignore facts if you wish, but your own credibility is at stake. To say what happened a year ago doesn't matter this year is just as dumb as saying this year doesn't matter once it's over. Responding to a "usual rebuttal" with an equally "usual rebuttal" isn't the best way to discredit them... or is it? You make the call.
What's a second? An hour? A day?
It has much more to do with
the Earth's rotation than with cesium.
Semi-off-topic?
An equally interesting article in Mr. Schneier's newsletter this month concerns Oracle's "Unbreakable" Database.
It seems Oracle put forth a good faith (albeit flawed) effort to secure Oracle9i. They enlisted the services of TCSEC, ITSEC, Common Criteria, Russian Criteria, and FIPS
140-1 to test for security holes. None of them detected a simple buffer overflow problem.
These security companies are a sham (or at least should be ashamed).
Remember... ZG9uJ3QgZm9yZ2V0IHRvIGRyaW5rIHlvdXIgb3ZhbHRpbmU=
MS is in a very hard position.
They've already gotten a reputation for putting security and stability last. New features, fluff always come first. Virtually everyone knows that MS lives by marketing, marketing, marketing.
Now MS realizes that Security is becoming "the issue." "It's the security stupid."
Now consider the difficulites.
MS has an enormous codebase to now fix - after the fact. Adding in security is WAY hard after the fact. Things break, testing must be redone etc. It's a whole lot easier to put in anything if it was part of the origional design. Super costly and painful afterward.
MS has "integrated" all of its' products. So, now they have to not only test the separate products, but also in every combination. Ouch!
From Firewalls and Internet Security (the God book of security IMHO)
- All programs are bugy
- Large programs are even buggier than their size would indicate.
- If you do not run a program, it does not matter whether or not it is buggy.
- Exposed machines should run as few programs as possible; the ones that are run should be as small as possible.
Now MS has what most would consider code bloat, and not only that integration. That's going to be an ugly task (securing the code)
MS has always fudged the truth before. Marketing before substance. So people will be very skeptical about MS's claims about anything.
MS's stance about security was always lax. Combine this with the prior point, and we have skeptical^2.
MS can't really use this as a marketing tool - or at least not until they can prove they've done something significant. This will be hampered by points 1 + 2, and continuing security lapses, when trying to secure that code and missing things.
MS can't really make money off security - again, at least not until it has serious results to show. Thus this will become a massive cost center without any revenue. Ouch^2. That will have the bean-counters breathing down the throats of the development/QA people to keep costs down. You're not producing new products, and thus revenue - salary will suffer etc.
Lastly, it will be a unglamorous job, and project. It will be hard work. You'll be unappreciated. You'll be expected to be a miricle worker, and double quick too. When you miss something, you'll get lots of heat, and few kudo's (Provided this _really_ _is_ somthing MS is _really_ serious about - if not the heat won't be there, but that's the point.)
Thus, to summarize.
- MS has a MASSIVE task to fix - both in size and complexity.
- MS has integrated all these things together. I would bet that the mutual distrust model between different modules/products hasn't been used, adding to the difficulty/complexity.
- MS has a reputation for producing fluffy software with lots of features, but not much security - it's always an afterthought. Ship early fix bugs later.
- MS has never been known for its' honesty and plain talk, thus making the credibiltiy of its' proclaimation that much more doubtful.
- This strategy won't be done quick, or cheap. The task will be difficult both technically and politically.
- MS won't be able to milk this decision for extra revenue anytime soon.
- The very fact that this effort exists, tends to point out a problem in the first place.
My conclusions are these.
MS may really intend to do this. I don't really believe it, but I'll give them the benefit of the doubt. But even if they are committed, how long will they remain committed. They won't be able to show results for some time. They will certainly have failures. These will undermine the confidence of both internal staff, and the public they're "selling" it to. It will cost a massive amount. It won't generate revenue.
It's going to be really easy to just splash it out there, and crow about it. Later, when the trench warfare sets in, it's going to be tempting to forget about it. It's out of the limelight, and we can just let it go quietly into the night.
We'll see - I don't doubt that MS _could_ do it. I just don't think they will for many reasons. And there will be _so many reasons_ no to.
Cheers!
How can you laugh at that? Obviously a feature needs to be secure all by itself and also be secure in the way it interacts with other features. Having a feature not be installed at all simply makes it even more secure. In fact, a feature that isn't installed is by default 100% secure. It can't be used, accesed, smurfed, or kidnapped for nefarious purposes. Thus, it's completely secure. Microsoft's practice of installing everything under the sun is probably it's biggest insecurity. Yes, you can choose not to install some stuff, but how many Joe Users install their own operating system?
--- Think of it as evolution in action ---
"Security works best when it's designed into the system from the beginning, so a lot of what they've already done is going to have to be rewritten."
This is false. XP, based on NT, has security built in. The vulnerabilities discovered so far basically seem to be in two camps:
1) Buffer overflows left in the code -- rewriting won't help these, it will likely just introduce more. They just need to be found and fixed. Microsoft is in fact going over all its code line-by-line, but I can't imagine that glassy-eyed developers spending a month doing that is actually going to find all the overflows.
2) Bad design, in particular allowing foreign code to execute. I.e. the various Outlook email viruses. These need to be removed, which is a basic change in how Microsoft thinks (security over nifty features) but again you don't need to rewrite Outlook to stop if from executing scripts by default.
Methinks Schneier might be fantasizing a bit about Microsoft *having* to do this, of saying, as he puts it, "We're going to put the entire .NET initiative on hold, probably for years, while we work the security problems out." It seems like he would like to see Microsoft fall behind in the market because they have to throw all their current code away. Plus he hates SOAP (since it sneaks past firewalls inside HTTP), which is one of the technologies .NET is based on.
Personally I think this is basically more marketing hype from Microsoft. Because they are still not going to penalize developers who write insecure code (something that was bandied about but not adopted) -- it will still be, "Oops, we did it again". So with no real connection between good code and stock options, developers at Microsoft won't change.
- adam
Back in the text-only e-mail days I was quite confident in telling to my users "text e-mail can't hurt you"...until a friend at a neighboring site (uucp) showed me what they'd found: An e-mail that ended with embedded escape sequences to program a key with a long string of commands, clear the screen, and then the something like "Mail file corrupted--press (whatever the key was) to continue."
The commands, which went back to the mail reader (or would have, if the user had followed the directions) would then 1) write the body of the message to a file, 2) exit the mail reader, 3) compile the source code it just saved, and 4) run the program.
There were a few bugs in the creature, so it hadn't worked as intended, but from then on I wasn't so sure about things being safe just because I couldn't see how to exploit them.
-- MarkusQ