Security/Standard Levels

From MozillaWiki
Jump to navigation Jump to search


READY

The goal of this document is to ensure consistency, coherence between security documents. All Mozilla security documentation must follow the recommendations below.

If a risk level is not present in this document, it cannot be used to express security risk.

It establishes standard level conventions, in particular:

  • Level color coding
  • Name or name schemes
  • Level expectation

The Enterprise Information Security (Infosec, formerly OpSec) team maintains this document as a reference guide for operational teams.

Updates to this page should be submitted to the source repository on github. Changes are detailed in the commit history.

OpSec.png

Standard Documentation Levels

We strongly focus 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. If data is of higher level, you are at higher risk. Etc. For this reason, the risk levels are the most important levels and must always be followed and present.

Scoring, pass/fail, RFC2119, etc.

If you are looking for scoring, pass/fail, document readiness, etc. labels and levels, please check Scoring and other levels instead.

Do note that all document must also express risk.

Standard risk levels definition and nomenclature

The risk levels also represent a simplified ISO 31000 equivalent (and are non-compliant) . These levels are also used to display 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.
  • Attention: Full attention from all concerned parties required.
  • Impact: High or maximum impact.
  • Effort: All resources engaged on fixing issues. Following standard/guidelines is required.
  • Risk acceptance: Rarely accepted as residual risk, must be discussed, and must be mitigated or remediated.
  • Exception time (SLA): Recommend fixing immediately.
  • Red signifies "most important".
  • Maximum is a level. Critical is not.
HIGH Risk

HTML Color code #ffd351

  • Attention: Full attention from all concerned parties required.
  • Impact: Medium, high or maximum impact.
  • Effort: Some key resources engaged on fixing the issue. Following standard/guidelines is required.
  • Risk acceptance: Risk must be discussed, and must at least be mitigated.
  • Exception time (SLA): Recommend remediation within 7 days.
  • Yellow generally signifies "warning". In our case it correlates to "important".
MEDIUM Risk

HTML Color code #4a6785

  • Attention: Attention from all concerned parties.
  • Impact: Low, medium or high impact.
  • Effort: Best effort. Following standard/guidelines is required.
  • Risk acceptance: Risk should be discussed, and at least mitigated.
  • Exception time (SLA): Recommend remediation within 90 days.
  • Blue is calm and neutral.
LOW Risk

HTML Color code #cccccc

  • Attention: Expected but not required.
  • Impact: Low or medium impact.
  • Effort: Best effort and best practices expected.
  • Risk acceptance: Risk may often be accepted as residual risk.
  • Exception time (SLA): Indefinitely.
  • Gray is a low contrast color, which signifies not too important. It's also less catchy.
  • Green is not used as green means "ok to do", which is not a level.
UNKNOWN Risk

HTML Color code #ffffff

  • Data collection is expected.
  • This level is expected to change to one of the other levels.
  • White represent the emptiness/lack of data.

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

Level Example
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.
  • You site scored C to the HTTP observatory tests, it is at MEDIUM Risk.
  • You have 1 immediately exploitable RCE vulnerability of maximum impact and are at MAXIMUM Risk.