chore(oscal): begin integration of composed oscal with validations

[brandtkeller]

Description

This change proposes the integration of Lula with uds-core for the purposes of compliance assessment on Pull-Request. This Proposal includes:

• all proposed future changes meet the minimum threshold for compliance
• framework established for iterating control body-of-evidence
• process for consuming uds-core compliance for downstream utilization

How does it work?

Each component that comprises uds-core contains an OSCAL file in the form of the component-definition model. This captures 1 -> N controls for 1 -> N standards (control implementations) that pertain to a specific component.

When controls are identified as implemented by a component, we can create or update a component-definition artifact through:

lula generate component -c <catalog-source> -r <controls-comma-delimited> --component "component name>

Validation

Lula operates on a model where controls are marked as satisfied when presented with programmatic and repeatable processes to to produce evidence that the control is satisfied.

These are often developed on a control-by-control basis and then composed into a single OSCAL component-definition in a schema-compliant addition in the back-matter. Reducing required network connectivity and making the compliance information portable.

One control may require evidence from many validations. One validation is the collection of data from some source and the measurement of that data for required adherence.

The lula validate operation is an objective assessment - determining control satisfied/not-satisfied state and writing the results to the assessment-results artifact.

Evaluation

The last step for determining greater, equal, or lesser compliance than the previous state is to execute a lula evaluate. This consumes the latest result in the assessment-results artifact and compares it against the threshold result.

The threshold result is identified as the result containing the following prop:

- name: threshold
   ns: https://docs.lula.dev/ns
   value: "true"

If the compliance of this latest result is worse than the threshold - the execution fails with a non-zero exit code - allowing for pipeline operations to fail.

If the compliance is equal - the command passes without any modification required.

If the compliance is greater - Lula will automatically move the threshold identifier to the applicable result item. (this would mean that the updated assessment-results artifact should be downloaded and submitted for update to the repository).

Naming

All files are titled with "oscal-" prepended to the OSCAL model type:

• oscal-component.yaml -> component definition
• oscal-assessment-results.yaml -> assessment results

This is primarily to allow for identification for linting workflows to target oscal files for Lula to Lint.

Metrics

The following are derived from the FedRAMP Moderate baseline:

24 controls of *329 total* mapped in OSCAL from Istio (7.29%)
24 controls of *161 total Technical* mapped in OSCAL from Istio (14.90%)
75 Unique controls captured in OSCAL of *329 total* (22.79%)
10 controls marked satisfied in OSCAL of *329 total* (3.03%)
75 Unique controls captured in OSCAL of *161 technical* (46.58%)
10 controls marked satisfied in OSCAL of *161 technical* (6.21%)

Note

DISA has recently published a new revision to the Cloud Computing Security Requirements Guide which may result in future iterations to a small subset of controls when reconciled.

DISA link

Review

The Lula team is actively working to make the review process better. Composed OSCAL has it's benefits for portability but that comes with the drawbacks of review.

To assist with the review process:

• Ensure the pipeline additions are sound
• Review the src/istio/oscal-component.yaml file. This will map controls to the current state of validations.
• Understand the connection of compliance/oscal-component.yaml to the individual components under src/

Troubleshooting

If the pipeline should begin failing in the future - notify the @defenseunicorns/lula-dev team.

It should be expected that any major revisions to applications could break known assumptions about configuration required for compliance. The Lula team can help navigate failures.

Related Issue

Resolves #458

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps(https://github.com/defenseunicorns/uds-template-capability/blob/main/CONTRIBUTING.md#submitting-a-pull-request) followed

[github-actions]

Compliance unicorn Evaluation: success

CC: @defenseunicorns/lula-dev

[mjnagel]

Two small comments but this LGTM! Thanks for all the hard work here @defenseunicorns/lula-dev

[rjferguson21]

Approving with intent to track https://github.com/defenseunicorns/compliance-artifacts/issues/51