Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(oscal): begin integration of composed oscal with validations (#496
) ## Description This change proposes the integration of [Lula](https://github.com/defenseunicorns/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](https://pages.nist.gov/OSCAL/about/) 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: ```bash 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: ```yaml - 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](https://public.cyber.mil/dccs/dccs-documents/) ### 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) - [x] 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)(https://github.com/defenseunicorns/uds-template-capability/blob/main/CONTRIBUTING.md#submitting-a-pull-request) followed --------- Co-authored-by: Andy Mills <[email protected]> Co-authored-by: Andy Mills <[email protected]> Co-authored-by: Micah Nagel <[email protected]>
- Loading branch information
4 people
authored
Jul 19, 2024
1 parent
30cbae4
commit 047fd30