Deliverable for May Timeframe

[JonathanChristopherson]

• Completed YAML File, technical description of metrics
• Roadmap describing the integration in STAR, and integration with other work at CSA
• Architecture Document

  • What we expect the system to look like, the requirements of the system that we expect an auditor to examine

[JonathanChristopherson]

Priorities for Code:

• Generation of measures
• Computation of measures into a metric
• Reporting the metrics into "something"

Chose 3 sample measures and show a thread all the way through to demonstrate what the end product will look like.

[pritikin]

The following captures an email from Alian to the working group on this topic:

---

After some discussion during our last meeting, followed by internal discussions within CSA, I'd like to confirm that our next goal is to produce new material in time for RSA 2022. During that event, CSA can advertise our work to a large audience.

This release should include:

A machine-readable version of the metrics catalog in YAML format, available on a GitHub repository. A whitepaper that accompanies the GitHub release. The first objective of a YAML metrics catalog is to encourage subject matter experts to contribute to the catalog through pull requests and issue submission on GitHub. Experts in security metrics are likely to have a technical background and should be comfortable with this approach. We hope that this will help us get input from a broader range of contributors, including people that are not interested in formally joining this Working Group.

The second objective of creating YAML metrics is to facilitate the development of tools that automate security compliance and testing. A YAML file can easily be referenced, versioned, remixed, or imported into a security application. In this context, CSA has started migrating some of its standards to YAML, notably the CCM v4. At this stage, the metrics catalog will likely be the first "public" release of a YAML artifact by CSA. The way the community uses and interacts with the YAML metrics will inform CSA's approach to future releases of machine-readable standards.

Recently, some working group members have been building a tool demonstrating the creation of measurements derived from the metrics catalog. This tool will use the metrics YAML file as an input, illustrating the value of a machine-readable document.

The whitepaper that accompanies the GitHub release should notably provide the following content:

An explanation of the YAML format. Instructions for contributors to the GitHub repository. A description of the value of a YAML metrics catalog, expanding on some of the ideas presented above. Use case descriptions and feedback, if available. Best regards,

Alain

[JonathanChristopherson]

Answer:

• What is the problem we want to solve?

[JonathanChristopherson]

We are trying to empower our users to take the next step forward by allowing machines to review metrics, freeing humans to mature their management and engineering. With this basis, here are some logical next steps.

[JonathanChristopherson]

• We need to discuss Audit process changes to take advantage of metrics- put in audit guide and white paper --different horizons, white paper is system view, audit guide is ground-level, metric-level horizon.
• Process changes include security tooling to provide metrics, IT vendor risk management both to service and to perform the risk assessment, possible Metrics Assessment as a Service.
• There are a number of controls met by shared responsibility model, can provide visibility/measurement to different areas of responsibility, and to enable consistent aggregation, collection, and display of all metrics for a system regardless of source, whether it's cloud service provider or consumer.

[pritikin]

We have a dependency on the data flow and system graph's before we can aggregate metrics. This is an interesting area of additional work but for now even being able to ask the question is a step forward.

The real value is probably that we can always drill down into the details of the aggregation.

[pritikin]

Max to do initial outline as markdown; and then we assign work from there (as distinct issues).

Just start within google docs so that we can collaborate faster. Move to notebook or whatever once we have a solid basis. (don't want to slow things down with PRs and new-to-us systems etc).

[JonathanChristopherson]

If we get everything in to the google docs, I can copy-n-paste over to the markdown/ipynb.

[pritikin]

A rough outline in google docs is started. This link should give access (permissions are limited to us active members): https://docs.google.com/document/d/1GUQzvNlp9rDRMqLnm4qitlxziNplQ1i7h4kVOpFMY2s/edit?usp=sharing

[pritikin]

3/2 meeting note: May 6th (friday) is our target deliverable.