« Internet Explorer Vulnerabilities Gone Wild | Main | Security Capture the Flag Competitions »

22 June 2012

Comments

Nice article, thanks.

I do use CVSS scoring regularly on vulnerabilities found during web application pentests. In my experience it provides an objective metric for vulnerabilities, and clients love objective metrics.
This however doesn't stop us (pentesters) from telling what those vulnerabilities actually mean for that specific client. Eg. when you exploit vulnerability 1, vulnerability 2 and vulnerability 3, this is what can happen - as in you described perfectly in your post.

In the end, the client is the only one that can set the right priorities of the vulnerabilities. Only they have the complete picture of the company, and can slap the correct business risk and associated costs onto a found vulnerability.
That's why it's so important in my opinion to write concise and readable reports, and spelling out what the vulnerabilities mean for them. We're there to assist the client in making a *well-informed* decision.

I'm curious about your next post on CVSS...

@Johnwhite78: Good point. Using a scoring system like CVSS should never take the place of the professional expertise of the consultant, whose recommendations incorporate many more factors than what CVSS measures. I think analog vs. digital makes for a useful rough analogy here. The vision and expertise of the consultant is vastly more fine-grained than the measuring system, which only samples a handful of metrics (which are themselves sometimes awkward to apply). So CVSS is lossy. No surprise there. The question is whether we can improve and extend it to make it better represent the original material.

Or here's another analogy. In baseball there has always been measurements applied to on-field events in an attempt to summarize a player's abilities, such as Runs Batted In (RBIs). But eventually there arose fierce debate about which metrics were actually the most useful. See http://en.wikipedia.org/wiki/Sabermetrics. The information security community is -- for reasons I can't comprehend -- somewhere in the very early stages of a similar debate for attack and defense metrics.

Re: your scenario manipulating tokens, I may or may not agree with you. Could you say a little more about why you think CVSS is not applicable to that attack path?

CVSS can be used to assist risk scoring in pen-test report, but it really doesn't make sense to use it as the main scoring method. In example, during pen-test we've managed to use token impersonation to get into one server (fully patched). On that server, we've found domain admin tokens and escalated into domain admin. It would be pure nonsense to score this scenario using CVSS.

Thanks! And your point about environmental scores is well taken. Pentesters can't be required or even expected to fill these in, but should be welcome to do so when they have the needed background information.

On the surface the project sounds straightforward. Your clients may be thinking: "All vulnerabilities have CVEs, right? And all CVEs have CVSS scores already calculated by the fine folk behind the NVD. Just plug in the numbers!" :)

As probably neither Yogi Berra nor Albert Einstein ever said: "In theory there is no difference between theory and practice. But in practice, there is." I'll cover some other differences between the theory and the practice in coming posts.

Excellent post Tim. I agree that using CVSS on pentests kinda works, but often just doesn’t make sense. I’ve run into the issue of having clients explicitly ask for all pentest results be reported using CVSS. I assume so they can combine with their vulnerability scanning data or input into some change management system. The result being a lot of “umm this attack vector doesn’t really fit CVSS” shoehorning. Filling in the environment CVSS vector, without guessing, would certainly require an understanding of the client’s overall risk posture and internal systems. This is probably not feasible during a black-box style test but more closely aligned with a white-box or threat model test.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment