OSCAL Norms for Multi-Project Collaboration

[jflowers]

trafficstars

Problem

Today, open source projects do not have a consistent mechanism to publish compliance and regulatory details about what the project does in a machine readable format and to enable assessment activities to occur in an automated manner. Adopters do not have a way to understand what capabilities and controls projects have in place and what their responsibilities as consumers are as defined by the leveraged project.

Adopters today have to manually review a given software project, understand based on existing documentation if it can meet a compliance or regulatory requirement, and then determine if it does it already or if it's configurable by the adopter. They have to do this with every release. If 1 project decides to express this in one manner, another may choose a very different one and the adopter now has two ways in which they can’t reason about the compliance properties of both projects. We need a specification and guidance to allow projects to consistently and uniformly express their compliance capabilities and posture for adopters to act on.

Other areas

• Project to project dependencies for compliance requirements
• Consumption of compliance metadata/information
• Standardization on language for expression (OSCAL recommended)
  • Has the needed evidence and the reporting for what auditors need alongside evidence
• Tie in with policy engines in a consistent way to avoid vendor lock-in

Impact

Depending on the shape and nature of this project, the desired experience by adopters of cloud native projects is that when they deploy a given project the project contains sufficient metadata that in combination with a policy engine allows for decisions on whether a piece of software is permitted to be deployed in the target environment.

Such metadata shows how the project can achieve compliance (with configurations) and how it HAS achieved compliance (based on its design and operation in a given deployment environment). The evidence can also be turned over to auditors in an automated fashion to enable reasoning about system properties and conformance with regulatory requirements on a continual and ongoing basis driven by deployment frequency thereby reducing the manual audit (internal and external) activities performed by covering the technical control elements (roughly 30% of a given framework like NIST))

A lot of organizations just use hundreds of spreadsheets with 1 compliance engineer to automate. Spot checking is not good enough here.

Deliverables

The project will deliver the following artifacts:

1. API Exchange Specification: A formal specification defining the structure and semantics used to communicate compliance and regulatory activities within the OSCAL framework, including support for OSCAL fragments within the workflow depicted in the diagram. See the existing Miro diagram for example exchange points. As an example, Cloud Events could be how this is delivered.
2. Diagram: A visual representation illustrating the interactions and relationships between various components and processes involved in compliance and regulatory activities, including the use of OSCAL fragments. (current Miro diagram)
3. Explanatory Documentation: Comprehensive documentation providing detailed explanations of the diagram and the API specification, facilitating understanding and adoption, with specific emphasis on the role of OSCAL fragments in the workflow. The documentation will also include concrete examples to illustrate the practical application and benefits of the defined API specification and the workflow diagram.

Scope

The project encompasses the following activities:

1. API Exchange Definition: Collaboratively define and standardize API exchange that capture essential compliance and regulatory activities, ensuring interoperability and consistency across different tools and platforms. Specifically supporting the exchange and processing of OSCAL fragments within the context of the diagram's workflow.
2. Diagram Development: Create a diagram that visually depicts the flow of compliance and regulatory information, highlighting key interactions and dependencies, and explicitly illustrating the integration and utilization of OSCAL fragments. (current Miro diagram)
3. Documentation Creation: Develop clear and concise documentation that explains the diagram and the API specification, enabling users to effectively leverage the framework. The documentation should provide specific guidance on how OSCAL fragments are incorporated into the workflow in the events or activities that support their usage. It will also include concrete examples to demonstrate the practical implementation and advantages of the proposed framework.
4. Community Engagement: Foster active participation and collaboration within the open-source community to gather feedback, refine the deliverables, and promote widespread adoption.

By delivering these artifacts, the project aims to establish a robust foundation for standardized communication and automation of compliance and regulatory processes within the cloud-native ecosystem, with explicit support for the flexible and granular exchange of compliance information through OSCAL fragments.

Intent to lead:

• [X] I volunteer to be a project lead on this proposal if the community is interested in pursing this work. This statement of intent does not preclude others from co-leading or becoming lead in my stead.

Proposal to Project:

• [x] Added to the planned meeting template for 10/16
• [x] Raised in a Security TAG meeting to determine interest - 10/09
• [x] Collaborators comment on issue for determine interest and nominate project lead: @jflowers
• [X] Scope determined via meetings, slack, and document
• [X] Call for participation in #tag-security slack channel thread and mailing list email
• [x] Scope presented to Security TAG leadership and Sponsor is assigned

• Slack Channel

• Meeting Recordings

• Google Group

• [x] Security TAG Leadership Representative: @eddie-knight

• [x] Project leader(s): @jflowers

• [x] Issue is assigned to project leaders and Security TAG Leadership Representative: @eddie-knight

• [x] Project Members:

• @jflowers

• @jpower432

• @iMichaela

• @degenaro

• [X] Meeting Time & Day: Every other Thursday from 1:00 - 1:45 EST

• [X] Meeting Notes

• [X] Meeting Details https://zoom-lfx.platform.linuxfoundation.org/meeting/93101840611?password=6baa3eeb-704d-4001-9b67-4ecdfef3397e

TO DO

• [X] Scope
• [X] Deliverable(s)
• [x] Project Schedule
• [ ] Retrospective

If you prefer to access the existing Miro diagram anonymously use this link. GDoc Draft