Fog Creek Software
Discussion Board




Is Microsoft's Trusted Computing working?

Is Microsoft's Trusted Computing effort to improve quality and security paying off?

First on the quality issue: I've been running XP Pro for a year and a half at home and have had only 2 problems. One was after an installation of some software. The software was hogging ~99% of the CPU time, so I had to revert back to a restore point. The second time another application locked and when I shut it down, the office shortcut bar disappeared. Really this is small potatoes compared to all the problems I've had with 95, 98, and NT.

Second is the security issue: Microsoft has issued a lot of bug patches in the past year. Are they making pretty good headway, or do they still have gaping holes due to the fundamental design of the architecture and virus portals like Outlook?

Of course I'm trying to get some serious opinions here, but I also know that I'm chumming the water for the anti-MS sharks.

Nick
Monday, July 21, 2003

I'm not exactly sure what you mean by "paying off".

Do you mean "has the massive dollar investment of putting the entire Windows and Visual Studio organizations to work for three months doing nothing but security reviews produced a financial return for Microsoft?"

If that's what you're asking, clearly it is far, far too early to tell.  Those sorts of massive investments can take years to show a real return.

If that's not what you're asking, please clarify the question.

Thanks,
Eric

Eric Lippert
Monday, July 21, 2003

"I'm not proud," Valentine said, as he spoke to a crowd of developers here at the company's Windows .Net Server developer conference. "We really haven't done everything we could to protect our customers ... Our products just aren't engineered for security."

You cannot send people through training, part time for three months and expect the results to change.  It is a culture whereby people are rewarded for the feature/functions that get into the final product.  The more the better. 

When the reward system is "you introduce a security flaw you, the QA team, and your management team lose their bonus."  then they are serious.  But they cannot do that.  It is not that important to them.  Other than bad PR, and certainly a desire to do better, what has it hurt them?

MSHack
Monday, July 21, 2003

> You cannot send people through training, part time
>  for three months and expect the results to change.

I'd qualify your statement.  You cannot send people through training and expect results to change _instantly_.  The payoff of such a large cultural change takes a while to work through the system.

But it _is_ working through the system.  When I go to a code review for a new feature now, the first questions people ask are usually something along the lines of "Have you run fxcop over this code? Can this assembly be called from partial trust? Does it assert any permissions? What error messages will we produce if called from partial trust?"

Two years ago hardly anyone knew what those questions even meant!  Now every spec we produce has security scenarios and threat models built into it, and the code does not get shipped until the team managers sign off on the threat model.  We are constantly developing new tools to perform security audits, and I take every opportunity I get to talk about security with my customers.

In short, I take the security of my product _very_ seriously.  I am not a voice in the wilderness here!  We all do.  (Though I may be a little more _vociferous_ voice than most -- one day a couple years ago I walked into a meeting with my coworker Peter and someone said "look out, here come the Security Twins!")

>  It is a culture whereby people are rewarded
>  for the feature/functions that get into the
> final product.  The more the better. 

I'd be fascinated to know where you heard this.  Perhaps there are some teams at Microsoft like that -- after all, there are a lot of teams here and I only work for one. Mine isn't one of those -- not even vaguely!  I'm rewarded for putting high quality implementations of the right mix of features into the right product.

So I'm curious.  Where did you get this particular idea from?

For that matter, where did you get the idea that Microsoft is one culture?  The corporate culture in, say, XBox is rather different from the corporate culture in, say,  Exchange Server.  From which teams are you generalizing?

> When the reward system is "you introduce a
> security flaw you, the QA team, and your
> management team lose their bonus."  then
> they are serious.  But they cannot do that.

An interesting opinion.  Your approach suggests that a culture based on blame and team-wide financial punishment for the mistakes of a few individuals would work well to eliminate flaws.

I'd be interested to know how much experience you have in setting incentive budgetary policy for large software development teams, and whether this approach has been successful for you in the past.  I know very little about budgeting, so I'd be happy to hear your insights.

Thanks,
Eric

Eric Lippert
Monday, July 21, 2003

Eric -- Good point.  Let me clarify.

> Where/who told me about the feature/function system.
  - Microsoft employees.  And as not to cause them heartache, I will generalize as "server".

> Security Practices
  - Your questions point out the nature of the issue. Yes, few people knew what to ask, but few still know what they mean.  The security issues arise from programming errors, not failure to accept security as important.  That people are asked is good.    Valentine was correct.  The code was not engineered that way, so it _may_ prove impossible.  That people are working to make a system that has problems bulletproof, while not impossible is far more difficult than enhancing a system where security is at the center. 

> Team Blame
  - If your boss says "XYZ" is important and he determines your raise, bonus, etc.  then "XYZ" is important to you.  If he says "XYZ" is important and the corporation says "PDQ" is more important than anything else is, "XYZ" is still more important to you.    I was disappointed to see "the mistakes of a few individuals".  While sometimes people are the problem, there exists an entire infrastructure to ensure their problems do not make it out the door.  If it is important, everyone in the ladder that put such a change out to the world carries some of the blame.  As a leader you do not get to claim all the success and blame all the failure. It is a team effort and everyone needs to make a better team.

MSHack
Monday, July 21, 2003

Eric,

While the interview was about eight years ago, Bill Gates did say, "The new version - it's not there to fix bugs. That's not the reason we come up with a new version."  Later on in the interview: "There are no significant bugs in our released software that any significant number of users want fixed."

http://www.cantrip.org/nobugs.html (from this Google search: http://www.google.com/search?q=FOCUS+interview+Bill+Gates&btnG=Google+Search&hl=en&lr=&ie=UTF-8&oe=UTF-8)

Granted, things have probably changed, but it's probably these two quotes that give the impression that Microsoft does not readily care about fixing bugs.

Sean Conner
Monday, July 21, 2003

Sorry Eric. I posted this topic this morning but haven't had a chance to check back all day.  By "paying off" I didn't mean in the monetary sense. I meant has Microsoft been effective in their efforts? Microsoft has released a lot of security alerts with patches this year, and every time they do there are a number of sites that portray it as evidence of their poor quality. I tend to look at it the other way around - hey, they're working to improve their quality. So, while others may be too cynical, perhaps I'm too optimistic. The bottom line is, are all the security patches having a significant impact?

Nick
Tuesday, July 22, 2003

I think my personal perception is that "Trusted Computing" is kind of a mixed bag. It's great that Microsoft is finally taking an interest in security at the corporate level, but the overall stability of my Windows 2000 machines has decreased, rather than increased as a result. A lot of things just aren't as dependable as they use to be - filesharing and the "scheduled tasks" control panel, to name two examples.

A lot of the security problems that Microsoft is fixing weren't even a potential problem for me, safe and snug behind our company's firewall.

Microsoft's new strategy of frequent patch releases also puts independent software developers into something of a bind. Under the old strategy, you would have to test your product against all the releases of Windows you wanted to support, plus the last few Service packs for those releases. Now, there's an essentially infinite number of permutations of every Windows OS...

-Mark

Mark Bessey
Tuesday, July 22, 2003

There is absolutely no doubt that the present system of frequent patches is sub-optimal!  It is extremely expensive for us, for our customers, for developers and testers, etc.

Before I get into some of the ways to mitigate this problem, let me take this opportunity to point out that the same day that Microsoft announced the recent RPC bug, Red Hat announced fixes for EIGHT kernel vulnerabilities and a "gaping hole" level Mozilla vulnerability.  Microsoft is hardly alone in the patch-issuing business! 

But since Microsoft has a large installed base of mostly non-technically-inclined customers, every patch is news.  Red Hat patches go to a relatively small number of technical people, and do not make headlines.  So there is a media bias there which is important to take into consideration.

To actually answer your question: clearly only time will tell, but I strongly believe that we are on the right track towards eliminating this problem of frequent patches.  There are basically three mitigating factors that come to mind:

1) An improved corporate culture; everyone is far more attuned to security issues now than they were a few years ago.  This means that we hope that (a) lots of existing security problems will be found now and patched, and (b) fewer new ones will be produced in the future.  You should expect the "find rate" to be large for a while as we continue to work through the codebase.

2) Increased use of managed code.  Managed code does not get buffer overruns or heap overruns.  Managed code has security metadata built into the model at a very deep level.  Entire classes of bugs have disappeared from my code since I started coding almost entirely in managed code. 

3) Improved patching mechanisms.  This "go to windows update and get the new patches" thing is better than running batch files, but what we really need is a way to declaratively express per-enterprise software update policies that can run predictably without human intervention.  I personally am doing some research in this area that I can't discuss in detail right now, but rest assured that lots of people are thinking hard about this problem.

Eric

Eric Lippert
Wednesday, July 23, 2003

"But since Microsoft has a large installed base of mostly non-technically-inclined customers, every patch is news.  Red Hat patches go to a relatively small number of technical people, and do not make headlines.  So there is a media bias there which is important to take into consideration."

And this is one extremely frustrating situation for the technical Microsoft customers. We constantly have to hear the "but Microsoft software is so buggy" crud being trown in our face by the clueless "non-technically-inclined", who then go on to push exactly the stuff we know is even worse.
Don't get me wrong. Microsoft products do have their flaws, and a good deal of them sometimes. But they are certainly not below industry average in this respect.

Is Trusted Computing working? Well let's just say I "Trust no one", but that at this point I do get the gut feeling that MS has truly placed this aspect of computing highly on the agenda, and they have a reputation of being able to turn their goals into code.

Just me (Sir to you)
Thursday, July 24, 2003

*  Recent Topics

*  Fog Creek Home