Skip to main content

Contextual risk scores

Contrast’s contextual risk scoring system provides insight into where there are actual risk points and what should be prioritized. The function contextual score helps you gauge the general performance of each function.

ServerlessGradeEN.png

Functions will have a letter grade A to F, which represents the overall posture of the function, and a numeric score from 35 to 100.

  • A: 90 -100

  • B: 80-89

  • C: 70-79

  • D: 60-69

  • F: 35-59

The overall contextual Risk Score is calculated as follows: Average = (Vulnerability score + Impact score + Likelihood score) / 3.

Vulnerability score

The vulnerabilities identified during the function scans (static and dynamic).

  • Types of vulnerabilities:

    • Custom code exploits (Static and Dynamic)

    • Dependencies (CVEs)

    • Least Privilege violations

  • To calculate the custom code vulnerability score, start with 100 points and subtract penalty points for the number of vulnerabilities found in a function multiplied by a penalty weight for their severity.

    • Critical: Multiply the number of vulnerabilities by 20

    • High: Multiply the number of vulnerabilities by 10

    • Medium: Multiply the number of vulnerabilities by 5

    • Low: Multiply the number of vulnerabilities by 1

      • For example: If the function has 0 Critical, 1 High, 0 Medium and 2 Low vulnerabilities,the score would be: 100 - (20 X 0) - (10 X 1) - (5 X 0) - (1 X 2) = 88

Impact (access level) score

The permission (IAM roles) given to the function. The more permissions the function has, the higher the risk.

To calculate the impact score, we inspect and score each of the 5 permission categories: List, Read, Write, Tagging, and Permissions Management for each service. Then, we start with 100 points and subtract penalty points for the access level of each service.

For example, given the following IAM policy:

{
    "Effect": "Allow" ,
    "Action": [
        "s3:GetObject",
        "sqs:*"
    ],
    "Resource": "*"
}

The score for each service access level would be calculated as the following:

{ 
  "s3": {
    "Read": 6,
    "Write": 3,
    "List": 3,
    "Tagging": 1,
    "Permissions management": 12
  },
  "sqs": {
    "Read": 3,
    "Write": 3,
    "List": 1,
    "Tagging": 1,
    "Permissions management": 6
  }
}

The overall score would be calculated as follows:

  • s3: [6], sqs: [3,3,1,1,6] --> 100 - (6+3+3+1+1+6) = 80

Likelihood (accessibility) score

The likelihood of an attacker reaching the function is based on the function trigger configuration.

Each service has a different score based on the ability of attackers to access the function as well as based on the trigger configuration (for example, authenticated/unauthenticated).

For example:

If the function has an EventBus set as a trigger, the chances for a potential attacker to access the Lambda function would be lower than accessing a Lambda with an API Gateway set as a trigger. Moreover, if the API Gateway is configured without any authentication (i.e., Open), then the function can be accessible by anyone, anywhere.

So the likelihood score for a function:

  • with an EventBus as a trigger would be: 90

  • with an (authenticated) API Gateway as a trigger would be: 75

  • with an unauthenticated API Gateway as a trigger would be: 5 (the lowest possible score)

  • without a trigger would be: 100 (the highest possible score)

In this section: