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

Note Risk levels are not described here, but are mandatory when describing risk and documented in Standard Levels.

See also Assessing Security Risk for an introduction to risk and our processes related to risk.

Scoring and other levels

RFC2119 handling recommendation levels

See also RFC 2119 for a formal definition.

OPTIONAL: This is up to the reader to choose to follow or not to follow this recommendation.

SHOULD: Should is very close to “must do” however, exceptions may be granted after discussion.

MUST: This must be done, is required, mandatory - there is no exception.

These are used to match recommended configuration states. It describes set of documentation configuration state that we recommend using, depending on your use-case.

Modern:

  • State of the art configuration from a security point of view.
  • Generally better for security sensitive services.
  • Fewer server/clients may be compatible.

Intermediate:

  • Usually the default configuration we recommend.
  • Reasonable configuration that we recommend while covering the largest amount of clients.
  • Fewer server/clients may be compatible, though the majority should be compatible with this configuration.

Old:

  • Configuration that you may only use if other configurations cannot be followed for technical reasons
  • Relatively safe - but must be moved to the intermediate configuration above when possible.
  • Generally supports the largest amount of servers/clients.

Document Status Codes

These are used in the header of every document to clearly signify its current status.

Level

Expectations

READY
  • Means the document is ready for user consumption and is expected to be followed.

DRAFT
  • Means the document is in progress or does not cover all cases.
  • You may follow this document for guidance, at your own risk.

NOT READY
  • Means the document should not be followed right now.

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

Expectations

PASS
  • Green generally means acceptance, allowance such as the traffic sign "Walk".
  • Means a test successfully passed.
  • There is no "almost passed": test must completely pass.

FAIL
  • Red generally means refusal, denial, such as the traffic sign "Don't walk".
  • Means a test did not pass.

Scoring levels

Scores are used to gamify usage of security controls and features. Note these levels do not directly signify risk, and are instead intended to provide a grade for a particular objective. The mapping to objective can be used as a base to create a mapping to Standard Levels.

These levels are used, for example, on the https://observatory.mozilla.org.

The letter E is not used in the grades in order to keep scores concise and voluntarily less granular (see expectations for each grade below). The use of + and - modifiers is allowed if necessary. These are added to represent going slightly above or below expectations.

Level

Expectations

A+, A, A-

Highest possible grade.

  • Support all features and controls.
  • All intentions of objective met.

B+, B, B-
  • Supports most important features and controls.
  • Some outliers need attention.
  • Most intentions of objective met.

C+, C, C-

D+, D, D-

Score may moderately contribute to risk.

  • Potential service blocker.
  • Needs attention and features need to be enabled/controls added.
  • Minimal to moderate intentions of objective met.

F

Lowest possible grade, score may greatly contribute to risk.

  • Zero to minimal intentions of objective met.
  • Immediate attention and action are required.
  • Score likely to block the service.