This document provides a consistent approach for determining security priorities for various types of issues. It also details common remediation Service Level Agreements (SLAs) in accordance with standard compliance requirements and best practices. This information can be used to develop guidelines or policies for your company.
This section provides sample remediation timelines for vulnerabilities based on their severity. The SLAs under the 'default time to remediate' are considered good starting points, while the columns to the right correspond to specific compliance standards. It is strongly recommended to adhere to stricter SLAs to ensure compliance, fulfill contractual obligations, and maintain a strong security posture.
| Vulnerability severity | Default time to remediate | PCI-DSS SLA | FEDRAMP SLA |
|---|---|---|---|
| Critical | 0-7 days | ~30 days | ~30 days |
| High | ~30 days | Not explicitly specified | 30-90 days |
| Medium | ~60 days | Not explicitly specified | 90-180 days |
| Low | ~90 days | Not explicitly specified | ~180 days |
Notes:
- Before finalizing vulnerability remediation SLAs, it is strongly recommended to consult with your compliance team to ensure that these SLAs meet or exceed the current versions of any applicable standards (e.g., PCI-DSS).
- Additionally, coordinate with your legal team to ensure these SLAs align with the SLAs agreed upon in customer contracts.
The science behind risk management and risk calculations can be quite extensive. If you're reading this, you may not have an expert with these skills at your company and need a 'good enough' solution to get started. The goal of this section is to provide a simplified approach for calculating risk that can be used to assign severity levels, which can then be linked to remediation timelines as outlined above.
A vulnerability bug bar is a table that outlines common vulnerabilities and their default risk levels. This simplified approach to classifying vulnerability risk is often a good starting point for quantifying risk and allows for rapid severity calculations. While it may not be entirely scientifically accurate, it works well over 90% of the time and can help establish a program quickly with limited resources.
Example bug bar
| Vulnerability severity | Examples of vulnerabilities | Impact |
|---|---|---|
| Critical | Remote command execution, SQL injection, sensitive data leakage | Vulnerabilities that are easily exploited and can grant full control over a system or access to the most sensitive data. |
| High | Privilege escalation, lack of token expiration, Cross-site scripting | Vulnerabilities that can cause significant downtime or expose data. |
| Medium | Denial of service, open redirects, missing cookie security flags | Vulnerabilities that are more difficult to exploit but present moderate concern. |
| Low | Server-side request forgery, server path disclosure, Clickjacking | Vulnerabilities that are very difficult to exploit or have a low impact if exploited. |
Notes:
- This doesn't automatically factor in externally exploitable vs internally exploitable issues, nor does it factor in if the issue is known to a third party (e.g. security researcher, customer, partner, etc...). For issues that are only internally exploitable, it is common to reduce the priority by one level.
- You will need to align with your security incident response owner to determine if externally known issues require triggering a security incident.
- Lastly, Microsoft has a pretty extensive security bug bar worth checking out covering both client and server side issues.
Pros: Enables rapid risk calculation by anyone without needing a risk calculator or entering numerous fields. The bug bar offers greater speed compared to a risk calculator when dealing with a dozen or more issues, though it sacrifices some scientific accuracy.
Cons: Factors like "is this accessible on the internet" are not automatically considered when using a bug bar. A common approach is to subtract the risk level if the issue is internal or not accessible by an external attacker.
A popular vulnerability scoring approach is to use the CVSS framework and its associated risk calculator. This approach allows you to consistently generate the same priority for each issue and incorporates accessibility and likelihood in a more scientific manner.
| Vulnerability severity | Examples of vulnerabilities | Corresponding CVSS 4.x scores |
|---|---|---|
| Critical | Remote command execution, SQL injection, sensitive data leakage | 9.0-10.0 |
| High | Privilege escalation, lack of token expiration, Cross-site scripting | 7.0-8.9 |
| Medium | Denial of service, open redirects, missing cookie security flags | 4.0-6.9 |
| Low | Server-side request forgery, server path disclosure, Clickjacking | 0.1-3.9 |
Notes:
- The examples above represent vulnerability rankings using the CVSS system. Scores may increase or decrease depending on the impact of the issue being exploited and the version of CVSS used.
- CVEDetails [3] provides a useful tool for exploring published vulnerabilities as measured by the CVSS scoring system.
Pros: Many security scanners provide CVSS scores with each finding, which makes prioritization easier. This allows you to reuse the scores in most cases.
Cons: Using the risk calculator for every issue can be time-consuming. When you have dozens or more findings, this process can take considerable time and is the biggest drawback of this approach.
Security scanners typically assign vulnerability severity automatically based on a CVSS score, simplifying risk calculation. This results in considerable time savings when determining the severity of each finding in bulk. Option 3 involves a hybrid approach, combining either Option 1 or Option 2 with the CVSS scores generated by automated vulnerability scanners. This middle-ground approach eliminates the need to manually classify the severities of scanner findings and supports ranking issues discovered by individuals, such as through a pentest, bug bounty, or other reports.
Pros: You benefit from accepting scanner finding priorities as they are. You can choose either Option 1 or Option 2 based on your risk tolerance and the resources available for classifying non-scanner findings.
Cons: Accepting scanner findings as they are, while also using a bug bar, may lead to scientific inconsistencies in your risk calculations.
[1] CVSS 4.0 Risk calculator https://www.first.org/cvss/calculator/4.0
[2] Microsoft security bug bar https://learn.microsoft.com/en-us/security/engineering/security-bug-bar-sample
[3] CVEDetails - Search by CVSS score https://www.cvedetails.com/cvss-score-distribution.php
Document version 1.0 copied from Sectemplates.com