search

cncf / tag-security

🔐CNCF Security Technical Advisory Group -- secure access, policy control, privacy, auditing, explainability and more!
https://tag-security.cncf.io
Other
2.09k stars 520 forks source link

OSCAL Norms for Multi-Project Collaboration #1277

Open jflowers opened 5 months ago

jflowers commented 5 months ago

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

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:

Proposal to Project:

TO DO

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

rficcaglia commented 4 months ago

So would this ask all CNCF projects to produce OSCAL components + an SSP (+ maybe CIS/CRM?)

jflowers commented 4 months ago

No, at least that has not been in my mind.

jflowers commented 3 months ago

Hey @brian-comply0, would love if you could join us on this project!

brandtkeller commented 1 month ago

Discussion captured at todays STAG Meeting:

Broad Objective - “This is how we should be able to exchange information in OSCAL”

Q: “How can we address the ambiguity within the scope of the deliverables?” Action item: conduct more discovery to dissect and determine what will be done

“The OSCAL norms seeks to provide clarity through opinionated standard use of OSCAL“

Q: What is the alternative? What Problem can we point to for the specific pain points? A: Project to consider the consequences of not performing this activity.

Q: How do we get there? A: Experimentation

Q: What is the intended deliverable medium? (WP, diagram, artifact?) A:TBD on what this guidance artifact format is.

Q: What level of sponsorship is the project requesting? A: Official Project Status

STAG Sponsorship - Eddie Knight Needs a new name (shorter)

Project Lead (Jay Flowers) accepts the initial step in the process for group formalization .

Feel free to comment if I missed anything or we want to clarify any points.

knowlengr commented 1 month ago

I concur with the general approach being taken with metadata. If I can be of assistance with this facet of the issue, let me know.

-Chair, IEEE P2957 Big Data Interoperability and Metadata Management

On Thu, Jun 13, 2024 at 11:01 AM Jay Flowers @.***> wrote:

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.

Scope: How much effort will this take? ok to provide a range of options if or "not yet determined" for initial proposals. Feel free to include proposed tasks below or link a Google doc

Intent to lead:

- 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:

  • Added to the planned meeting template for mm dd
  • Raised in a Security TAG meeting to determine interest - mm dd
  • Collaborators comment on issue for determine interest and nominate project lead
  • Scope determined via meeting mm dd and/or shared document add link with call for participation in #tag-security slack channel thread add link and mailing list email add link
  • Scope presented to Security TAG leadership and Sponsor is assigned

TO DO

  • Security TAG Leadership Representative:
  • Project leader(s):
  • Issue is assigned to project leaders and Security TAG Leadership Representative
  • Project Members:

  • Fill in addition TODO items here so the project team and community can see progress!

  • Scope
  • Deliverable(s)
  • Project Schedule
  • Slack Channel (as needed)
  • Meeting Time & Day:
  • Meeting Notes (link)
  • Meeting Details (zoom or hangouts link)
  • Retrospective

GDoc Draft https://docs.google.com/document/d/1uZ1qSVAGoRL117JDdTO4KSQWwNsHUnjxwTfg1N7HaW4/edit

— Reply to this email directly, view it on GitHub https://github.com/cncf/tag-security/issues/1277, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABG5HAL3UIPRARR7TJWOW4DZHGX4LAVCNFSM6AAAAABJIS6BYGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2TCMZYGI4DOMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Mark Underwood Linkedin https://linkedin.com/in/knowlengr

eddie-knight commented 1 month ago

@jflowers will be opening a PR with a project charter, and I will submit a request for a community calendar entry so that calls are hosted and recorded via LFX.

Per today's project call, the next project meeting will be focused on ways of working with a focus on research / experimentation.