Accurate severity scores help security teams understand the risks that vulnerabilities pose to their environment. This guide explains how Cloud Security Management (CSM) uses different measures of severity to calculate the scores.

CSM severity scoring framework

CSM Misconfigurations, CSM Identity Risks, and Security Inbox misconfigurations use the CSM severity scoring framework to determine the severity of a finding. The framework compares the likelihood that an adversary would take advantage of a misconfiguration to the risk posed to your environment. By weighting both of these aspects, findings can be prioritized more accurately by real-world risks. The matrices below show how a misconfiguration’s severity score is computed based on its likelihood of abuse and impact.

Likelihood

The likelihood component is made up of two subcomponents:

• Attack vector: The means through which a misconfiguration can be exploited.
• Accessibility: If the resource is publicly accessible or not.

Attack vector

The attack vector is determined by the following criteria:

Accessibility

Accessibility is determined by the following criteria:

Likelihood score

Together, the attack vector and accessibility determine the Likelihood score:

Impact

The impact component is how damaging the exploitation of the misconfiguration would be to the environment.

Severity scoring matrix

The likelihood and impact components are used to compute the overall severity score for a misconfiguration.

Examples

To explain how the framework is used here are a few examples.

Example 1: SNS Topic should have access restrictions set for subscription

The detection rule for SNS Topic should have access restrictions set for subscription checks if the SNS topic has a resource-based policy that contains a Principal of *, and an Action with the sns:Subscribe permission. This combination gives anyone the ability to subscribe to the SNS topic and receive its notifications.

Using the CSM severity scoring framework, the rule would be scored as follows:

• Likelihood score: Highly Probable
  • Attack vector: No Authorization
    • The Attack Vector is marked as “No Authorization” because the resource-based policy contains a *. This wildcard grants anyone the ability to act on the resource. No authentication or authorization is required to exploit the misconfiguration.
  • Accessibility: Public
    • Accessibility is marked as “Public” because the misconfiguration can be exploited over the internet through its resource-based policy. No specific network access is required.
• Impact: Medium
  • Impact is marked as “Medium” due to the fact that the confidentiality of the resource is impacted. An adversary who exploits this misconfiguration can receive messages sent by the SNS topic.
• Severity score: Highly Probable x Medium = High
  • The final severity score is High. This is because a Highly Probable likelihood mixed with a Medium impact results in an overall score of High.

Example 2: EC2 instances should enforce IMDSv2

The detection rule for EC2 instances should enforce IMDSv2 checks if an EC2 instance is using the Instance Metadata Service Version 1 (IMDSv1), which is vulnerable to common web application attacks. If exploited, an adversary can obtain access to the IAM credentials stored in the IMDS and use them to access resources in the AWS account.

Using the CSM severity scoring framework, the rule would be scored as follows:

• Likelihood score: Possible
  • Attack vector: Vulnerability
    • The attack vector is marked as “Vulnerability”. This is because the exploitation of this misconfiguration requires the resource to contain a vulnerable component, such as vulnerable software running on the EC2 instance that can be abused to perform server side request forgery attacks.
  • Accessibility: Private
    • Accessibility is marked as “Private”, because the EC2 instance has not explicitly been made public.
• Impact: Medium
  • Impact is marked as “Medium” due to the impacts to the confidentiality of the EC2 instance. An adversary would be able to access the IMDS and potentially pull IAM credentials associated with the resource.
• Severity score: Possible x Medium = Medium
  • The final severity score is “Medium”. This is because a possible likelihood mixed with a Medium impact results in an overall score of Medium.

CVSS 3.1

CSM Vulnerabilities uses Common Vulnerability Scoring System version 3.1 (CVSS 3.1) to determine a base score for a vulnerability. It then modifies the base score to take into account the following:

• Whether the underlying infrastructure is running and how wide-spread the impact is.
• The environment in which the underlying infrastructure is running. For example, if the environment is not production, the severity is downgraded.
• Whether there is an active exploit for a given vulnerability from sources such as CISA KEV catalog.
• The exploitation probability, calculated and verified using EPSS.

Further Reading

Additional helpful documentation, links, and articles:

Start tracking misconfigurations with CSM MisconfigurationsDOCUMENTATION Understand your identity landscape with CSM Identity RisksDOCUMENTATION Learn more about CSM VulnerabilitiesDOCUMENTATION