Reusability of Components

[openprivacy]

Given SSP that imports agency-profile that imports 800-53-catalog, can the SSP's system-implementation reference a (reusable) CDEF whose control-implementation sources 800-53-catalog? (Somewhat related to #1177 and #1080)

Using files in https://github.com/CMSgov/ars-machine-readable/tree/main/ODP-extract as an example:

• ars-5.0-moderate-catalog.xml sources ars-5.0-moderate-profile.xml which imports ars-5.0-catalog.xml which is a “derivation of” NIST_SP-800-53_rev5_catalog.xml
• If I have an SSP that imports ars-5.0-moderate-catalog.xml can it contain CDEFs that source NIST_SP-800-53_rev5_catalog.xml which would make them reusable as advertised?
• Note that things get a little sticky if this CDEF implements a control from the NIST catalog that has been removed from the ARS catalog.
• Or would the CDEF need to be specific to ars-5.0-moderate-catalog.xml which limits its general reusability?

[GaryGapinski]

Related (but not necessarily CDEF-related): I intend to undo a previous decision which excised all non-baselined controls from the fundamental ARS 5 (derived from 800-53 rev5) control catalog. I recently noticed that someone at NIST failed to employ control SC-45 and its enhancements in SP 800-53B rev5.

[aj-stein-nist]

OK, to understand better the team I probably need to sit down and look at the CMS ARS content cited above, with or without this change, to keep in mind when answering this question. Need to mull that over. Thanks for pointing it out.

[aj-stein-nist]

Before we try to proffer an answer: the quick summary is: a component in a component-definition has control requirements that specify its source, a SSP points to its own as well separate of the imported components it gets from that other instance, how do we look at the final resulting SSP and know: are we pointing to the CM-1 in different catalogs across a smattering of controls, can it reference different controls that may be from 1 or more catalogs at the same time?

[openprivacy]

Wading into the waters...

As it stands, the source of a component in a component-definition must match the profile or catalog imported by the SSP or the component can’t be validated - which severely limits the ability to have reusable components.

What if the SSP imports a profile or catalog that back-traces deterministically to the component source? If an intermediate profile (to the SSP) tailors out a control that appears in the component, one could ghost that control.

[sunstonesecure-robert]

In the abstract isn’t the question when a component definition pulls in controls from 2 different sources, even if they are human text indistinguishable, they are still separate controls to a machine “validation”. Therefore to reuse a component def and have all controls satisfied, there may need to be some way to express/assert/test that catalog A control X is equivalent to catalog B control Y? This is in an attempt not to have duplicate effort and reduce bloat. ASIDE: in maybe a different context, thinking about a compiled exe, if I use function/class foo from lib X in one scope, and function/class foo from lib Y, i by default get 2 different copies either statically linked in or 2 entries in some symbol lookup table for later dynamic loading. There might be some equivalent to a gcc compile flag or linker/dlopen flag to override the default. But I would need to tell the compiler or linker what I want. Or is that different from the problem reported?

[iMichaela]

@openprivacy - I am a little confused over the example provided. It appears that the focus is on the controls a component will provide to the system if it is part of the system. But components implement controls for their secure operations as well. To me, a control provided by a component is different than the controls implemented by that component.

If:

• the NIST profile is Moderate and
• the Agency profile is: AC-3, AC-17(2), SC-7, with AC-17(2) tailored to require TLS 1.3

If Component 1 is a firewall appliance, it will provide SC-7 control to a system it is part of but will need to enforce the access (implement AC-3) to protect the rules for being modified by unauthorized entities and supports remote access (AC-17) by implementing VPN and TLS 1.1.and 1.2 only. Please note: without AC-3 and AC-17, the appliance will not be able to provide the expected SC-7 boundary protection since a malicious actor could change the rules.

If Component 2 is a Wi-Fi router , also a component of your system, which implements the AC-3 and the AC-17(2) by supporting TLS 1.3 once configured.

In your SSP, AC-17(2) -> by-component can not be satisfied by the Component 1 as described above, even though the agency's AC-17(2) is derived from the NIST AC-17(2) implemented by such component. If the Component 1 would support TLS 1.3 then yeas, the component can be reused, but somebody needs to review and decide and give thumb up or thumb down.

I hope this example explains the point I was trying to make in my earlier comment when I stated that a component implementing NIST controls cannot be automatically reused for a system implementing agency controls unless no tailoring was done.

[aj-stein-nist]

Can we get together and have a more simplistic example to work through the issue, @openprivacy and @iMichaela?

[openprivacy]

@aj-stein-nist - yes, but I just wrote this so I'll go ahead and post it:

@iMichaela - Thank you for this clear explanation. Generally, I think of a CDef for a given implementation of hardware, software, etc. possibly having multiple component implementations with different sources (say rev4 and rev5). A CDef capability for e.g. boundary protection might import multiple CDefs, each defining a single component, such as a firewall or a router.

With respect to “AC-17(2) tailored to require TLS 1.3”: As TLS versions will continue to rise, they may best be defined by an ODP such as sc-13_prm_2 [Assignment: organization-defined types of cryptography for each specified cryptographic use] so that an automated assessment can look up the acceptable TLS versions and confirm that the firewall appliance correctly implements TLS 1.3 as well as 1.1 and 1.2 - or fail the test.

[iMichaela]

Can we get together and have a more simplistic example to work through the issue, @openprivacy and @iMichaela?

Sure. Please feel free to send a meeting invitation. You can see my calendar.

[iMichaela]

@aj-stein-nist - yes, but I just wrote this so I'll go ahead and post it:

@iMichaela - Thank you for this clear explanation. Generally, I think of a CDef for a given implementation of hardware, software, etc. possibly having multiple component implementations with different sources (say rev4 and rev5). A CDef capability for e.g. boundary protection might import multiple CDefs, each defining a single component, such as a firewall or a router.

I agree. And this is the reason for my comment indicating that there si not simple answer if a CDef is reusable , generally speaking, just because the implemented controls are 'derived from'.. ..

With respect to “AC-17(2) tailored to require TLS 1.3”: As TLS versions will continue to rise, they may best be defined by an ODP such as sc-13_prm_2 [Assignment: organization-defined types of cryptography for each specified cryptographic use] so that an automated assessment can look up the acceptable TLS versions and confirm that the firewall appliance correctly implements TLS 1.3 as well as 1.1 and 1.2 - or fail the test.

Indeed. Best practices are important. My example was trying to highlight ONE CASE where the general 'reusability' rule is not applicable. A simple math theorem is easy proven wrong if one can find examples that do not follow it. You just demonstrated that the correct answer to 'reusability' is: THE CDEF REUSABILITY DEPENDS ON THE IMPLEMENTED CONTROLS (NOT ONLY WHAT IS IMPLEMENTED, BUT ALSO HOW IT IS IMPLEMENTED) .

[iMichaela]

Given SSP that imports agency-profile that imports 800-53-catalog, can the SSP's system-implementation reference a (reusable) CDEF whose control-implementation sources 800-53-catalog?

@openprivacy - if this would be my case, I would need to ensure that either the 800-53 profile did not tailor the controls implemented by the component definition OR, the suggested implementations 'magically' matches the tailored control(s)

ars-5.0-moderate-catalog.xml sources ars-5.0-moderate-profile.xml which imports ars-5.0-catalog.xml which is a “derivation of” NIST_SP-800-53_rev5_catalog.xml

Since the controls are derived AND have the chance of being tailored in the profile, it most likely they are no longer equal. Sometimes an implementation might satisfy an equivalent controls by pure luck. So the system owner could use a CDef that sources NIST controls but ONLY as an example and not as a valid implementation. If you want to get fancy though, maybe a smart GRC tool could use NLP-based analysis to determine the deviation from the original NIST 800-53 control to determine if the existing information available in the CDef can be used as a suggestion or example or, if it will be more confusing, then it would provide no suggestions.

In this case and the one above, while the available control implementation could be rendered as a suggestion, should not be used in an automatic fashion and the system owner will have to confirm the control he/she is implementing is the agency-profile control for which the suggested implementation is still good even though it was initially written for another 'version' of the same control.

Or would the CDEF need to be specific to ars-5.0-moderate-catalog.xml which limits its general reusability?

If I would want to automate the process and populate the control implementations blindly, yes. BUT my system owner will still be responsible for accepting those implementations.

These are my views and what I would do, based on my risk tolerance :) OSCAL is not prescriptive. RMF requires the tailored controls (agency-profile) to be implemented and not other variations of those controls.

[GaryGapinski]

RMF requires the tailored controls (agency-profile) to be implemented and not other variations of those controls.

I have recently realized that the concept of OSCAL profile resolution does not admit inclusion of "optional" controls.

Specifically, a "resolved catalog" will not contain controls which are not deliberately included by the profile. Were a profile to include all controls, there is no obvious|sanctioned|fundamentally-OSCAL way to indicate that "in this (resolved) control catalog, there are controls which are mandatory to implement but there are other controls which you may liberally use to achieve your desired security posture".

In other words, it seems there is no OSCAL-defined way (namely, an catalog control element or attribute) to indicate a control is required or optional-but-potentially-appropriate (à la NIST SP 800-53B §2.4) when a catalog is regarded in the context of a (resolved) profile, other than to include the MacGyver prop element (serviceable but not quite the same as a control attribute denoting necessity or shades of satisfaction).

This is somewhat related to the "where are the controls related to my CDEFs in this catalog" in this issue. Perhaps this is best discussed somewhere else?

[aj-stein-nist]

I think "MacGyver prop element" is going to be a new household term in the community, I enjoyed that.

Yes, please open a separate discussion for that so we can discuss that topic with its own focus. Thanks in advance, @GaryGapinski, I appreciate you kept that in mind as you framed the topic of discussion.

[openprivacy]

@iMichaela - proposing OSCAL include scoping:

either the 800-53 profile did not tailor the controls implemented by the component definition OR, the suggested implementations 'magically' matches the tailored control(s)

If the 800-53 profile tailors out a control implemented by a CDef’s component, that control has been tailored out and would not be used by the SSP (unless re-defined and implemented by the SSP’s This-System component).

Since the controls are derived AND have the chance of being tailored in the profile, it most likely they are no longer equal.

Just as with multiple implementations of function/class foo, the (local) inner scope wins

confirm the control he/she is implementing is the agency-profile control for which the suggested implementation is still good even though it was initially written for another 'version' of the same control

In the simplest case, the 800-53 control’s ODPs would be shadowed by the agency-profile’s ODPs.

If (a more complex case) the agency-profile restructures the control description/guidelines, then the agency-profile’s version takes precedence.

BUT my system owner will still be responsible for accepting those implementations.

That should always be the case

[aj-stein-nist]

I hope to update this comment with a more detailed answer, but I also want to work through an example. More on that to follow, but I started a branch this afternoon (very much not yet complete, just getting started) and embedded the CMSGov repo to work through the example to address what is possible, not possible, and what is ambiguous given your question.

https://github.com/aj-stein-nist/oscal-content-forked/tree/1637-reusability-components

More to follow.

[openprivacy]

I may be off base, but enabling scoping seems a powerful tool that will directly support component reusability.

[aj-stein-nist]

Well that is something we can discuss, but I want to frame questions and answers like this in two phases: 1a) what does OSCAL allow/require for this use case today? 1b) Is what is allowed or required for the use case documented clearly? 2a) If there is a need for additions/changes/removals to OSCAL beyond what is currently in a stable released 2b) if so, is there an issue already open for that?

Sounds good.

[iMichaela]

I hope to update this comment with a more detailed answer, but I also want to work through an example. More on that to follow, but I started a branch this afternoon (very much not yet complete, just getting started) and embedded the CMSGov repo to work through the example to address what is possible, not possible, and what is ambiguous given your question.

https://github.com/aj-stein-nist/oscal-content/tree/1637-reusability-components

More to follow.

@aj-stein-nist - the link above is not longer valid and should be updated/removed.

[aj-stein-nist]

Sorry I had to do some gnarly debugging of what happens when you make your own clone of OSCAL versus what is forked for another issue. The updated URL will be above in a second.

https://github.com/aj-stein-nist/oscal-content-forked/tree/1637-reusability-components

That said, I spent more time working through the problem with the team than publishing components yet. There was a lot to cover. There is no content to work through this yet, it should be a version of main from a while back and that is why it shows divergence. It just needs a rebase and it will completely "empty" of changes.