Security/Standard Levels: Difference between revisions
Gdestuynder (talk | contribs) (Automated sync from https://github.com/mozilla/wikimo_opsec) |
Gdestuynder (talk | contribs) m (Star colors) |
||
Line 18: | Line 18: | ||
Star rating | Star rating | ||
<span style="background-color: #14892c; border-radius: .25em; color: # | <span style="background-color: #14892c; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯✯✯✯</span> | ||
<span style="background-color: #4a6785; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯✯✯</span> | <span style="background-color: #4a6785; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯✯✯</span> | ||
<span style="background-color: #ffd351; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯✯</span> | <span style="background-color: #ffd351; border-radius: .25em; color: #000000; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯✯</span> | ||
<span style="background-color: #d04437; border-radius: .25em; color: # | <span style="background-color: #d04437; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯</span> | ||
Optional, Should, Must | Optional, Should, Must | ||
Line 282: | Line 282: | ||
|- | |- | ||
! <span style="background-color: #14892c; border-radius: .25em; color: # | ! <span style="background-color: #14892c; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯✯✯✯</span> | ||
| | | | ||
''Highest possible grade.'' | ''Highest possible grade.'' | ||
Line 303: | Line 303: | ||
* Potential blocker on initiative | * Potential blocker on initiative | ||
|- | |- | ||
! <span style="background-color: #d04437; border-radius: .25em; color: # | ! <span style="background-color: #d04437; border-radius: .25em; color: #ffffff; display: inline-block; font-weight: bold; margin: .1em 0; min-width: 6em; padding: .05em .5em; text-transform: uppercase; text-align: center;">✯</span> | ||
| | | | ||
''Lowest possible grade, score may greatly contribute to risk.'' | ''Lowest possible grade, score may greatly contribute to risk.'' |
Revision as of 00:14, 27 February 2016
STATUS: 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 level is not present in this document, it cannot be used. It establishes standard level conventions, in particular:
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. |
Standard Documentation Levels
Different kinds of levels
There are different kind of levels or states we want to express:
- Risk levels
- Data handling levels
- Not-strictly-levels tests such as "OK" or "PASS" and "NON-OK/NOK", "FAIL"
- Scoring levels such as "good", "bad"
- Requirement levels
- etc.
While they're used to describe different kind of levels, they all attempt to display a hierarchy. Thus, all levels attempt to use the same coherent standard model.
Risk levels definition and nomenclature
These are the base standard levels and are strongly encouraged be used as a foundation for any other level definition.
Risk Level | The importance of a risk as defined by its impact and probability.
We express security risk levels qualitatively (low, medium, high, maximum). |
---|---|
Risk mitigation | Reduce the risk level through a technical or non-technical mean in order to:
|
Risk remediation | Remove the risk by correcting an issue, or removing the issue, or implementing a technical or non-technical solution that removes the risk. |
Residual risk
Accepted risk |
Risk that will not be corrected, removed or reduced. It is instead accepted as-is and will therefore be residual. |
The risk levels are not ISO 31000 compliant, but represent a relatively simplified equivalent. (If you do not know ISO 31000, that's fine!).
Level | Coding rationale | Definition & expectations |
---|---|---|
UNKNOWN | White represent the emptiness/lack of data. | This is not a real level, it is used when there to represent that we do not have enough data to correctly assess risk (i.e. data collection work is required).
Even when no data is present, it is often possible to estimate the risk (since there is a risk of not knowing). However, 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 dist-trust (by assign it a higher risk) the service, user, etc. by default. |
LOW |
|
This is the lowest level, where the risk is reasonably close to zero.
|
MEDIUM |
|
|
HIGH |
|
|
MAXIMUM |
|
This is the most important level, where the risk is especially great.
|
Effort measurements
When work is required for a remediation, mitigation, additional security control, etc. we rate this effort using our standard levels. This helps managing resources and prioritizing work.
Level | Time spent |
---|---|
LOW |
Example: Flip a configuration switch, change a password, lookup a document, etc. |
MEDIUM |
Example: Take a group decision, create standards, lookup complex data, manual upgrades, etc. |
HIGH |
Example: Implement a new security control, code a new feature, change all company user passwords, etc. |
MAXIMUM |
Example: Implement a new security design/change product design, etc. |
RFC2119 handling recommendation levels
See also RFC 2119 for a formal definition.
Level | Coding rationale | Definition & expectations |
---|---|---|
OPTIONAL |
|
|
SHOULD |
|
|
MUST |
|
|
Pass/fail tests
Tests are not levels per se. When possible, they either pass or fail. It's similar to a walk/don't walk traffic sign.
Level | Coding rationale | Definition & expectations |
---|---|---|
PASS |
|
|
FAIL |
|
|
Document Status Codes
These are used in the header of every document to clearly signify its current status.
Level | Definition & expectations |
---|---|
READY |
|
DRAFT |
|
NOT READY |
|
Scoring levels
These levels are used to score general effectiveness. Most commonly, these levels are used to score countermeasure effectiveness (controls) in security reports.
Four levels are used to align with other security related levels, such as risk levels. Note these levels do not signify risk, and are more intended to provide a grade for a particular objective.
Level | Definition & expectations |
---|---|
✯✯✯✯ |
Highest possible grade.
|
✯✯✯ |
|
✯✯ |
Score may moderately contribute to risk.
|
✯ |
Lowest possible grade, score may greatly contribute to risk.
|
The values may be scored ordinally, but should be represented visually (using star symbols) for presentation purposes. Where scores are desired to be fed into other metrics (e.g. risk calculations) the scores may be inverted (e.g. a 1 becomes a 4) to represent an impact score (risk datapoint).
Levels of security provided (by service)
This should be used for Mozilla provided or hosted services as well as externally provided services (SaaS, etc.).
Security level provided (impacts mentioned are from Rapid Risk Assessment | Definition & expectations |
---|---|
LOW |
|
MEDIUM |
|
HIGH |
|
MAXIMUM |
|