It's ethical because Schneier says so...

... does that make him the dispatcher of all things ethical? (I have a funny story about that, remind me to tell you someday...)

Bruce Schneier says bugfinding is ethical because.... well, because he says so. I guess. In fact, in a bizarre twist, he suggests it may be unethical not to do vulnerability research if you have the ability... (I'm guessing that maybe if you were saving starving people in the third world that you would get a pass on that one...)

Talk about a crock of bull. Seriously, there is no logic or reasoning to the entire position (which is why I am not compelled to provide my logical reasoning against it). And for a guy who is a huge supporter of information security economics, this should be downright embarrassing.

The Best Virtualization Joke Ever...

... but only because it's the only one. Stop reading now if you can't handle humor ;-)

Three hypervisors walk into a bar.

The first hypervisor points to the pool table across the room and says to the other two, "watch this!" He snaps his fingers and the cue ball magically hits the 8 ball into the corner pocket. Hyvie 2 pats him on the back and says, "Nice job, but that's nothing. Watch this!" Hyvie 2 points to the abandoned building across the street and snaps his fingers. Amazingly, a carnival appears out of nowhere, complete with hundreds of people, cotton candy and a ferris wheel!

Hyvie 1 and Hyvie 2 proudly give each other high fives and turn to Hyvie 3, who has been quietly standing by, watching the bravado. Then Hyvie 2 says, "Heh, heh - why so glum? I bet you can't beat that one!"

Hyvie 3 slowly looks from Hyvie 1 to Hyvie 2... then he claps his hands.

And the other two disappear!

Five Immutable Laws of Virtualization Security: Clarifications

Chris Hoff at Rational Irrationality asks a few questions about Burton Group's Five Immutable Laws of  Virtualization Security. He's right that I think that some of his concern is nitpicking about words (yes, Chris, people debate the intent and meaning of the Constitution and even amend it from time to time). On the other hand, I agree that the wording used in Baseline Magazine is confusing. I am not sure whether that is my fault or the magazine's fault.

In any case, the intent behind Immutable Law 1 is very straightforward. It derives from folks periodically suggesting that because a VM runs in ring 3, a compromise of the VM's kernel is less significant than a compromise of the kernel of a physical system, since the VM kernel runs in ring 3.

This is wrong in a very important way. Immutable Law 1 tries to describe this. If you take a physical box running an OS and a set of applications, then port it into a VM, a compromise at the kernel level of the VM has the same impact as a compromise at the kernel level of the physical box (even though it is running in ring 3).

Immutable Law 2 addresses the "virtual is more secure than real" approach that tries to compare a hypervisor's attack profile to the OS attack surface. Since the hypervisor attack surface is additive (.e. the OS is still there), this comparison is inappropriate.

Hope this helps.

The Smartest Thing You'll Read All Week

Nope, it's not from me (but you knew that ;-)). It is from Alex Hutton of RiskAnalys.is regarding Schneier's comment about security mindsets:

The problem with the security mindset is that, in risk analysis, it carries over as a bias.

Read the whole post, it is good stuff.

A Great Example of Bugfinder Nirvana

Over at HellnBak's blog (not sure who this is, but s/he is definitely smarter than me, and good at keeping things in context), there is a post about SDL:

Let me say this right now. SDL works.

You name the major vendor - Microsoft, Apple, IBM, HP, VMWare, etc… I have worked with them on getting vulnerabilities fixed and I have been doing so at different times during my 15 year career.  I was sitting at the lunch table in the 90s when a Sr. Microsoft executive looked at a group of researchers and said “If I had my way people like you would be in jail”.  I was there when Scott Culp during his MSRC days called every Security Researcher a Terrorist.  I have also watched the vendor everyone loves to hate — Microsoft — take a complete 180 on their security philosophy.

So before you comment calling me a fan boy let me say this.  Is Microsoft perfect with how they deal with security vulnerabilities and bugs?  No, they are far from it.  But, they are better than the majority of the vendors I have had to deal with.

This is a great example of the subtle cognitive biases I am talking about. Here is someone who thinks that the best proof that SDL works is simply that MS makes him feel good. No doubt, MS is great with their PR and their support of bugfinders, but I have no clue (note to hellnbak - cut-n-paste the bolded phrase and attribute it to me) how pandering proves SDL works.

In any case, whether or not SDL works isn't really in question. This just proves how weak and malleable the evidence is. Not sure about you, but it appears to me that....

HellnBak is a fan boy. ;-)

Are Bugfinders Being Gagged by Microsoft?

Short answer - No.

Long answer:

David Litchfield suggests that I think there is something nefarious going on between Microsoft and bugfinders. I wouldn't go that far. Microsoft is too smart for that and it doesn't serve their purpose. In any case, I do think that they genuinely want to reduce the number of bugs in their products (heck, we hear about how great they are at this every quarter).

I need to clarify my perspective on some of the other things David says:

Litchfield: what happened to the flaws that the researchers found but kept quiet?

Lindstrom: I don't think bugfinders contracted by Microsoft are finding new vulns and not telling anyone (or only telling Microsoft). I think they already believe they've inspected the code well enough and are less interested in finding more. And I think they are aware that finding too many bugs after they've done the contracted work would make them look bad.

Litchfield: "If the latter, then why haven't they been found by other good researchers who baulk at the very idea of working for Microsoft and would love to see nothing more than Microsoft being embarrased or by made a name for themselves by getting out an advisory or two or sold them to Verisign or Tippingpoint's ZDI?"

Lindstrom: It is not clear to me how many "other good researchers" are out there focusing on Microsoft products (the  app layer appears to be where it is at these days), nor is it clear to me that anyone cares that much about embarrassing MS anymore (witness this entire thread where some prominent former critics are now advocates). And things change in the world such that there is more money to be made in the undercover world - monetizing vulns appears to be worthwhile these days, so bugs found are more likely to be kept secret.

Litchfield: if the public vuln count was up, even marginally, you could bet that everyone would be screaming from the rooftops that SDL was a failure. Given that most people (even Pete and Ryan) think SDL was a success, why is it so hard to believe the opposite?

Lindstrom: It's hard to believe the opposite because there are a number of variables that could also explain a low number of vulnerabilities.... and a high number of vulnerabilities would have the opposite set of variables that I consider less plausible.

Microsoft's SDL - a second look

[This whole Microsoft Security Development Lifecycle issue is really pretty surreal – if someone had told me five years ago that a bunch of bugfinders would be defending Microsoft while I pointed out inconsistencies with what they were saying, I would have thought they were crazy.]

There seems to be some confusion about my point regarding SDL so I feel compelled to reiterate my message: I am not suggesting that SDL doesn’t work – on the contrary, I think it probably has had a significant effect. I am simply saying that public vulnerability numbers do nothing to prove it.

Let me see if I can explain my logic a little better and then come up with some better ideas for Microsoft if they want to prove SDL works.

As far as I can tell, the overall goal of SDL is to ship a product with fewer bugs. I believe the most significant effort around SDL was to train Microsoft employees, so that a) architects design more secure products; b) developers write better code (fewer bugs); and c) QA testers find more bugs (with the caveat that this last one may be difficult if the first two succeed).

The three assertions above – driving higher quality from each participant – are my interpretation of SDL objectives based on six years of public reports about the MS initiative. Some have suggested that SDL is a process and that simply increasing the amount of resources allocated to the problem, is within the scope of SDL. I believe this is disingenuous.

If all we need are more resources, we don’t need SDL (or anything with a special name to it). If all we need are more external reviews, we don’t need SDL. If the truth of the matter is that programmers are all at the top of their game already, we don’t need SDL. We simply need to work harder and not smarter.

That is not what I perceive to be the spirit of SDL. And if it is true, then it simply means that we’ve been cheated all these years and SDL really was always a marketing exercise. (And a very clever one at that). I choose to think more highly of Microsoft and believe their intentions were to really make their people better at what they do. If you disagree, there is no need to read further.

The major shortcoming of using public vulns as a measure of SDL efficacy is that there are too many other variables involved. Just because SDL’s goal is fewer bugs and there are fewer bugs disclosed in public doesn’t mean that one caused the other. Here are some other candidate reasons that could have contributed to a reduced public bug count in post-production:

1) Microsoft simply increased the amount of resources allocated to development;

2) Microsoft hired/contracted with all the major bugfinders before going GA;

3) External, uncontrolled resources spent less time and effort on Vista than they did on XP (due to unpopularity of Vista, more interest in applayer stuff, or simply happenstance).

4) Vulnerabilities have gone undercover and don’t get publicly disclosed anymore.

Now, if I were an external analyst (oh, wait…;-)), I might be forced to consider public vulnerability data as my only source of information to try to determine causation from SDL. In that case, I would use the vuln numbers and then try to come up with estimates to address the factors described above (at a minimum). But not only does MS have access (presumably) to much better data, but they also don’t see a need whatsoever to control for these other variables.

This is the core problem: Microsoft is much more confident in their hypothesis than the evidence dictates. So, not only is the accuracy of the information in question, but the approach itself uses one data point to make its case. That turns science into religion and forces a second look at the entire process. (I pause again to re-assert that I think SDL is probably working, but the proof laid out is not convincing).

I really don’t expect Microsoft to go through a scientific exercise to demonstrate the value of SDL. But I certainly feel like I am at a religious revival when I hear how poorly everyone else is doing and that others should adopt SDL and how insulting it is for people like me to question their beliefs. It sounds solely like a marketing and PR exercise to me, and nothing else.

And Microsoft can do better than that.

[Next Installment: What Microsoft SHOULD do to demonstrate the value of SDL.]

Dave Maynor has Saved the World!!

That young whippersnapper Dave Maynor (whose receding hairline is a symptom of performance-degrading drugs and not age) tries to equate my points about SDL with my views on bugfinding. (He must be hurting for work folks, help the poor child out so he doesn't need his allowance anymore, I say!)

I guess I need to clarify my point and then try to address his. First, my point was simply about the relationship between SDL success and the metric used to measure it. At one level, Dave is right that Microsoft can pick whatever metric they want to determine success. But that is more true for internal metrics than it is for public ones that are intended as marketing propaganda used to take swipes against its competitors.

So, the metric "publicly-found and disclosed vulnerabilities" is almost by definition incomplete, since there are presumably many more bugs found in private during the development cycle that would apply to the SDL. And when you have access to more data to make it complete you should use that data to measure success. That is my point. Simple.

(Let me take a quick step back to say that my belief is that the most prominent feature of SDL has always been to get the developers to write better code and less about designing better software or enticing enemies with $$$ so they will stay under NDA while finding vulnerabilities. Even if that isn't the case, my comments hold but even more so if this is true.)

What I am trying to figure out is why the little guy thinks this has something to do with bugfinding. Which it doesn't. Anyone care to enlighten me?

[It was very timely for Dave to point out that every day I get a day older, since I was looking at Twitter yesterday and feeling old because it seems like so much noise to me...]

Microsoft's SDL has Saved the World!!

I can't believe it, folks - Microsoft has saved the world with its Security Development Lifecycle! Yay! You heard it here first, second, third... (hey, this sensationalistic stuff Michael and Robert promote is fun!)

Here's the straight scoop: Michael Howard, the "father of the SDL," is using Jeff Jones vulnerability counts as proof that the SDL works:

So if Windows Vista has more code than Windows XP SP2, why are we seeing a reduction in vulnerabilities? Simple: the Security Development Lifecycle (SDL)! Microsoft decided to change its development practices to enforce greater security discipline.

My gut reaction: I cannot believe Howard is actually going to suggest that the number of vulnerabilities found by external individuals is an indicator of SDL success. I defend Microsoft's SDL to many people and it is patronizing to see a metric completely abused.

Hmm, just for fun let me see if I can figure out some other reason why vulnerability counts might be down....(1 millisecond later)... Eureka! It could be that,

Microsoft has systematically hired and/or contracted with every one of their most vocal critics (and most seasoned bugfinders) to do the work behind the scenes and they don't count those vulns!

Now, it happens that I think this is a very, very smart thing to do. From a marketing perspective and from a threat control perspective. But it says nothing about the SDL because they don't reflect the real numbers. And it pains me even more to see this:

The only way you reduce security vulnerabilities is by focusing on improving code security, design security, reducing attack surface, education, tracking evolving threats, mandatory use of tools, banning known bad functionality, better compilers, better linkers, better libraries, etc. And that is what the SDL is all about and what our team is laser-focused on.

Just think how MS could have revolutionized the way we think about vulnerabilities. And they give us trash*.

Then, Robert Hensing has to go and "second that emotion" by acting insulted that people don't believe SDL works:

One of the most frustrating things for me is when ignorant non-believers <G> claim that the SDL is all just marketing hype / spin / FUD etc. (as so eloquently captured at the beginning of his article <G> and as the title of this post).  It's insulting to me.

I gotta tell you. This stuff is insulting to me, and as a frequent defender of SDL it is even more insulting to be ridiculed the way Microsoft has decided to ridicule those of us who think there are better numbers to be had. I am glad Microsoft has decided these things should be said because it helps divide us even more and makes me realize that I should be more vocal in my concerns.

Could it really be that SDL has done nothing to help MS developers write better code? Could it be that the only thing that makes them "better" is a stronger quality control cycle? There are so many ways they could do a better job proving the efficacy of the SDL that it begs the question why they aren't...

*It's not really that bad, but in context it is truly frustrating to see this stuff.

Asking the right questions about "virtualization security"

There are many vendors coming out of the closet about their virtualization strategy. New technology platforms always drive messaging around security - for example, we saw it with wireless and mobile devices in recent years.

I posted a set of 8 questions on the Burton Group blog that may be useful in tracking just what it means to be providing security in virtual environments. Here is an excerpt:

The only reason any of this matters is to assess the speed for which you need a security solution and the availability of solutions that support that need. There is nothing wrong with having a solution that is virtualization-agnostic, but it is useful to know how unique the solution actually is if it is a differentiator in your evaluation process. In addition, in the near-term security solutions should be able to leverage the characteristics of virtualization for beneficial features such as patching a VM that is not in service or isolating a host agent from the host it is monitoring. That is essentially the VMsafe story.

Read more here. Can you think of any questions I missed?