feat(generate): support for profile model and basic generation

[brandtkeller]

Description

Adds initial support for the profile model with some very basic generation functionality to build upon.

Looking to implement an OSCAL model interface for two reasons:

1. validate the necessity of the interface across models
2. experiment now vs future alignment with the underlying library possibly changing

There is a lot to unpack with support for a new model. Doing research and looking to document findings but ultimately believe the majority of complexity will be wrapped into processing of a profile for use with another model (either upstream in a catalog or downstream in a component/ssp).

Intent is to document and further decompose both profile issues as well as oscal model issues.

Related Issue

Fixes #67

Relates to #

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
• Schema Updates applied
• Contributor Guide Steps followed

[meganwolf0]

probably going to play with it more/give more thought to the OSCALModel interface, but just to kick back some thoughts as a starter

[CloudBeard]

I know this isn't OSCAL Schema compliant but Lula functionality wise what do you think about a situation where you want to create a profile for IL4 using FedRAMP Moderate that would introduce the need to add the control AU-5(1) which isn't in the baseline so that control should come from the FedRAMP High Baseline.

Im thinking command/functionality wise allowing multiple sources, have something like -ia (include-all, for Moderate baseline), and -i for the specific controls in High Baseline.

Reconcile what that would actually look like in OSCAL but a quick way to say give me all of FedRAMP Moderate and this control(s) from High.

(Also don't think this blocks this PR, its more of a future request/thought)

[brandtkeller]

I know this isn't OSCAL Schema compliant but Lula functionality wise what do you think about a situation where you want to create a profile for IL4 using FedRAMP Moderate that would introduce the need to add the control AU-5(1) which isn't in the baseline so that control should come from the FedRAMP High Baseline.

Im thinking command/functionality wise allowing multiple sources, have something like -ia (include-all, for Moderate baseline), and -i for the specific controls in High Baseline.

Reconcile what that would actually look like in OSCAL but a quick way to say give me all of FedRAMP Moderate and this control(s) from High.

(Also don't think this blocks this PR, its more of a future request/thought)

I was going to move it off to another issue but you gave me to motivation to support an --all flag for importing all controls.

I believe we can accomplish the scenario above with a few commands. Processing that will be another story and scope for another issue I will write.

[meganwolf0]

I was going to move it off to another issue but you gave me to motivation to support an --all flag for importing all controls.

Trying to follow the train of thought in the thread, but would --all not be the default if include or exclude wasn't provided? I guess, what happens in no flag vs --all?

[brandtkeller]

Trying to follow the train of thought in the thread, but would --all not be the default if include or exclude wasn't provided? I guess, what happens in no flag vs --all?

Great point - that was a gap. Added a OneRequired for the flags to lean into explicit vs default.

[meganwolf0]

Approved! Are we going to create follow-on issues to reconcile the OSCALModel interface across the other models we have?

[brandtkeller]

Approved! Are we going to create follow-on issues to reconcile the OSCALModel interface across the other models we have?

Added issues as referenced a few hours ago