The goal of this document is to ensure consistency, coherence between security documents. All Mozilla security documentation must follow the recommendations below.
This document establishes standard level conventions, in particular:
- Level color coding
- Name or name schemes
- Level expectation
Looking for scores instead? While all document must still express risk using the standard levels, you can refer to the Scoring and other levels guideline for scoring, pass/fail, RFC2119 definitions, document readiness, etc.
Standard Documentation Levels
We strongly emphasize on presenting risk levels in all documents, pages, etc. It allows for a common representation of risk regardless of tools and other nomenclature used. If you use a scoring system for example, and your score is F, you are at higher risk - but it could mean different things on different tools. For this reason, the risk levels are the most important levels and must always be followed and present.
See also Assessing Security Risk for an introduction to risk and our processes related to risk.
Standard risk levels definition and nomenclature
The risk levels also represent a simplified ISO 31000 equivalent (and are non-compliant with ISO 31000). These levels are also used to display importance, effort, risk impact, risk probability and any risk related level.
Risk Level |
Expectations |
Rationale |
---|---|---|
MAXIMUM Risk HTML Color code #d04437 |
This is the most important level, where the risk is especially great.
|
|
HIGH Risk HTML Color code #ffd351 |
|
|
MEDIUM Risk HTML Color code #4a6785 |
|
|
LOW Risk HTML Color code #cccccc |
|
|
UNKNOWN Risk HTML Color code #ffffff |
|
This is not a true level, it is used when there to represent that we do not have enough data to correctly assess the level (i.e. data collection work is required). Note: communicating the risk of not knowing is challenging and prone to failure, in particular when once data has been gathered, the risk appears to in fact be low. This concept is also known as "trust, but verify" - i.e. unknown does not distrust (by assign it a higher risk) the service, user, etc. by default. |
Examples of usage
LOW Risk
- Attention Service owner or delivery team may look at it, through email or other means.
- Effort Flip a configuration switch, change a password, lookup a document, etc.
- Risk acceptance Accept risk of leaking non-sensitive data as peer-review process is light.
MEDIUM Risk
- Attention Service owner or delivery team must be informed via bug, document, etc.
- Effort Take a group decision, create standards, lookup statistics, manual upgrades, etc.
- Risk acceptance Mitigate the risk of attackers accessing the admin panel by using SSO.
HIGH Risk
- Attention Ensure service, product owner is aware via bug and pings.
- Effort Implement a new security control, code a new feature, change all company user passwords, etc.
- Risk acceptance Hotfix to mitigate within the next few days, eventually turn off if it takes too long.
MAXIMUM Risk
- Attention Ensure service,product, capability owner is aware via bug and pings.
- Effort Implement a new security design/change product design, etc.
-
Risk acceptance Turn service off/put it behind VPN until fixed/ASAP.
- Your site scored C to the HTTP observatory tests, and it is at MEDIUM Risk.
- You have 1 immediately exploitable RCE vulnerability of maximum impact and are at MAXIMUM Risk.