-
Notifications
You must be signed in to change notification settings - Fork 11
Content of a metric
As a number one rule, the Continuous Audit Metrics catalog aims to gather metrics that are automatable: this describes measurements of security attributes of an information system that can be performed automatically, without human intervention.
Each metric in the catalog contains the following fields:
- Primary CCMv4 Control ID
- Related CCMv4 Control IDs
- Metric ID
- Metric Description ⭐
- Expression ⭐
- Rules ⭐
- SLO Recommendations ⭐
- Implementation guidelines
- Auditing guidelines
These fields are details hereafter. Contributors of new metrics should try to provide at least the fields marked with a start symbol above.
A primary security control in the CSA CCMv4 that can be related to the defined metric. Implementing the corresponding metric should provide measurements that can be used to partially or fully support the corresponding security control.
The reference to a CSA CCM control is somewhat arbitrary because in some cases a metric applies to more than one security control. Nevertheless, a reference to a CCM control is useful to show that the metrics are anchored in existing security practices and it provides a way to broadly identify what coverage is achieved in terms of security.
YAML: primaryControlId
A list of all other CCMv4 controls that are related to the metric in addition to the primary control already described.
A metric may be related to a control in at least two ways:
- The metric may provide assurance regarding the effectiveness of more than one CCMv4 control.
- The metric may rely on the assumption that other CCMv4 controls are in place because these other controls appear as necessary conditions for the proper implementation of the metric.
YAML: relatedControlIds (List)
A unique identifier of the metric.
Note: Each metric is provisionally named after the primary control ID to reflect the primary mapping.
YAML: id
A brief description of the metric.
YAML: metricDescription (Text)
A definition of the security attribute and its measurement method, which forms the core description of the metric. The expression is either:
- A mathematical formula describing the measurement; or,
- A description of the conditions and rules for performing the measurement of a security attribute.
YAML expression, a structure composed of the following fields:
-
formula: a string describing the metric's measurement method as a mathematical expression, as commonly expressed in programming languages like javascript or C (e.g. "100*A/B"). -
parameters: an array of elements further describing the variables that are used in the formula. Each element contains the following fields:-
id: an optional unique identifier for the parameter. If different metric formulas use the same parameter, these parameters should have the same id. -
name: the name of the parameter as it appears in the formula (e.g. "A") -
description: a human-readable description of the parameter.
-
A list of rules that MUST be followed to perform a measurement and obtain measurement results with this metric.
When the expression is a mathematical formula, the rules can be used to detail how different fields in the formula are calculated.
YAML: rules (Text)
Industry best-practice recommended objectives that organizations should meet, in terms of the measurement results obtained through the metrics (e.g., minimum expected level). This information represents a general recommendation—not a requirement—and it should be adapted to the organization’s risk profile.
YAML: Complex (to be detailed)
An optional set of guidelines and clarifications that may assist the reader in the interpretation and implementation of the proposed metric.
YAML: implementationGuidelines (Text)
An optional set of guidelines that describe how to assess the implementation of the metric, from an auditing perspective. An outline for audit guideline contents is in discussion. Follow Issue #17 for examples and details.