Support parameters in components

[bradh]

User Story:

As an OSCAL component producer, I want to be able to use parameter substitution to populate boilerplate text in components.

Examples of this might be the organisation or system name, which are used over and over. Those could be kept in one (shared) file and imported / resolved for each component. The name of the position / person associated with certain roles might also be candidates for this, which might only appear in the component file.

Goals:

I want to be able to provide literals for substitution into components, similar to (perhaps the same as) the way it works for param in catalog.

As a stretch goal, it might be useful to have conditional / boolean values that can invoke parts of the component based on install options. For example, (SIMP component for Apache)[https://github.com/simp/simp-doc/blob/master/docs/security_mapping/components/apache/mandatory_access_control/control.rst] has this:

When SELinux is enabled in SIMP, Apache is configured to run within a context.
That would be good to avoid, by use of a boolean / configuration value that reflects whether SELinux is enabled.

Dependencies:

Somewhat dependent on component maturation, but otherwise none identified.

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.
• Examples showing how this works are included.
  {The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[butler54]

Just wanted to add to this requirement. While I do not see the requirement necessarily at the root component level - from my experimentation I believe there may be a need for both properties and params at the control implementation level.

Happy to connect with some thoughts and examples.

[butler54]

So I want to give this issue a bit of a bump as we've been experimenting with how parameters can be set and propagated through a system using OSCAL.

Some context: I happened to log onto gitter to see this message (below) and there is some diverge between what @brianrufgsa stated and the original throughts that we had.

Brian Ruf @brianrufgsa Oct 02 03:04
...... It's not directly. The concept is vendors can publish the component-definition files that a tool could then use to import content into the SSP. There is no intended direct linkage between the two.
For example a component-definition model might have information about a product, as well as a series of configurate options for complaince with various baselines. If you were creating a FedRAMP Moderate SSP, you would only import the FedRAMP or FISMA moderate portion of the component-definition content.

My original thinking was that a component-definition was an independent statement on the compliance configuration of set of components. This is different to @brianrufgsa's statement above. However, in the use I described for components we hacked up a target-definition (not wedded to the name) (see here: https://github.com/IBM/compliance-trestle/blob/develop/3rd-party-schema-documents/IBM_target_schema.json) which provides a templated component. E.g. vendor statement with some options a particular implementation can use.

The idea was that we needed a vehicle to express the potential configuration of a service. In particular what we noticed was that there was a tendency to want to express parameters at the control-implementation or component level in addition to the implemented-requirement level in the schema.

E.G. There seems to be a need for parameters which span across controls which relate to a component. Particular implemented-requirements may set specific values for those controls where there is an explicit requirement.

If parameters are NOT tied to particular controls - there are follow up issues in the SSP as the SSP presumes that parameters are set w.r.t a particular implemented requirement.

[brian-ruf]

@butler54 we've had some internal conversations it it turns out my statement was incorrect about no direct linkages between a component-definition file and an SSP - beyond import. It turns out that concept was previously discussed among others, and I wasn't aware.

Currently the syntax doesn't officially support this; however, we believe its just a matter of defining a few property names in the correct places in the SSP syntax.

You are correct that component-definition files are also intended to address component satisfaction of different target definitions. The biggest difference being that is no guarantee of how the component will actual protect something in the context of a specific system.

For example, the exact same component configured the exact same way within a system could be assessed very different given placement in front of the firewall, behind the firewall, or on the admin-only network. That is before you you consider potential configuration tweaks that may vary at each of those deployment points.

All of that said, I'm intrigued about your suggested use of parameters in this context, and think I'm starting to get your point, but need more time to let it sink in. Admittedly, component-definition hasn't been getting much attention recently for reasons not appropriate to share here. We would love to see any of our vendor partners rejuvenate the component-definition modeling efforts in advance of our ability to circle back to it.

[butler54]

On your comments w.r.t. guarantees on on satisfying a control - I agree. Every control-implementation made in a component definition is almost inherently 'partial' due to the lack of context which you described.

The key piece here from a tech vendor perspective is that clients want to understand what tools you have to 'help' them with various controls - in a similar way https://github.com/complianceascode/content tag xccdf rules with NIST / PCI / ISM / other controls.

Under this usecase - the expectation I have would be component-definition becomes the index of capability - explicitly because it is not coupled to an assessed system.

The thought I have in the back of my head from an automation perspective is effectively this. Given a user's profile and a user provided list of components they are leveraging - it's possible to partially fill the content in an SSP. This will not be perfect, however, may be of use in many scenarios.

[brian-ruf]

@butler54 yes, that is one of the goals for component-definition, but it hasn't received much attention or vetting.

In theory, a component-definition can point to several baselines (profiles), and provide control responses in the context of each baseline.

The idea is that an SSP author selects components, and based on the baseline (profile) identified in the SSP, only the relevant control response content is imported.

In theory, there are also configuration scripts and/or guidance associated with that baseline as well to somewhat auto-configure the component to align with a baseline.

Another goal/vision in mind for component definition are inspection scripts/steps, which an assessor's tool can use to query for the current setting and compare it to the prescribed setting. Likewise, this can be used in a continuous assessment or as another form of continuous monitoring. It could help auto-configure NOC/SOC alerts, etc.

I'm not sure how much of that is implemented. I believe that is more of an OSCAL 2.0 feature.

Back to your original parameter question - one clarification:
Are you talking about parameters in the context of the profiles to which you link. (i.e. if FedRAMP Moderate, AC-2 parameter 4 has ___ value, this is the setting)?
Or are you talking about parameters within the context of the control response?
Something else? (what am I not seeing?)

[butler54]

So on the question of parameters. I was talking about this (parsing your language) in the control response. I'll provide a bit of an example which hopefully will highlight the need.

Say that I wanted to consume a DBaaS from a cloud service provider. Let's presume that their are two encryption option:

1. Where the CSP manages the encryption keys
2. Where the user manages keys through a key management store.

So the kind of parameter for this component / control-implementation is a choice of the encryption method.

In this scenario SC-28 is agnostic to the encryption method. SC-12 on the other hand would (in implemented requirement) mandate that the encryption_option == user provided KMS.

This would allow us to basically express where controls constrain the 'configuration' of a component.

You can imagine a similar scenario where a component has declared support for multiple catalogs where a parameter affects control support across catalogs.

I hope this helps.

[david-waltermire]

Pushing this to the OSCAL 1.1 release.

[Arminta-Jenkins-NIST]

At the 11/16 Triage Meeting: This issue will be closed on Nov 24, 2023 if there isn't a written response before that time.