Reporting on Risk: One Metric to Bind Them All

In my previous post, I discussed ways that organizations have typically reported on risk: namely, talking about the number of closed vulnerabilities. I discussed how most stakeholders (and particularly non-technical executives) can’t make heads nor tails out of that kind of reporting.

So what’s the best way to truly report on risk?

Your first step is to understand the criticality of your various asset inventories. For example, you may know that a particular asset contains all of your highly sensitive customer data—whereas another asset is a set of workstations containing developer code, but not is actually important or sensitive. If both of those assets have the same likelihood of a breach, you want to focus on the one with the most impact to the business, and prioritize the vulnerabilities in that environment first.

Once you have completed arranging your environment to represent some degree of importance and potential impact to the business, the real work begins: you need a true metric to measure risk. As I’m sure is clear by now, reporting on the number of closed vulns is the wrong metric to choose.

What you need to do is bring together your internal assets with external intelligence on what’s happening “in the wild”—in other words, what activity poses a threat to your organization right now. Whether it’s poor password policies, misconfiguration issues, or critical vulnerabilities that are actively being exploited either through advanced persistent threats or non-targeted attacks, it’s this real-time context that suddenly turns a simple number into a story that even a layman can understand.

Next, you need to be able to report on this metric repeatedly—over and over again—day to day, month to month, quarter to quarter. Whether the trend line goes up or down, you’ll be able to mark your progress to goals. Think of this as Internal Assets + External Intelligence = Trend Line.

The metric needs to be simple, understandable, and repeatable, showing historical trends

  • Here’s where we are
  • Here’s where we’re going
  • Here’s how we’re getting there

How Kenna Can Help

If you take into account the general concepts I’ve discussed, you can create the reporting you need without Kenna. But modestly, I think I can safely say that doing so will create a lot of work for the team. Kenna automates a lot of the steps we’ve discussed: it takes into account internal assets and external threat intelligence, and part of the platform’s functionality is to create a trend line of risk—superimposed against vulnerabilities, just in case you can’t live without that number—so you’re able to track your progress over time, and create a report that is truly board-ready.

Here’s a sample of our reporting screenshot:

dashboard reporting

A lot simpler to look at than the spreadsheet reports we looked at in my prior post, right? While what we’re looking at here is the “Kenna Score”—which combines both internal assets with external threat intelligence—it does serve the purpose of providing a simple, understandable metric. And reporting on risk versus vulnerability count can be quite powerful: imagine having the conversation where you explain that vulnerability counts are going up, but overall risk is going down—since the team is remediating the vulnerabilities that truly present risk to the business, rather than a mountain of non-critical vulnerabilities that actually pose no threat. Such a non-intuitive trend line is quite possible if your yardstick is risk rather than the usual numbers game.

At Kenna, we find that presenting a trend line of risk sparks important conversations. People begin to understand the company’s past trajectory and future path. And it becomes much easier to discuss budget allocations to help support critical aspects of the business that still may be exposed to risk.