When a Public Cloud vulnerability is disclosed, Cloud providers don't assess the CVE Base Score unless customer impact has been demonstrated.
The Cloud customers community need a way to perform such assessment for analyzing the potential impact the vulnerability may have had in their subscriptions and accounts.
PI is a simple methodology for rating the base (i.e. unmitigated) score of a Public Cloud vulnerability independently from Clod providers.
Like CVE, PI ranges from 0.0 to 10.0:
- LOW vulnerabilities score less than 5.0
- MEDIUM vulnerabilities score between 5.0 and 7.5
- HIGH vulnerabilities score between 7.5 and 9.5
- CRITICAL vunerabilities score more than 9.5
From long standing experience in risks assessments, I have noticed that the key questions to ask when conducting an assessment depend on the order of magnitude of the risk. Each order of magnitude must address a limited set of concerns, and all that is below that order is meaningless.
For Cloud vulnerabilities, I have defined several orders of magnitude, the two major ones being cross-tenant and same-tenant.
So in the end we have only very few questions to answer, this makes the assessment pretty simple and straightforward: the orders of magnitude behave like filters hat show you only relevant questions.
To keep the PI rating within the 0.0 -> 10.0 range, a logarithm is being used.
The AWS and Azure folders contain the detailed individual scores of Cloud vulnerabilities rated so far: files are sorted according the following naming convention:
YYYY_MM_name.md
YYYY and MM are the year and month of the public diclosure.
Open a pull request and I will review it for merge into this repository. Please note that, for now, only Azure and AWS providers are supported. We plan to add more in the future.
Calculations are versioned. The current version is 1.5
To propose any change, make a pull request to the markdown file called Specifications. Don't forget to add detailed explanations in comments.
PiercingIndex.pdf explains how the PI is calculated. Only 8 questions, labelled A1 to A8, must be answered to get a rating.
In each indivudual vulnerability file, the following components must be mentionned:
- the PI version (currently, it is version 1.5)
- the URL of the vulnerability report
- a traceback to cloudvulndb.org assessment (a YAML file)
- a vector string summarizing answers to the 8 questions, it is an easy and portable way to reason about the severity of a vulnerability.
- the PI calculated from that vector.
The Vector String is directly inspired from the CVSS format.
As explained in the PDF documentation, the exact answers to put into the vector depend whether the vulnerability is cross-tenant or not
Only questions A1,A2,A7 and A8 matter for the PI rating: questions A1 and A2 are purpose-built for cross-tenant vulnerabilities, while questions A7 and A8 are miscellaneous questions applicable to all vulnerabilities.
For a cross-tenant vulnerability, the vector must be formed as such:
PI:version.subversion/A1:val_A1/A2:val_A2/A7:val_A7/A8:val_A8
The AWS ECR cross-tenant vulnerability, for example, is attributed the following vector in PI version 1.5:
PI:1.5/A1:20/A2:1/A7:1.1/A8:1.1
In this case, only questions A3 to A8 matter: questions A3 through A6 pertain to same-tenant vulnerabilities, while A7 and A8 apply to all vulnerabilities.
For same cross-tenant vulnerability, the vector must be formed as such:
PI:version.subversion/A3:val_A3/A4:val_A4/A5:val_A5/A6:val_A6/A7:val_A7/A8:val_A8
For example, here is the vector of the Azure logic App same-tenant vulnerability in PI version 1.4:
PI:1.4/A3:1.05/A4:1.05/A5:1.05/A6:8/A7:1.1/A8:0.9
Modified PI range to align with CVE range: was 0.0 - 1.0 Now: 0.0 - 10.0
Modified A8 weight to account for Lightspin Azure Cloudshell and Orca CosMiss disclosures
Modified A3 weigth to account for Azure FabricScape and AWS EKS IAM authentication vulnerability disclosures
Modified global weigthing accounting for the data accumulated over the past semester.
