Improve Lula validation identifier

[brandtkeller]

Currently links and resources require very specific naming Lula Validation in order for lula to know and execute validations in the OSCAL.

Evaluate existing fields for implemented-requirements and backmatter.resources for a better identifier that is less likely to incur errors due to typos.

[brandtkeller]

Discussion around investigating the use of props for the reference of Lula validations.

Considerations here for how GRC tooling could possibly support.

[CloudBeard]

What if we move around the text/rel in the links like Cole mentioned to make it better than just text matching and extend by adding any supporting context around the validation with props that GRC tools could use.

Since props brings class/groups I can see relevance there for tracking/supporting information for validations and controls to provide greater context especially to UDS Engine.

[brandtkeller]

@CloudBeard can you elaborate on:

adding any supporting context around the validation with props that GRC tools could use.

Wanting to understand what you see this extension augmenting.

[brandtkeller]

Thinking about the use of links more and the OSCAL Extension docs we have two problems we want to solve for:

1. Create a better utilization of links for identifying a Lula validation exists in the back-matter (Current workflow to-date)
2. Create a workflow that allows targeting an external file

For scenario 1:

links:
    - href: '#a7584118-3d2d-46c8-b388-df747309c0fa'
      rel: lula
      text: Some lula validation - no string matching here

For scenario 2:

links:
    - href: './path/to/the/validation/file.yaml' or 'git://gitrepo_url' or 'oci://registry' etc
      rel: lula
      text: Some lula validation - no string matching here

But how can we reference a unique validation in an artifact that contains 1 -> N?

[meganwolf0]

Could you do the href as the path to the file + "#{uuid}"? Seems like the href is kind of flexible so maybe could do something like that. So we'd have to maybe have validations of format:

a7584118-3d2d-46c8-b388-df747309c0fa:
  target:
    ...

or maybe

metadata:
   uuid: a7584118-3d2d-46c8-b388-df747309c0fa
target:
   ...

I'm sure there's some implications either way

[brandtkeller]

Yeah I think we can experiment with where to put that identifier in the href potentially.

As for validation - I had brainstormed your second option and considered the conversion between yaml manifest and embedded item in the back-matter.

IE the link to the back matter would include the UUID for the back-matter resource item (as we have it to-date). When you ran the command to pull the validations - it would use that UUID and place it inside the validation. Possibly redundant to have it in the validation when embedded but worth consideration.

[CloudBeard]

Thinking items like: (some of this is out of scope for the issue)

If a control is partially implemented move that from remarks into props.

props:
  -name: implemented
    ns: https://lula.dev/ns/oscal
    value: partially

If a control is partially implemented or can only be partially automated and needs to be examined/interviewed to fully meet a control. (could pull this out of the validation manifest so its more focused on validations)

props:
  -name: method
    ns:  https://lula.dev/ns/oscal
    value: EXAMINE

If we add in several control-implementations: we can map more than just the ILs we need from NIST 800-53. Do all of a High/Moderate profile and add these on the controls that match that so when we use a manifest/CLI to say I want FedRAMP Moderate IL4 we can grab the IL controls from the NIST 800-53 controls.

props:
  -name: impact level
    ns:  https://lula.dev/ns/oscal/il
    value: 4

Maybe an edge case that im not 100% sure of yet but if its partially implemented but you know which other tool meets the other half use a prop to identify that. Its more relevant when evaluating on a SSP instead of a component definition if you can tie them together and have it come out in the SAR as implemented because it checks all of the validations that are grouped? Still not 100% sure on the looks yet, thinking having the UUID from the other may be needed but initial thoughts.

props:
  -name: implemented
    ns: https://lula.dev/ns/oscal
    value: partially
    group: authentication (thinkning keycloak and authservice?) 

Maybe put a prop on the component to create the "group" and from there frees up the implemented requirements to link UUIDs?

component-definition:
  uuid: 8a9a32e4-e847-4f59-8282-b1cbc8d4e98f
  metadata:
    title: UDS Capability Keycloak
    last-modified: "2023-12-01T20:09:06Z"
    version: "20231201"
    oscal-version: 1.1.1
    parties:
      - uuid: f3cf70f8-ba44-4e55-9ea3-389ef24847d3
        type: organization
        name: Defense Unicorns
        links:
          - href: https://defenseunicorns.com
            rel: website
  components:
    - uuid: 9f1c741f-caf0-4d67-8ffe-b0f180132f46
      type: software
      title: Keycloak
      description: |
        Keycloak is an open-source, self-hostable identity and access management tool.
      purpose: Provides users with secure authentication and authorization capabilities.
      responsible-roles:
        - role-id: provider
          party-uuids:
            - f3cf70f8-ba44-4e55-9ea3-389ef24847d3
       props:
         -name: supporting component
           ns: https://lula.dev/ns/oscal/supporting-component
           value: authservice
           group: authentication

Could also use it to add in any details we are missing when we need to make the jump to SSP/SAP/POAM. If its not in the catalog or dosen't make sense to augment that could add to props on the component definition. This out of scope for lula validation identifier but just for props in general for augmentation.

I do think we take it a step further and the uri we use for the namespace either on our doc site or internal to the repo docs we add a doc to explain what its doing and what you can expect to see there.

[brandtkeller]

I believe there is a lot of potential we still need to investigate through the use of a lula namespace in OSCAL and the use of props. (Maybe we start documenting that in this issue: https://github.com/defenseunicorns/lula/issues/134)

The use of props and how validations are built are not mutually exclusive. What we want to do is control disparate context. Links and Props exist kind-of isolated from one-another and creation of dependencies between the two should be done carefully.