Slashdot Mirror
Security Community Reacts to Microsoft Announcement
A number of readers have collected stories concerning the change of focus by Bill Gates to security. Bruce Schneier and Adam Shostack have written a piece, while Crag Mundie of MSFT has also chimed in, along with some commentary from ZD folks. SecurityFocus has other words, as does InfoWarrior.
It seems to me like MS are doing this just to counteract the recent bad press they have got in the security area.
I have said it in the past, and I'll spew it backup now for those who missed it, MS do not make the best software - bu they do have the best marketing department and business sense.
It seems that the various tones of the above mentioned pieces reflect a Microsoft good or Microsoft bad attitude. Unfortunately, the problem being discussed transcends the usual polemics of such a debate. Good security, whether from Microsoft, Sun, Novell, Cisco or others, is in everyone's best interest. If Microsoft has finally awoken to this fact, good for them. Their previous security through obfusication was a travesty and insulting. If my personal information is going to be stored on a computer that is linked to a network, I want the best damn security money can buy. For that computer, for the database software, for the firewall, for the remote machine at the local insurance agency that is accessing the info, et. all.
True Names are important for a reason.
...says:
But we're still in the early years of the computer revolution, and there are many technological, social and regulatory hurdles we must overcome before computers truly become a ubiquitous--and essential--technology.
The early years? No. When you've got one person on top who can't get their sh*t together...
I mean, we could be farther along in this 'revolution' he speaks of. Why aren't we? Because the Big Guys [read:Microsoft] are doing what they want to do. Why are they now only focusing on security?
Oh! Pick me! I know! --- Because they do what they want to do, and that's it. They don't give in to customer demand; most of their product is cooked up by visions that Bill and others have.
Get your Unix fortune now!
Cringley has a good piece up on this as well.
Separate Data and Control Paths
Use Secure Default Configurations
Separate Protocols and Products
Choose for Security over Features
Make it Transparent and Auditable
Give advance notice of Protocols and Designs
Engage the community
All that stuff sounds great, but I can say the same thing in far fewer words:
Start from scratch. Do it right this time.
The first thing Microsoft is going to do under their new "security first" paradigm will be to announce that due to security concerns, they can't tell us what any of their security upgrades actually are.
Windows is too backwards compatible, IMO. Too much building off of old stuff. Microsoft needs to make a new version more or less from scratch, like Apple's transition from the old Mac OS to OS X. It isn't a quick or easy transition, but it will pay off in the long run.
I guess that's the problem when you are a huge software company trying to appeal to everyone. You end up supporting everything and it turns into a big mess.
mark
If you want to make an apple pie from scratch, you must first create the universe. -- Carl Sagan
Let's wait and see, announcement are just words, let's see how they will react when there's going to be another big security hole (because there always are going to be, and that on just about any platforms, but especially with Microsoft), if they've really changed philosophy, they will react more quickly (as in programmer-wise and not PR-marketting-wise), and not handle this as a press release taking their customers for complete idiots and reacting immaturely blaming people that finds the bugs as "terrorists".
And anyways, for those of us that are on some security mailing lists like NTbugtraq, we'll see how the people got their discovery handled by Microsoft, if they change for real, maybe we won't read as many "We notified microsoft 3 weeks ago about this matter and nothing was done, now it's time to bring it public" and then having the Microsoft PR and legal team on their back.
I think they are starting to feel the heat of people that are really not satisfied and claiming that buisness damage due to insecure OS should be fined to the creator of the OS, especially when they claim it's secure. Heh.. good thing.
--- Metamoderating abusive downgraders since my 300th post.
Someone brought this up in another article, so I can't take credit.
The settlement with the DOJ specifically allows Microsoft to exclude documentation of APIs that relate to security. This new initiative makes damn near anything in some way relate to security. Gotta love it.
I would look for MS to make at least two major acquisitions in order to shore up their security offerings - they have used acquisitions in the past to shore up problem areas.
Of course the caveat is that they are not so much concerned with security as an intrinsic value but in the selling of security, and there is an important distinction here. As with any growing software market, you can't underestiamte Microsoft's efforts, and I think it is largely naive for the readership here to snicker and write off MS in this regard.
Usually, Bruce Schnier writes good stuff, and I enjoy reading it. This time, though, the piece is riddled with misinformation and poor advice. I'm surprised.
SOAP isn't just a Microsoft protocol, for one, but the main problem with that paragraph is that SOAP was not designed to elude firewalls, any more than RPC was. SOAP is just an RPC mechanism that happens to flow over HTTP, mostly because Dave Winer only knows one protocol -- HTTP. Mr. Winer didn't try to evade protocols, he just couldn't conceive of creating a different protocol for this application -- an error of omission, not commission.
In terms of file and media distribution, the function of a HTTP server, FTP server and gopher server are very similar, so there's actually some sense in bundling the three together (and MS isn't the only group to do this). The security problems come when dynamic execution is added to the mix in HTTP. Mssrs. Schnier and Shostack desperately want to undo this, but they don't have the right answer -- the problem isn't stocking the three protocols together; it's that the Internet gave us three ways to do the same thing. To really address the security issue here, we should probably go back and redo the protocols so that dynamic content and media content flow over separate protocols, but there's no chance of this happening -- HTTP didn't kill FTP, and even gopher is making a mild comeback, so we're stuck with this mess for a long time.
There's some good advice regarding security in that article, but the authors' notions of product design are off-target, and contrary to the direction a lot of folks (even those beyond MS) are taking.
Bottom line is, words are easy. I'm going to wait to see the action.
Chris Beckenbach
I once heard a story about the Denny's restaurant chain. I'm not sure if it's true but the moral is. The story goes like this.
Apparently, Denny's had intended to be a 24x365 operation, never closing its doors. Therefore, when they built the restaurants, they didn't bother putting locks on the doors.
One year, they decided to give their employees Christmas day off. In order to close the restaurants, they needed to be able to lock the doors. Therefore, they had locksmiths go out to all of the stores and install locks.
Now, instead of having spent about $10 per door when the store was built to have locks installed, they needed to send locksmiths to all of the stores and pay them for a couple of hours work resulting in a cost of a few hundred thousand dollars to give their employees a day off.
The moral: It's a lot easier to design security into a system in the first place than to try to add it on later.
Microsoft has their work cut out for them.
Step 1: Embrace some technology.
Step 2: Extend it in proprietary ways, locking the users in to Microsoft.
How long before we hear,
How long before the security protocols used are known only to Microsoft (for security reasons, naturally)?Three months—at the most!
This reads alot like the dilbert where dogbert is a consultant and says something to the effect of "I'm going to make a bunch of recommendations that I know you are too cowardly to implement. Later, when you fail, I'll laugh at you for ignoring my advice."
25% Funny, 25% Insightful, 25% Informative, 25% Troll
What really scares me about this is the talk about taking desktop control away from users, the one thing MS has always been good about in the past.
Billg says:
"Security: The data our software and services store on behalf of our customers should be protected from harm and used or modified only in appropriate ways...It should be easy for users to specify appropriate use of their information including controlling the use of email they send."
Of course, this new "secure" email won't work on those unamerican Linux computers.
Am I the only one nervous about that?
"...they've helped transport people to the moon and back safely, they manage critical aircraft systems for thousands of flights every day, they support business operations at companies of all sizes, and they move trillions of dollars around the world to keep the global economy"
It's a shame that none of these run Microsoft software. MS didn't exist in the 60's (moon landing), has nothing to do with aircraft systems (most still in use run on late 70's mainframes and mini's), and god help the bank/brokerage who runs their mission critical software on an Wintel platform. End flame.
Mundie does have one idea right though; make it ubiqutous (sp?). He indicates computers should have the same reliability that requires no thought. I agree whole-heartedly. However I don't believe MSFT can do it without rewriting the whole damn thing over. I cannot count the amount of times an NT server had to be manually power cycled because a service hung and wouldn't restart. This wasn't some oddball, third party service; this was IIS ("WWW Publishing Service" I believe) Until simple things like the separation between kernel and application (EVERY application, no exceptions for the ones you need to tweak for benchmarks) is complete, NT will have problems
Toodles
Toodles D. Clown
I thought that looking at these two articles provided an interesting comparison. Mundie's idea of "trustworthy computing" is a world in which people don't think about the technology that makes their computing devices work. This seems to me to be pretty much the same philosophy that Microsoft has followed for a while now, ie lowering the level of knowledge required to operate computers.
By constrast, in the Schneir article, the viewpoint expressed seems to me to advocate people getting involved in the operation of technology. More configurability, plus more modular components, more transparent auditing/logging of OS functions etc. In the author's view, users should be aware of what their computer is doing.
This is the fundamental problem with Microsoft's view of security. Their focus on making things transparent to the lowest common denominator is at the root of all the architectural problems from lack of logging to Outlook viruses arising from scriptable email. They need to change their view that people should just view their computers as mysterious black boxes before their security record will ever improve.
SOAP is designed to use HTTP/HTTPS as the most common implementation of transport and protocol underneath. Schnier and Shostack touch on how poor a decision this is. I think this goes a lot further than many developers and companies are realizing.
You just removed your firewall.
The idea of SOAP is to allow IT services to be exposed as remotely addressable and usable procedures. Essentially with every web service or SOAP receiver, you have written a brand new server that parses XML protocol messages to decide on action. Thus every web service you create may have overrun, DoS and other exploits inherent in it, in your code, as you are executing paths based on a message from the outside. Just like a web server, ftp server or any other available server.
So now, everyone has to become better at security, to the point that the web services are safe. Ideally they should all run within a sandbox environment with restricted permissions, but considering SOAP authentication is based on HTTP authentication, the models may or may not match up properly.
Most importantly is that the SOAP specification team, including MSFT and the .NET portions pertaining to web services have basically increased the difficulty of every network administrator's job by stuffing all this over port 80.
Now if there is a vulnerability in a web service, the network admin has to take out port 80, probably taking down the web service, the web server, and who knows what else that's been tunnelled through there. They can't simply block a set port. UDDI could have advertised a port for the service as well, and stateful inspection could be implemented at some level on each service port to increase security and leverage off of the firewalls. Instead, a rat's nest of information is getting funnelled through http/https. The firewalls aren't designed for this, and the inspection task is only going to get more difficult as SOAP grows in popularity.
MSFT is always looking at first to market, and I can almost assure you that for that reason, SOAP was designed around port 80 and into the web server engines. I can also say with a fair bit of confidence that the first time MSFT gets beat to market due to a security review, that the security priority is going to get thrown right out the window of the executive windows at Microsoft if it causes the stock to slip.
As an example, we wrote a test app with a different foundation class library that was bug- and memory-leak free in all of the major WinXX OS's up through 98 and NT 4), and even compilable and bug free back into Win 3.XX. The whole app was a total of 123K: the Microsoft Foundation Class (MFC) [version 3.2, IIRC] test app as created by the wizard came in at just over 1 Meg, riddled with memory leaks, logical errors, etc. Our determination was that it wasn't just a bad wizard -- the MFC itself was causing many of the leaks and problems.
Now then, if you look at the Win API set now (Y2002), it is just that much more massive than when I last actively coded to it -- but the underlying code classes look much the same. [I haven't done a diff, so I can't prove it.]
So accurate or inaccurate, I don't think Microsoft has the corporate will to change from a company built on FUD (fear uncertainty doubt) to a company whose software is something I can trust because it doesn't even look to me like they have fixed all of their original problems in the foundational code classes from the early days of Windows 95.
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
The problem is that an alarmingly large number of people cannot distinguish between the following:
What has happened to the software industry in general is exactly what has happened to the American political process. If you make promises and then cash the check, it doesn't really matter if you deliver. The reason is that people are gullible.
So you think, "gosh, wouldn't it be great if they've finally decided to do it right." But they haven't done it; they've just said that they are going to do it. Any support for mere words on the hope that it might come to pass will remove any incentive for actually doing it.
Most people get off so much on the hope and the promises that they don't realize how they're encouraging integrity-challenged behavior with their actions. It takes a real cynical bastard not to get caught up in this, and then we get told, "Oh, you Microsoft Bad Religious Types."
This one kills me. From Craig Mundie:
"Many people today are still reluctant to trust computers with their personal information, such as financial and medical records, and few people would knowingly entrust their lives to them"
Every time you fly on a plane your life is in the 'hands' of computers. Every time someone gets an x-ray or a CT scan or any one of many now normal medical procedures you are entrusting your life and health to computers. Most (if not all) medical and financial records are entrusted to computers.
We do it everyday and the reason we do it is because these devices are designed and built by companies that have earned our trust by building quality products to very strict specifications for safety. These companies have good track records of safety and if they have problems then they are reported.
What Mr. Mundie should have said is:
"Many people today are still reluctant to trust Microsoft with their personal information, such as financial and medical records, and few people would knowingly entrust their lives to Microsoft."
--
-- Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
It would be good if the people who spend so much time attacking Microsoft's security issues considered that UNIX generally and Linux in particular are not exactly fault free.
How can anyone who runs sendmail throw stones at Microsoft? sendmail is a textbook case in how to write software that can never be secure. The program breaks every single one of the rules Bruce and Adam set out. There are plenty of better alternatives, yet sendmail remains the default through sheer inertia (you might want to route some bang path UUCP or OSI mail sometime you know).
UNIX only became secure as a result of trial and error. There never was a security architecture worth a damn. For many years the main contribution to the security world from the UNIX security architecture folk was discouraging people from using shaddow password files.
The security model of all modern operating systems is based on the security model of MULTICS and comes from the age of the Multiple Access Computer. The security problem is defined in terms of a single machine that has multiple concurrent users. The addition of the network is an afterthought.
What this means is that very few of the security features in a modern O/S are actually of the slightest relevance to a machine running a Web server. In effect we end up with two parallel permissions structures, the one managed by the O/S and the one managed by the Web server.
Win2K and XP have Kerberos and PKI integrated into their core. The standard condfiguration supports IPSEC, S/MIME, SSL, Kerberos, Smartcard login, Encrypted File system. Measuring security in terms of cryptographic features Microsoft wins hands down (Microsoft are good on features).
Linux on the other hand is not in anywhere near such a good position. Security packages are available but it is left to the end user to integrate them. Linux also lacks anything that resembles the 'Security Administration Guide' mentioned in the rainbow series books.
Security is not a binary condition. The problem I see for Linux is complacency. There are too many weenies out there whose knowledge of security is actually minimal who tell people Linux is secure because that is what they have been told. None of the O/S on the market are particularly secure. Windows has a great security architecture that the crappy applications completely bypass. UNIX has a crappy architecture and some very well tested applications whose security bugs have been largely eliminated by trial and error.
People in the OSS community can go arround telling each other that Linux will always be more secure than Windows if they like, but that won't make it true. Gates has essentially served notice that Microsoft is going to be upping the ante here. That does not mean that they will win, but a lot of work is going to have to be done if Linux is going to keep up. Fotunately it is not necessary to integrate PKIX into Linux as Microsoft did with Windows, the OSS community could skip a PKI generation and move straight to using new technology such as XKMS and SAML.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/