Explore a Lula namespace for OSCAL props

[CloudBeard]

Initial Thought

Create a Lula namespace for OSCAL props to extend OSCAL.

First example is to create an identifier for partially implemented controls. Could be picked up by tools but aslo humans to see that the control isn't fully implemented yet.

Creating a namespace would allow us to add more over time if/when we need to extend OSCAL for things specific to Lula.

Why

Currently the default NIST namespace only supports the prop name of markings.

There is not public documentation around best practices or standards yet.

Start norming around using custom props and/or creating issues with NIST to have them adopted where it makes sense.

What

Use the URI of https://lula.dev/ns/oscal (place holder for site) to start using custom props.

First prop:

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

[brandtkeller]

Included in this statement of work would be:

• Partially vs fully implemented identifiers (and dependency information for partial state
• Support for validation "types" IE Healthcheck vs Override vs standard

[CloudBeard]

Updating from other issues:

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.

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.

[CloudBeard]

I believe determining tech/admin controls will need to go into props #237

[CloudBeard]

Possibly #327 for identifying multiple/different frameworks - this one could go other directions but props is one.

[CloudBeard]

During initial POC of report cmd #372 I think we will need to use props to add the data above like tech/admin, impact levels, partiall/fully implemented, and future items.

Current thought is on reporting tech/admin controls mapped in componenet definitions we'd need a way to label those. Would also allow others to challenge our thoughts on which are tech/admin and see X validation to support a stance one way or the other.