Robert Scoble points us to a long post by Chris Brumme, one of the architects of Microsoft’s .Net platform. The majority of this post is about starting up and shutting down future versions of Windows, which is boring stuff.
The bottom of the post talks about security and the recent problems with security, and this is where it gets interesting.
Scoble has posted in the past about how Microsoft employees have been called to help man the phones to support customers who’ve been attacked by the various exploits. I have many friends (at least 5 here in Japan) who’ve lost all their data and had to reinstall all their apps. This is a really, really big deal and I think it will get worse before it gets better.
The important take away for me from Brumme’s post is that there is a sea-change happening at Redmond and while I do think it will take a lot more time for us to see it, things are really changing and Microsoft is really starting to work differently. Looking at how the ship dates for Longhorn (the next version of Windows) have been pushed back significantly is the most obvious reaction.
To read about the tumult and internal gyrations of a company of this size and stature in crisis is actually pretty interesting for those of us who work in large organizations that are in crisis themselves.
p.s. Reading about comments from the 1980′s in the current codebase of Windows was funny 
GotDotNet Blogs – Chris Brumme
Rambling Security Addendum
Finally, an off-topic note as I close down:
I havenÌt blogged in about a month. ThatÌs because I spent over 2 weeks (including weekends) on loan from the CLR team to the DCOM team. If youÌve watched the tech news at all during the last month, you can guess why. ItÌs security.
From outside the company, itÌs easy to see all these public mistakes and take a very frustrated attitude. ÏWhen will Microsoft take security seriously and clean up their act?Ó I certainly understand that frustration. And none of you want to hear me whine about how itÌs unfair.
The company performed a much publicized and hugely expensive security push. Tons of bugs were filed and fixed. More importantly, the attitude of developers, PMs, testers and management was fundamentally changed. Nobody on our team discusses new features without considering security issues, like building threat models. Security penetration testing is a fundamental part of a test plan.
Microsoft has made some pretty strong claims about the improved security of our products as a result of these changes. And then the DCOM issues come to light.
Unfortunately, itÌs still going to be a long time before all our code is as clean as it needs to be.
Some of the code we reviewed in the DCOM stack had comments about DGROUP consolidation (remember that precious 64KB segment prior to 32-bit flat mode?) and OS/2 2.0 changes. Some of these source files contain comments from the Î80s. I thought that Win95 was ancient!
IÌve only been at Microsoft for 6 years. But IÌve been watching this company closely for a lot longer, first as a customer at Xerox and then for over a decade as a competitor at Borland and Oracle. For the greatest part of MicrosoftÌs history, the development teams have been focused on enabling as many scenarios as possible for their customers. ItÌs only been for the last few years that weÌve all realized that many scenarios should never be enabled. And many of the remainder should be disabled by default and require an explicit action to opt in.
One way you can see this change in the companyÌs attitude is how we ship products. The default installation is increasingly impoverished. It takes an explicit act to enable fundamental goodies, like IIS.
Another hard piece of evidence that shows the companyÌs change is the level of resource that it is throwing at the problem. Microsoft has been aggressively hiring security experts. Many are in a new Security Business Unit, and the rest are sprinkled through the product groups. Not surprisingly, the CLR has its own security development, PM, test and penetration teams.
I certainly wasnÌt the only senior resource sucked away from his normal duties because of the DCOM alerts. Various folks from the Developer Division and Windows were handed over for an extended period. One of the other CLR architects was called back from vacation for this purpose.
We all know that Microsoft will remain a prime target for hacking. ThereÌs a reason that everyone attacks Microsoft rather than Apple or Novell. This just means that we have to do a lot better.
Unfortunately, this stuff is still way too difficult. ItÌs a simple fact that only a small percentage of developers can write thread-safe free-threaded code. And they can only do it part of the time. The state of the art for writing 100% secure code requires that same sort of super-human attention to detail. And a hacker only needs to find a single exploitable vulnerability.
I do think that managed code can avoid many of the security pitfalls waiting in unmanaged code. Buffer overruns are far less likely. Our strong-name binding can guarantee that you call who you think you are calling. Verifiable type safety and automatic lifetime management eliminate a large number of vulnerabilities that can often be used to mount security attacks. Consideration of the entire managed stack makes simple luring attacks less likely. Automatic flow of stack evidence prevents simple asynchronous luring attacks from succeeding. And so on.
But itÌs still way too hard. Looking forwards, a couple of points are clear:
1) We need to focus harder on the goal that managed applications are secure, right out of the box. This means aggressively chasing the weaknesses of our present system, like the fact that locally installed assemblies by default run with FullTrust throughout their execution. It also means static and dynamic tools to check for security holes.
2) No matter what we do, hackers will find weak spots and attack them. The very best we can hope for is that we can make those attacks rarer and less effective.
IÌll add managed security to my list for future articles.
Great blog. I saw your entry on viruses changing Microsoft, and thought IÌd offer a little background from inside the borg. Of course, i speak for myself and not the company. I donÌt think that itÌs the viruses changing MS, rather than the networked nature of computing changing the needs of software. In other words, the definition of winning has changed. A few years ago, winning meant having more, cooler features than the competition. Linux changed the playing field by saying Ïhey, we have less features, but at our prices you should realize how little computing ÎinnovationÌ you can scrape by with.Ó Throw in broadband internet and suddenly, having more features doesnÌt really matter as much. We also used to prioritize resources so that a feature absolutely must accomplish its original goals. Now, if itÌs late in the project, weÌd rather break the feature than allow a security expoit.
I went through the much publicized security training in Redmond, then taught it in MS Japan and am trying to lead my team into applying the lessons in our new product development out here in Tokyo. ItÌs truly amazing how 180 degrees security thinking is from traditional techie. If you apply security principles to blogs, they look like a prime target. For example, if thereÌs a political candidate you donÌt like, itÌs trivial to create scripts on a machine that uses an anonymous wifi hotspot on the net that will flood the comments areas until theyÌre unusable (or exploit a buffer overrun), add a billion trackbacks that all point to offensive sites, or constantly refresh moblog images until you run out of bandwidth. A cool feature becomes a scary feature very quickly. Anyway, you can imagine what this kind of thinking does to people like me who used to spend our days designing new features thinking that every little something makes life a little better.
But I think the reason blogs (or Linux or Macs) are safe so far and there are Windows worms and viruses so commonly seen today is that Microsoft is one of the easiest targets to hate and use to wreck havoc on the world. In time, everyone will have its trolls attacking it. Of course for the thousands of anti-ms people out there only a tiny percentage are willing to write and publish a worm/virus today so I hope I’m wrong. IÌm wishing that these viruses generate more than Ïboy Microsoft stuff sucksÓ types of comments and rather help people realize that Microsoft may be one of the first targets, but eventually these attacks will be much more pervasive. All software has holes today. And thereÌs mounds of abandoned code still being used but that nobody understands. Hopefully people start realizing that it takes a lot of effort to make attacks difficult in any software.
I echo some of the same comments that Chris has offered.
(These comments are very much my own, and not those of my employer.)
Microsoft has traditionally had a very customer-oriented, feature-oriented, scenario-oriented culture. You can see it from our very slogan — we talk about enabling people on any device. About letting people realize their potential. Winning for Microsoft has traditionally very much been about enabling people. I tend to think of this in terms of the existance quantifier in logic — the goal was to show that there exists a way to do some task “blah.”
Unfortunately, security requires a completely different attitude. It’s the antithesis of enabling people, in some ways. It’s about being paranoid. Locking systems down. About the \forall operator — for all possible misuses of this feature, there does not exist a security exploit. It really, really is a completely different way of looking at the world.
After having spent a great deal of time working on security here at MS (w/ Chris Brumme on the CLR, and the DCOM team which is in my org, and my own team), it’s become very clear to me that building a security product, is really, really, really freaking hard. It’s really hard. I’m sure that my Mac apps and most *nix apps have a good number of security holes. Look at all the exploits that have been found in bind. Or wsftpd. Etc. Writing secure code is really hard.
I think we’re doing a really good job internally redirecting ourselves down a new path. We invest a lot of time looking at security. And I really think managed code will be a great boon for security. (We go through an elaborate process of threat modeling for every feature we ship now. We formally decompose our features and analyze the threats to the product. We sometimes find some pretty interesting, subtle ones (and fix them …). But, really, most of the security exploits that bite us are all buffer-overrun related.)
Ultimately, I don’t think we can ever put in place enough human-controlled processes to find every security bug in our products. We need to find ways to close off entire avenues of bugs (e.g., managed code), make patching much easier (e.g., better windows update), and come up w/ better tools for blogging worms / virii in the network. But, as you say, give us time. I think we’re getting there.