Spire Security Viewpoint

ISS outs Trend Micro

IBM / ISS released (partially redacted) security advisories against Trend Micro. I think John Pescatore got it right in this article:

"But in some ways, Pescatore said, X-Force broke an unspoken rule. "They definitely compete with each other," he said, referring to IBM's Internet Security Systems and Trend Micro. "Does the blog post warn users of the danger? That's what the vulnerability advisories are for. Would X-Force do the same thing if it found bugs in IBM's WebSphere? If IBM didn't patch fast enough or the patches didn't work too well, would they be blogging that, 'We've had it with IBM'?"


These kinds of competitive rivalries really bring out the worst in security companies and highlight the house of cards that is vulnerability discovery and disclosure. Perhaps more importantly, you'd think ISS would act differently given its experience with the Witty worm and its somewhat strange circumstances... although they may hold the record for the number of vulnerabilities found in competitor products (hmm, maybe I am confusing cause and effect here).

In any case, I doubt it would pass my litmus test. I really don't understand why the profession facilitates arbitrary target practice. Pescatore cuts to the chase with his IBM point, and I am tempted to challenge for ISS to out IBM sometime soon, except that it would increase risk. In any case, IBM would be a target-rich environment in an arbitrary world.

November 13, 2008 in Vulnerability Management | Permalink | Comments (1) | TrackBack (0)

Microsoft Exploitability Index

It is truly disappointing to see Microsoft go its own way with an "exploitability index" that is so coarse in its own scale and so similar to other scales (e.g. CVSS and even MS' own ratings) that it simply adds noise to the overall vulnerability rating arena.

August 05, 2008 in Vulnerability Management | Permalink | Comments (1) | TrackBack (0)

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.

April 21, 2008 in Vulnerability Management | Permalink | Comments (2) | TrackBack (0)

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.]

April 21, 2008 in Vulnerability Management | Permalink | Comments (0) | TrackBack (1)

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.

April 15, 2008 in Vulnerability Management | Permalink | Comments (9) | TrackBack (3)

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?

April 04, 2008 in Vulnerability Management | Permalink | Comments (1) | TrackBack (0)

A tale of two quotes - vulnerability disparity

First, from the Associated Press:

"Rouland contends the 2007 number would have been higher if not for the emergence of a black market that will pay up to $100,000 to computer whizzes who find such threats and sell the information to criminal gangs eager to exploit them."

This quote references the X-force report I mentioned in an earlier post - you know, the one where people are really concerned that vulnerabilities are decreasing.

Second, from a private mailing list:

"I'd bet that most skilled researchers have a number of vulns that they know of that are just lying around, where they didn't have the time or inclination to publish. Maybe they *know* an overflow is exploitable, but haven't put in the 20 hours to prove it; maybe they don't want to deal with the hours/days of labor it takes to disclose it responsibly; etc. Since we're on the back of the envelope - conservatively, I'd say that each skilled researcher would have a minimum of 5 issues that are just lying around that are not likely to get published. So, we're talking hundreds or thousands."

Hmmm, well $500k sure isn't chump change to me, and I suspect that would be true of many bugfinders. So, we have (potential) sellers with $500k of unrecognized income available to them, and buyers with a plentiful supply of vulnerabilities paying as if they are scarce.

I think this variance may be evidence of another thing as well - it is common for people to suggest that one reason to find bugs is that it is just as easy as the bad guys to find them. Keeping aside the fact that this argument is bogus to begin with (rediscovery rates are 7% at best), if these two perspectives really are rational, then it illustrates the disparity in the bad guy's ability to find vulnerabilities, and is perhaps a credit to every legitimate bugfinder who keeps his vulns secret.

To heck with gaming the numbers, it is great fun to watch people gaming the analysis (me included? feel free to clue me in where I am wrong...).

February 12, 2008 in Metrics, Vulnerability Management | Permalink | Comments (1) | TrackBack (0)

Back of the Envelope Math - Undercover Vulnerabilities

Assumptions:

  • [A1] Schneier says: "They find, on average, one security flaw per 1,000 lines of code." Update: I can't substantiate the number but if memory serves me, 1/1k is a common rule of thumb for all defects. Also, I think the numbers here are more likely - around 1/10k. I will use this number instead.
  • [A2] Tippett says: "Only 3 percent of the vulnerabilities that are discovered are ever exploited."
  • [A3] The National Vulnerability Database shows 29,360 vulnerabilities found, ever (I suppose).
  • [A4] Spire Security (i.e. me) lists 20 total vulnerabilities discovered via exploit. (undercover exploits)
  • [A5] Spire Security (yup, me again) estimates there are 3 trillion lines of code in the world, perhaps 240 billion "active" lines of code.

Calculations:

  • [C6] 240,000,000,000 / 10,000 = 24 million vulnerabilities in existence. [A5]/[A1]
  • [C7] 30k / 24m = .125% vulns found (that's 99.875% of vulns undisclosed). [A3]/[C6]
  • [C8] 30,000 * 3% = 900 vulnerabilities actively exploited (can this be right?) [A3]/[A2]
  • [C9] 900:20 = 45 to 1 odds that an exploited vulnerability will come from the pool of known vulns. [C8]/[A4]

etc.

Update: I've had some feedback that suggests [A3] NVD numbers may be off by as much as a factor of 50 and that my list of 20 undercover exploits [A4] is "off by half" which I don't understand but will use 100 to be on the safe side. Here are the calculations in that case ([A3] = 1,500,000; [A4]=100):

 

  • [C6] 240,000,000,000 / 10,000 = 24 million vulnerabilities in existence. [A5]/[A1]
  • [C7] 1.5m / 24m = 6.25% vulns found (that's 93.75% of vulns undisclosed). [A3]/[C6]
  • [C8] 1.5m * 3% = 45,000 vulnerabilities actively exploited [A3]/[A2]
  • [C9] 45,000:100 = 450 to 1 odds that an exploited vulnerability will come from the pool of known vulns. [C8]/[A4]

February 08, 2008 in Metrics, Vulnerability Management | Permalink | Comments (2) | TrackBack (0)

A Dose of Schneier Magic

Every once in a while, Bruce Schneier comes up with a doozy. Caught this one today (written on 2/5):

"They find, on average, one security flaw per 1,000 lines of code.  And when the flaw is fixed, everyone's security improves."

I am talking about the latter half of the statement, of course. He's obviously a smart guy, but this is a really naive thing to say - as if you wave your magic wand and the fix automatically applies to the tens or hundreds of thousands (millions?) of instances out there.

Actually, what happens is that security improves for some and in decreases significantly for others. This possibility occurs after risk spikes for the period between discovery/disclosure and patch application. Any individual entity's risk increases if it doesn't hit 100% patch level. This favors small companies and individuals heavily.

February 07, 2008 in Vulnerability Management | Permalink | Comments (2) | TrackBack (0)

Getting over the hump with vulnerability counts

Should our vulnerability counts be going up or going down? That is an important question every security professional should be considering when laying out a security program.

If you believe vulnerability counts should be increasing, then presumably you believe that we are only covering the tip of the iceberg with respect to the total number of vulnerabilities in production. In this case, you are taking a short-term view of what is happening in security - it is okay to be hoping the counts increase in the short term, but eventually you want them to decrease (right?).

If you think vulnerability counts should be decreasing, then you might be heartened by this bit of news from ISS' X-Force:

For the first time [in 2007], X-Force witnessed a reduction (-5.4 percent) in new vulnerability disclosures from the previous year.

The strange thing here is that X-Force wants to explain this decrease as a statistical anomaly. I think they should be pointing to it as a potential indicator of success, albeit with a need for more substantiation. 

So, do you want the number of vulnerabilities found in 2008 to be higher or lower than those found in 2007? (Btw, if you have some reason to expect 6000-7000 vulnerabilities to be found this year, and I believe you do, what are you doing to protect yourself from these "known unknowns" RIGHT NOW?)

Update: Funny! People are really vested in ensuring this number stays high. Here's what Larry Dignan at ZDNet/Zero Day had to say. Can you sense the worry? People get attached to this stuff so much that it becomes clear that they NEVER WANT TO BE DONE (not that they would, but presumably that is the end game for a process of finding vulnerabilities).

February 05, 2008 in Metrics, Vulnerability Management | Permalink | Comments (1) | TrackBack (0)

»

About

Categories

  • Identity Management
  • Incidents
  • Metrics
  • Quotes
  • Threat Management
  • Trust Management
  • Vulnerability Management

Recent Posts

  • Modelling the Security Ecosystem - is exploit availability exceeding patch availability?
  • Exploiting Undercover Vulnerabilities
  • Social Security Numbers don't have to be predicted - they are known
  • Don't confuse brand value with executive embarrassment
  • Collateral Damage in the Cloud
  • Security Measurements Illustrated
  • Security and "Healthy"
  • Cost-Benefit vs. Cost-Effectiveness
  • Security and Risk in the Cloud, ongoing...
  • R.I.P. Peter Bernstein
Subscribe to this blog's feed

Archives

  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • November 2008
  • October 2008
  • September 2008

More...

Blog powered by TypePad