Severity logic?

[esell]

I have not been able to find any documentation on how the severity for each check, regardless of the provider, is determined, is that something that is provided somewhere? I noticed a previous discussion mentioned "We use a combination of the CVSS 3.0 (https://www.first.org/cvss/calculator/3.0) and the context of the check inside AWS to set the severity.", but that was from 2022, so I wasn't sure if that was still the case. Thanks!

[jfagoagas]

Hello @esell, currently our definition for each severity level is as follows:

Critical – The issue should be remediated immediately to avoid it escalating.
For example, an open S3 bucket is considered a critical severity finding. Because so many threat actors scan for open S3 buckets, data in exposed S3 buckets is likely to be discovered and accessed by others.
In general, resources that are publicly accessible are considered critical security issues. You should treat critical findings with the utmost urgency. You also should consider the criticality of the resource.

High – The issue must be addressed as a near-term priority.
For example, if a default VPC security group is open to inbound and outbound traffic, it is considered high severity. It is somewhat easy for a threat actor to compromise a VPC using this method. It is also likely that the threat actor will be able to disrupt or exfiltrate resources once they are in the VPC.
Security Hub recommends that you treat a high severity finding as a near-term priority. You should take immediate remediation steps. You also should consider the criticality of the resource.

Medium – The issue should be addressed as a mid-term priority.
For example, lack of encryption for data in transit is considered a medium severity finding. It requires a sophisticated man-in-the-middle attack to take advantage of this weakness. In other words, it is somewhat difficult. It is likely that some data will be compromised if the threat scenario is successful.
Security Hub recommends that you investigate the implicated resource at your earliest convenience. You also should consider the criticality of the resource.

Low – The issue does not require action on its own.
For example, failure to collect forensics information is considered low severity. This control can help to prevent future compromises, but the absence of forensics does not lead directly to a compromise.
You do not need to take immediate action on low severity findings, but they can provide context when you correlate them with other issues.

Informational – No configuration weakness was found.
There is no recommended action. Informational findings help customers to demonstrate that they are in a compliant state.

We will add this to our public documentation.

Please let us know if you have found it helpful.

Thanks!

[esell]

Appreciate the response, thank you!

I'm more wondering how you determine what check gets what severity. Is CVSS still used as another answer suggested? Is it based off of a standard somewhere or just based on the maintainers knowledge of the check?

[jfagoagas]

We determine the severity using a mix of CVSS, the maintainers knowledge about the provider, the affected resource and the security check and also the above severity definition. Mixing these three is how we define the check's severity. However, there are some cases where we override the severity to a higher one if the context of the resource indicates a higher risk.

[esell]

Thank you for the info! A minor feature request (with all of your free time 🤣): it would be neat to have the CVSS score stored as part of the metadata file so folks using the tool can justify a rating for a check.
Thanks again!

[jfagoagas]

That'd be ideal but I'm not sure if we can get the CVSS score just with the information Prowler retrieves because for CVSS there is a strong point in the context and sometimes a Prowler check has not all the context required.

What do you think? Do you have any example of Prowler checks that could apply to it?

[esell]

I was thinking almost like a SeverityJustification entry in the metadata file. As many of the checks are more config/compliance things vs a pure vulnerability/CVE thing, our group has struggled to justify the default ratings outside of "Prowler folks are smart, we'll trust them" :) If there was a note in the metadata file that explained how the severity was determined for the check, that would potentially help end-users when it came time to justify the severity to their managers. Maybe that is where the Risk value in the metadata comes into play and we (our group) should be leveraging that as our first factor...

I agree though, trying to align Prowler checks to CVSS could be difficult as there are so many what ifs out there. I have not reviewed many of the Prowler checks, but I'll set aside some time to look at a handful and see how CVSS might fit, and if so, what data might be captured in the process to help justify the severity rating.

[jfagoagas]

That's great, please let us know once you have an update on it. Regarding the Risk I think it'd be a good start point.