Metrics model in YAML alignment with CCMv4 Metrics Catalog v2

[mosi-k-platt]

There are some attributes in the YAML file that we do not have in the metrics catalog v2 Google sheet and we need to figure out how we want to handle them.

• measureName - Why do we need this attribute? If we keep it, should a naming convention be established?
• measureUnit - We need to define a list of standard units. Rich Seiersen basically defines two types of units in his BOOM metrics framework - counts and rates
• measureType - We need to define a list of standard types. Seiersen defines six different types in BOOM: counts, burndown, arrival and departure, survival, escapes.
• measurePeriod - We don't currently have this as a column in the catalog, but it may be defined in the rules or implementation guidelines for certain metrics.
• metricPeriod - A metric is the result of one or more measures, e.g. measure A divided by measure B provides the percentage reported in the metric. We need to decide if the recommended frequency in the catalog should be used as the metricPeriod.
• sloPeriod - We need to decide if the recommended frequency in the catalog should be used as the sloPeriod.

As the YAML file is completed, we also need to determine which file will be the source of truth for the metrics catalog - the YAML file or the Google Sheet. If we want the YAML file to be the source of truth, then there are fields in the Google Sheet that we may want to add to the YAML file.

[mosi-k-platt]

Decided during 20220114 working group meeting that all the attributes published in v1 of the catalog will be included in the yaml file.

[mosi-k-platt]

I will have all of the metrics from v1 of the catalog into metricsmodel.yaml by the time we meet on Feb. 4th.

[pritikin]

3/18 meeting notes

ADR: add a header fields to the yaml (do what is in the main csa example today)

name: Continuous Audit Metrics Catalog version: 1.0.0 url: https://cloudsecurityalliance.org/artifacts/the-continuous-audit-metrics-catalog/ ccm_version: 4.0.5

ADR: use this form for the metricExpression

metricExpression:

• expressiondescption: Percentage of compliant code:

  this structure means you can't define a measure w/o also defining the metric that uses it

  at some point we may need to manage versions of the catalog and thus wish to revisit this decision

  ADR: #1

  measures:

  • measureName: prod_apps_with_verification ideally we have the least number of these measureDescription: a description of the measure measureAlias: etc
  • measureName: prod_apps_deployed measureAlias: etc
• forumula: 100*A/B