Problems with prioritization

Traditionally, findings are scored based on their impact. For vulnerabilities, this is done via CVSS. Mondoo has all policies and checks prioritized with an impact rating as well. This approach is easy to get started, but quickly drowns our dashboard in critical findings. 

Most security tools are optimized for reporting. For the longest time, these apps were measured by the number of findings they produced in their target environment. Over time, we kept adding more technologies, which created a need for more security tools, and thus produced more findings. We took care to eliminate false-positives, as much as possible, and offer localized prioritization.

Unfortunately, despite a ton of results, things don't get fixed nearly as quickly as we want. When we spent time with platform and engineering teams, we learned a lot about their frustrations. 

Two things kept coming up: 

First: Clear and actionable findings are a requirement. If you produce an issue, you also need to provide guidance on how to resolve it. 

Second: The biggest pain point is still prioritization.

In some cases, security tools create high-priority issues that quickly turn out to be only minor concerns. Sometimes priority findings are lost among a long list of similarly flagged issues. Certain packages may be used only for development and never run in a production environment.

Security teams feel this pain as well. Today's environments are complex and hard to understand. They span clouds, workloads, and services. It's easy to miss a finding that actually puts your company at risk. This uncertainty is caused by complexity.

Effective prioritization eliminates complexity and makes findings easier to understand for both security and platform teams. Ultimately, by making security accessible and easy to act upon, we can increase its adoption in an organization.‍

Risks and exposure

When you sit down with your first cup of coffee, you want to know which findings you will tackle first. Which vulnerability is the most impactful? Which issue causes the greatest actual risk of being breached? Which package, if updated, has the biggest impact on your posture? 

This is the "first cup of coffee problem" in security. It revolves around effective prioritization of findings.

To do this, we need three ingredients: The finding's impact, its contextual risk, and its downstream exposure.

Contextual risks are all things that an attacker uses to exploit a security issue in a distributed system. For example: If you detect a vulnerability in your SSHd package, attackers still need a way to reach it. This can be done by having the vulnerable package's binary running on the OS and verifying that it opens a listening port. In cloud environments, we may even find that the instance is exposed via a public IP and open security groups. 

Some actions can also reduce the contextual risk. For example, users may add firewalls, security rules, or other countermeasures like LSMs.

All of these aspects chained together describe the contextual risk of a vulnerability relative to the asset's role in the overall system.

Downstream exposure accounts for all things an attacker will use after they have exploited a security issue. For example, they may gain access to user accounts, credentials, databases, or other systems on the network. Some nodes may be running critical workloads, like kubernetes clusters or databases themselves.

Finally, some systems may be part of your critical infrastructure, while others are only used for development. These systems can be tagged and subsequently reprioritized during the risk evaluation (see the next section). 

Both contextual risks and downstream exposure are combined into risk factors. These risk factors provide a scoring system on top of traditional impact, which expresses the risk of a finding in the context of the overall system.

Custom prioritization

Platform teams often understand which systems are the most critical for the business to run. For example: Payment systems need to be up and running at all times and kept as secure as possible. Developer services may be more lenient and can support frequent breaking changes.

To support companies with these custom needs, Mondoo is the first solution on the market to offer fully customizable risk prioritization.

You can customize risk priority in the Mondoo Console via a straightforward configuration. (This feature will be generally available this month.) Use a simple slider to increase or decrease the influence of individual risk factors.

For example: Some teams care a lot about systems on their perimeter, while others prioritize findings equally between internet-facing and internal systems. The latter may have audit requirements like fast resolution times for vulnerabilities on all devices. 

In the first case, users can increase the impact of the risk factor for internet-facing systems, which deprioritizes internal assets. In the latter case, users can change the risk factor to have no influence at all on prioritization. Mondoo still flags internet-facing systems in the UI, but it doesn't deprioritize internal systems. 

Finally, users can also define and evaluate their very own risk factors. Far beyond simple tagging, they can reprioritize systems as critical if certain workloads are executed on them. Other teams can look for network or credential access and reprioritize all findings if they are found on these assets.

Priority charts

We are launching a major overhaul of the Mondoo Console with brand-new visualizations for findings:

The interactive chart on the left allows us to explore our environments by technologies and quickly find the most impactful areas. In this case, you can see that Kubernetes needs attention. Once you drill in, you can even find the object types and assets that need fixing.

The right side shows new lists of findings, which are prioritized by contextual risks. They include both a risk score (based on risk and exposure) and a blast radius, which shows how many systems are affected at different levels of criticality.

Additionally, we have overhauled the list of vulnerabilities and advisories and introduced a new list of checks, which are prioritized by risk score. These show aggregate findings for the environment with contextual risk scores, blast radius, and risk factors for each finding. We are also in the process of releasing vulnerabilities grouped by software in environments. 

Finally, we are shortly adding a list of findings grouped by risk factor for each environment. This is useful to see aggregate risks, such as all internet-facing systems. It also allows us to natively group EOL systems and replace the current EOL policy.

Summary and outlook

Risk factors are an amazing way to prioritize the most impactful actions your teams can take in their environments. In the next month, we will also add risk graphs and a chain of custody to make these even easier to understand and follow.

Whenever you wait for that first cup of coffee in the morning, we will be busy prioritizing contextual risks for all your findings.