It’s that time of year again, I guess. The time of year when people take the nice empirical #of vulnerabilities reported for the top technologies and offer them as data. From the eWeek article, Report: MS, Apple, Oracle Are Top Vulnerable Vendors:
”IBM’s X-Force released its 2007 report on cyber attacks on Sept. 17, revealing that the top five vulnerable vendors accounted for 12.6 of all disclosed vulnerabilities in the first half of the year…” Their list and % of vulnerabilities:
- Microsoft, 4.2 percent
- Apple, 3 percent
- Oracle, 2 percent
- Cisco Systems, 1.9 percent
- Sun Microsystems, 1.5 percent
- IBM, 1.3 percent
- Mozilla, 1.3 percent
- XOOPS, 1.2 percent
- BEA, 1.1 percent
- Linux kernel, 0.9 percent
I’m not going to suggest there’s a conspiracy theory about how they cut at #5 in the article (because look who is at #6 -grin-). Nor am I going to say anything about any particular vendor here. No, what I want to ask you, my Internet friends, is “What use is this?” The answer, I’ve come to is “not particularly much”. Unless you’ve got a hobby around collecting these statistics or are a journalist that needs a good headline - these numbers unfortunately don’t really tell you much about quality of code base, or how good or bad your environment might be from a security standpoint if, for example, you exchanged your OS X servers for Linux servers.
A QUESTION
Here’s a fun question: Which of the following represents a potentially vulnerable state:
- A four-character alphabetic password
- A 256 bit AES encrypted string of text
- An unpatched NT 4 server
For those who didn’t guess right away, I’ll spare you the trick question. They’re all potentially vulnerable - it depends on the amount of force a specific threat agent can apply to them. Sometimes this force is greater than our ability to resist it, and bad things happen. Sometimes our ability to resist that force very strong, and we’re in a good state.
ON VULNERABILITY
Now we could measure the strength of that force for a threat agent using a population distribution represented by a standard Gaussian distribution (a bell curve). Those threats who are particularly adept in their capabilities (that is, their skills & resources) might be said to be somewhere in the top 95 percentile or greater. Those who are less capable but still adept as attackers might be represented in the top 75th percentile. We may even classify those who are low on skills, but because of privileges high on resources (non-technical internal attackers with system credentials) as being “very high” or 90th percentile or above - we could go on here, but you probably get the idea.
Similarly, we could measure the strength of our controls against some baseline measurement of force. A very hardened asset like the 256 bit AES text string in our example may be said to be in the top 95th percentile. An unpatched NT server may be in the bottom 25th percentile (or lower).
What is important to us is the difference between the two. In FAIR, we call this difference “Vulnerability” - you might call it “true vulnerability” because this difference between Threat Capability and Control Strength gives us an idea as to “how vulnerable we really are”.
Two things to note:
- We just created a model. We took state of nature (Control Strength, Threat Capability) and created a state of knowledge (Vulnerability). If this is wrong, then I don’t want to be right
- This “vulnerability” is still missing crucial elements before we can understand anything about our risk.
With regards to that second point - this is why some products that call themselves “risk management” and some products statements about “risk” drive me nuts. We have no concept of frequency yet. Frequency, as you might have already figured out, is a key problem not only in probability theory - and risk is a probability issue, of course - it is imperative in understanding how “secure” we are. Before we can determine risk we have to have an understanding of the frequency for contact and probability of action against us for the threat agent we’re aiming to use in our Vulnerability statement. In addition to missing frequency, without understanding probable magnitude of loss, you can’t really make a business risk statement.
(via RiskAnalys.is)
September 20, 2007, 8:32am Comments
