[updated to fix formatting]
Here is a metric I’ve been working on that I believe more
properly reflects the impact of vulnerabilities on risk, especially when
compared with straight vulnerability counts, which are counterintuitive, and
"days of risk" which is a measure of vendor responsiveness and not
enterprise vulnerable state of a platform.
DOB = The "date of birth" of the vulnerability.
For software manufacturers, this is the date of first release to users. For
enterprises, this is the date of implementation of the software that has the
vulnerability in question.
VD = The vulnerability disclosure date. This date is
currently unused in my model. Note that this date will almost always differ
from the vulnerability discovery date, since black hats may have discovered it
unbeknownst to us and even full disclosure advocates need time to verify their
findings before disclosure.
PD = Patch date. For software manufacturers, the date the
patch is made available to users. For enterprises, the date the patch is
applied to a system.
TD = Today’s date. (This changes every day 
).
DOL = Days of life for an individual vuln is PD – DOB for
patched vulns and TD – DOB for unpatched vulns.
My measure is a simple elapsed time ratio:
Vulnerability Rating (VR) = (sum(DOL)) / (TD – DOB)
As a measure of the vulnerable state of a software program,
Spire’s "Vulnerability Rating (VR)" is the sum total lifetime (in
days) of all vulnerabilities living ( sum of days that each individual
vulnerability lived (or is living) in production until it dies (i.e. it was
patched) divided by the total number of days the software has lived in
production.
Some characteristics of this metric:
1. Fewer vulnerabilities found over a longer period of time
equals "more secure." I really don’t like this assumption that much
because it doesn’t factor in effort or the complexity of the software, but in a
general sense I believe this to be true.
2. A patched vulnerability results in a net increase in
security. This effect comes when we stop incrementing the numerator +1 every
day while continuing to increment the denominator.
3. A patch vulnerability found and patched earlier will have more impact but decay
quicker than a patch vulnerability found and patched later in a product’s life.
4. The VR can be applied both to platforms from a vendor’s
perspective and to an organization’s implementation.
What do you think?
How does this formula account for software that is less actively probed for vulnerabilities, and software that is mature vs. newly released?
Also, how does it account for differences in vulnerability severity?
@DF -
Three great questions that certainly could be asked of vulnerability counts and Days of Risk as well. I’ll take them one at a time.
1) While I fully endorse techniques during development to capture effort metrics, it is extremely difficult to do this for the entire world. The metric does not address discovery effort directly, but it should be reflected in the trend line as higher peaks – i.e. vulns found would have more significant impact.
2)(TD – DOB) in the denominator covers mature vs. new products, since it is a product lifetime (or deployment period for enterprises). New products will divide by a smaller number, so each individual vuln has greater impact. As we expect software to get more secure over time (else we wouldn’t be looking for vulns) the impact flattens out over time as well.
3) I don’t account for severity. My belief is that a metric should start simple and then get more complex as need arises. If severity levels can be objectively shown to be significantly different among programs with the same general function, then I will come up with a corresponding weighting scheme for each vuln’s lifetime.
Thanks for the comments!
My question about less actively probed software was not directed to effort metrics, but the phenomena of widely used software attracting more researchers and criminals, while little used or distributed software attracts fewer. It seems to me that recently released widely used software could initially be rated more vulnerable than little used software, and the ratings could flip over time. If so, a rating at any point in time does not provide a comparable measure of vulnerability that could be used in purchasing or operational decisions.
Does that make sense, or have I missed something?
Just sent it to CVSS list….
@DF -
I think it makes complete sense to want to have a good idea about which platforms are more or less vulnerable than others at the earliest possible time in your deployment cycle (e.g. at buying time). To accomplish that objective, you can look at complexity measures (we assume that more complex software is more likely to have more vulnerabilities, though the only study I am aware of didn’t find a correlation) or attack surface measures – e.g. the Relative Attack Surface Quotient (RASQ).
Unfortunately, the complexity work is not simple post production and isn’t published (or isn’t done) during development. So we are stuck with making do with the things we can quantify.
You are right that the VR comparative ratings will change over time and could flip-flop – the whole Firefox vs. IE fiasco of late ’04 is a good example of that.
The thing I like about the VR is that you can isolate on exposure and measure trends in your own deployment. There is an element of “threat” in this approach, but I think it will still provide a more useful approach to vulnerability than existing measures.