The cybersecurity field does not have a universally adopted standard for assessing, displaying, and discussing risk. This is especially true in the space of cybersecurity tools.
A given tool may range from using CVSS scores to high/medium/low ratings, to a completely custom scoring system. Approaches to risk ratings are all over the map. I touched on this dynamic in my recent article, “In Cybersecurity, Beware Death by a Thousand Vulnerability Reports,” and I will expand on it here.
The good news is that, despite the complexity in the tooling ecosystem, there is an opportunity for simplification.
Different Examples of Tools
Let’s start by referencing several tools that operate at different layers of a technology stack. The list below is a hypothetical IT or application environment, along with a portfolio of security tools and their risk ratings.
- Penetration testing. Cobalt – uses high, medium, and low with visualization of both the impact and likelihood ratings that make up the overall risk score.
- Attack surface management. Risk Recon – calculates a numeric risk score, then overlays a letter grade (A-F) on top of this.
- Cloud posture. Palo Alto Prisma – uses high, medium, low, and pass (to represent a correctly configured configuration).
- Custom application code. Veracode – uses very high, high, medium, low, very low, and informational, then mapped to CVSS.
- Open source libraries. Github – uses a critical, high, medium, low scale.
- Network and host configuration. Nessus – uses CVSS scores and then assigns vulnerabilities to prioritization buckets based on the score.
The differences between each of these linguistic labels are subtle. However, subtlety can be confusing to consumers when they try to interpret results.
A Reporting Scenario
There is a trend in the industry to move away from standalone vulnerability reports towards ticketing system integrations (e.g., Jira, Github Issues, etc.). The problems now arise when a development team begins to review these incoming tickets and sort them for remediation. The developer must then:
- Understand the environment and relate that to the details in the ticket
- Interpret the difference between an 8.5, a high, a very high, and a critical
Taken together, the developer owns the burden of interpretation. Further, the right answer on interpretation depends heavily on the context of the vulnerability, the application function, and the environment. This is something that many scanning tools lack in varying degrees.
The security leader who is pulling together risk metrics to brief senior leadership or a board of directors shares the burden in a similar way. The subject matter expertise, in this case, may make this easier, but it’s still an added layer of work.
Enrichment
Some tools have started to enrich the vulnerabilities in their platform to assist with prioritization. This takes many forms such as code path verification, threat intelligence against specific vulnerabilities, whether exploit code exists, and more.
This enrichment process can help users of a tool to prioritize issues while they are using the tool’s interface. Once a vulnerability has been exported out of a given tool, it may retain the enrichment metadata, but it now falls victim to the compare and contrast reporting scenario highlighted above. When a vulnerability has been enriched by a particular solution but another one has not, the consumer may still see two high-risk vulnerabilities side by side.
Penetration testing as a general practice often naturally benefits from this enrichment process. Due to the nature of it being a live test on a running system, anything found and exploited has a real factor associated with it. In contrast, when developers classify vulnerabilities as hypothetical or academic in nature, pushback follows.
An Opportunity for Security Teams
As mentioned earlier in this article, despite the complexity in the tooling ecosystem, there is an opportunity for simplification for security teams. Bring vulnerabilities together into one place where a uniform risk calculation can be created and presented to the ultimate consumer of the results. This aggregation approach could be something that is either:
- Visible to development teams, e.g., expose the results directly to them; or
- Invisible to them, e.g., treat this as middleware and integrate into the ticketing solutions from this point
Simplification is an underrated approach to change management, as detailed in the book Subtract: The Untapped Science of Less. Removing steps, complexity, and burden can add tremendous value to those involved in the vulnerability management process.
