component-definition needs implementation-status

[degenaro]

User Story:

As an OSCAL component-definition author, I need to be able to specify the implementation-status of my component.

Goals:

The system-security-plan.control-implementations.implemented-requirements comprises by-components.implemenation-status. The best place to author the component implementation-status is in the component-definition by the component owner.

For a cloud provider, services SSP component rules and (with this change) implementation-status are inherited from the provider declaration in the component-definition.

Dependencies:

N/A

Acceptance Criteria

• [x] 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.
• [x] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• [x] 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.

[iMichaela]

@degenaro -as earlier discussed, OSCAL component definitions are not meant to describe implemented components, but rather suggest to or guide system owners that are using respective components for their systems how to securely configure them and the controls associated. The component in an OSCAL SSP will be the implemented component.

[degenaro]

Description of implementation status from OSCAL doc: Indicates the degree to which the a given control is implemented. (seems like some grammar fix-up could be enjoyed here).

The component owner, being the author of the component definition, is in the best position to provide this information and should be given the opportunity to do so.

[gregelin]

I think @degenaro makes an important point.

If a component represents a common control providing service, such as an enterprise authentication service (aka "SSO"), then it is very helpful to know within the SSO's OSCAL component model what controls were implemented for the SSO (and any control implementation status). Is the SSO component implemented at the organization or not?

Some may argue that because the SSO is a service and has its own SSP, then the SSO cannot be a component; and is simply used via an interconnection and a leverage SSP. That also makes sense...and then raises the question if there is a rule about what can be defined as a component?

It seems there should be a rule. Either the SSO is a component and therefore the status should be represented in the component model; or the SSO is not a component but an interconnected system and has a System SSP to be leveraged and no component model. If the choice of what is a component is left the organization, then some organizations will say the SSO is a component and we're back to it being useful to have status information in the SSO OSCAL component model.

In can also be the case that a component is implemented at the organization level (e.g., the SSO works and has controls), but the control is not yet implemented for a particular system SSP because particular system is still in the process of integrating the SSO.

[iMichaela]

The way I think this should work is: 1) the system providing SSO gets ATOed 2) the AI controls that can be implemented by this system are explained in a CDef, explaining all possible options and how to configure them 3) an organization implements the desired one(s) and includes the control(s) in the Common controls SSP identifying the inheritance and the customer's responsibility (see leveraged authorization for how to) 4) the Common controls SSP is used to ATO all common controls that get inherited we used

[degenaro]

Thanks for your comments Greg & Michaela. If you look at Figure 1 and Table 1 here https://www.ibm.com/cloud/blog/compass-compliance-part-1 it is evident that the control provider, who authors the component-definition, is the one best able to "indicate the degree to which a given control is implemented".

[david-waltermire]

As @iMichaela indicates, a component in a component-definition represents something which COULD be implemented within any information system. It isn't actually implemented until it appears in a system-security-plan.

Both /system-security-plan/control-implementation/implemented-requirement/statement/by-component/implementation-status and /system-security-plan/control-implementation/implemented-requirement/by-component/implementation-status convey the degree to which the control or control statement identified by /system-security-plan/control-implementation/implemented-requirement is implemented. The second provides a fine-grained status for each component, while the former identifies the status for the whole control.

If we were to add an implementation-status to a component in a component-definition, what would this status indicate? It cannot indicate anything about the actual implementation status in an information system, since a component in a component-definition is not an actual implementation. At best, this status might indicate if the control is supported by the component or not. If the control or control statement is not fully implemented, why include it in the component in the first place?

To add to this, just because a product supports a control, there is no gaurantee that the information system is relying on this feature or even has that feature configured to provided the control support. This is why the information system NEEDS to declare this information.

Given the above, I don't see a strong argument for why implementation-status needs to be added to a component in a component-definition.

@gregelin "a common control providing service, such as an enterprise authentication service (aka "SSO")" needs to be documented (option 1) using an OSCAL system-security-plan if its implementation is to be inherited through the OSCAL leveraged-authorization declaration. If this service is defined as a component in a component-definition (option 2), then it would need to be instantiated as a component in the information system to declare the implementation. These are the two options provided by OSCAL. In "the case that a component is implemented at the organization level (e.g., the SSO works and has controls), but the control is not yet implemented for a particular system SSP", the SSP can declare the degree to which the component is implemented using the by-component/implementation-status for either option.

@degenaro The "control provider, who authors the component-definition" does know what is implemented in their software/service, so they should document the control implementation in the related component in a component-definition. They CANNOT state anything on behalf of the system owner about how or if that control is implemented in an information system using that component. An example of this is how FedRAMP provisionally authorizes a cloud service, but they cannot accept risk on behalf on the agency implementing an information system based on the cloud service. ONLY the agency authorization official can do this.

[david-waltermire]

@degenaro The NIST team would be glad to work with you on a concrete example of how all of this works to test in your tooling. We are here to help.

[iMichaela]

@gregelin and @degenaro - To highlight the points @david-waltermire-nist is making, let's use one concrete example: Microsoft Azure offers Active Directory as a service. The service has been ATO at IL5 (one level above FISMA high), meaning it is very well secured. HOWEVER, this service implements password-based authentication which does not meet the necessary AAL3 (authentication assurance level 3) necessary for IL5 systems. As of today, should an agency decide to use this service, they will not be able to change the default configuration for the password to meet the agency's password's length requirement and the complexity due to a bug, even for AAL2, not to mention the AAL3. Compensatory controls would be necessary (as a separate auth factor). So, the overall SSO component will have to be decided by the system owner (which could be the system owner of the organizational common controls or any other system) and only the system owner is able to mark the control as fully implemented when both factors are in place (in the scenario I provided). The inability to change the configuration for the instance ATOed at IL5 is a bug I hope MS is working on fixing. It has been reported, but it still proves the point Dave and I are trying to make and it justifies why the organization is the one that would determine how to implement the SSO as a common control, ATO it and allow other system owners to inherit the control for their systems, or just as a simple component providing ICAM for a regular system.

[degenaro]

Still not following, sorry. The very first sentence here says The OSCAL component definition model represents a description of the controls that are supported in a given implementation of a hardware, software, service, policy, process, procedure, or compliance artifact. Again, the component owner knows best what is implemented. @iMichaela if I understand correctly, in your example the component is the Active Directory Service whose owner knows that the implementation status is IL5. Why should not the owner be able to specify in the component definition that the implementation status is exactly that? If the implementation status is not IL5 then component owner has made a mistake in making that claim. The system owner can accept the claim or not.

[ancatri]

@iMichaela @david-waltermire-nist Thank you for your explanations which make perfect sense for the use cases you mention. Our cloud use case is. slightly different in the sense that the system owner subscribes to a service with controls already implemented. Before subscription there is no system , so no SSP. As the control implementer is the service provider, we need to allow them to declare the implementation-status to guide the customer system owner. We have the choice to use props to declare the implementation-status in the control provider object which is the Comp Def, OR, we asked here if we. can have the implementation-status as OPTIONAL , not required by the oscal schema. We will use props. for now. Thanks!

[gregelin]

@iMichaela @david-waltermire-nist @degenaro - This is a terrific thread. The specificity in each comment is very useful and I personally find it very helpful. Thank you.

@iMichaela @david-waltermire-nist both state that the SSO service would have its own ATO, therefore its own SSP, and that seems to suggest the proper way to include the SSO in the target system's SSP is via a leveraged authorization. I recommend NIST defines that as a formal rule and part of the standard. (If that is already the rule and intention of the standard, my bad for missing it and how can I help spread the word?)

@degenaro, your referenced Figure 1 diagram is terrific. Did IBM create it? You should add a credit line to it and let everyone use the documentation.) I also agree very much with your quoted text on the OSCAL component definition model. It's very easy to read that and think the control implementation status is defined within the component definition model.

I want to build to the rules:

1. Existing services(systems) with ATOs are included in a target system's SSP by leveraged authorization because the existing systems have approved operational accountability risk management boundaries. (The implementation of the controls for the existing services is somebody else's responsibility. The target system transfers the risk related to those controls to the leveraged system.)
2. Software, hardware is included in a target system's SSP as a Component when the target system is responsible/accountable for the installation, configuration, and operational maintenance of the identifiable item. (Example: Agency uses OKTA for SSO, but my target system has installed and is operating its own OKTA instance because we are on network segregated from the enterprise OKTA instance.)
3. The Component model and the control implementation statements therein are recommendations and/or draft content for target systems that are installing and operating the Component. Only the target system knows if a control is implemented and the idea of implementation status has no meaning outside of the context of a target system ATO accountability boundary.
4. The Component owner knows best what the recommended controls are and how the controls are to be implemented (and even tested) for standard/supported configured operational instances of the component.
5. The targeted System dev/op teams knows best how the Component is effectively configured operationally and whether the control is implemented or tailored.
6. TO BE DISCUSSED is whether a Component model ONLY contains control implementation statements that refer to features that are planned for the component or must a Component model only contain "valid" CI statements where "valid" is defined that the target system can implement that control today with a proper configuration. (This is David's question.)

The above rules leaves a couple of question...

• Is an agency's IT Policy document a Service or a Component? The Policy document has an accountability bound but I don't think Policies have ATOs or approved SSPs to leverage. Or is the Policy still essentially a Component that the Target system is implementing? (As in, "Yep, we are following that Policy.")

• An agency operates a Docker registry that provides hardened "gold-images" of root docker containers (e.g., Alpine, Ubuntu, Windows, etc.). A target system builds its system using the gold-image containers. There is a however, a known issue with a library in the agency-provided container for RHEL 8 that shows up on scans and gets flagged as a finding (and a POA&M) in the targeted system. It would seem that the Docker registry would be part of an existing agency system with an ATO. But is the Docker and/or the RHEL 8 image a Component that target system implements or a Service? Who is responsible for the POA&M? It would seem to me that it is up to the organization to decide whose is responsible for the POA&M: either agency decides Docker registry service team is responsible and agency accepts the risk on down stream systems; or agency decides (some) target system may be responsible for creating compensating control (either fix, or add something) and risk acceptance is evaluated at target system.

I think Michaela's steps is very clear and helpful and the concrete details of the Azure example is very helpful. I think these types of thoughts belong in a document called, "OSCAL by Examples." I also like David's path description of the content. I don't why I didn't notice it before. It's a very helpful convention.

[gregelin]

Having an example that describes @ancatri scenario would be very useful. I think it is a common scenario in cloud environment that has orchestration for deploying the target system, or from another perspective delivering specific functionality in the form of (A) partially or wholly pre-configure components into a target systems effective operational deployment or (B) separately managed services that the targeted system registers with upon operational deployment.

[iMichaela]

@iMichaela @david-waltermire-nist both state that the SSO service would have its own ATO, therefore its own SSP, and that seems to suggest the proper way to include the SSO in the target system's SSP is via a leveraged authorization. I recommend NIST defines that as a formal rule and part of the standard. (If that is already the rule and intention of the standard, my bad for missing it and how can I help spread the word?)

@gregelin - NIST (RMF team) is not prescriptive beyond the guidance in 800-37 rev2 regarding Athorizations to Use (previously known in 800-37 as leveraged authorization). OSCAL is designed to be flexible and useful in many scenarios. In the example I used, the SSP of the Azure Active Directory (AD) is not providing controls that are inherited since its own IA & AC controls are securing the system which delivers SSO as a service to other systems. The way I see it (based on conversations with DoS and OISM), the SSO will be an organizational common control provided by a separately ATOed system. In our case, all common controls are grouped in a separate SSP (with a distinct system owner responsible for them) and from THIS SSP, the SSO service is used to implement the IA and AC controls for other systems (with different system owners), when applicable. As ave described above, the SSO service, even though fully implemented and ATOed, does not provide identity and access control to any other system until that system implements it (directs the requests to SSO and receives the response which is then processed). To provide the SSO details/ability/configuration, a CDef created by Microsoft (see option 2) in Dave's description above, could be used to describe the controls the SSO is able to support. I personally make a distinction between controls provided by an external (interconnected) system and inherited controls. If the access control to my deployed platform (PaaS) is managed by the IaaS used, as it was the case with the ORION JK21 we worked on, then the AC is inherited from the CSP which manages the accounts, and the IaaS' ATO is leveraged. We, the owners of the SaaS (aka SDP), could not chose to use or not to use the provided access control mechanism, while with an SSO service (also implemented), you chose to use it (aka integrate their service).

[openprivacy]

If we were to add an implementation-status to a component in a component-definition, what would this status indicate?

We are finding it useful for component authors to indicate (in the CDEF)

• component-class (e.g., reusable_component, example_template, system_specific) in components/props and
• control-type (e.g., inherited, hybrid, allocated) in components/control-implementations/implemented-requirements/props.

External to the component will be agency maintained metadata that provides records containing a pointer to the component along with its vetted status (by who, when, trust "score") and usage statistics. This could influence the implementation-status and other "default" attributes when assembling an SSP, perhaps initially marking well-vetted controls as inherited or even satisfied in a leveraging system.

[iMichaela]

Thanks for your comments Greg & Michaela. If you look at Figure 1 and Table 1 here https://www.ibm.com/cloud/blog/compass-compliance-part-1 it is evident that the control provider, who authors the component-definition, is the one best able to "indicate the degree to which a given control is implemented".

@degenaro and @ancatri - Neither @david-waltermire-nist nor I disagree with you over the fact that the provider of an implemented solution/service knows best a "service with controls already implemented". We only point out that the OSCAL SSP should then be used and not the OSCAL CDef. This is why CSPs are submitting SSPs to FedRAMP to be used for the P-ATOs and not CDefs. CRMs are also important to convey customer responsibilities. Please note that these comments are here to explain the vision and to promote best practices, but, at the end of the day, you and your team can use whatever pleases you as long as the interoperability and data portability are not of concern.

[iMichaela]

@iMichaela if I understand correctly, in your example the component is the Active Directory Service whose owner knows that the implementation status is IL5. Why should not the owner be able to specify in the component definition that the implementation status is exactly that? If the implementation status is not IL5 then the component owner has made a mistake in making that claim. The system owner can accept the claim or not.

@degenaro - The Azure Active Directory (the instance I mentioned !! not all of them) was assessed and authorized at IL5 which demonstrates how secure the implemented system (!) is. This ATO at IL5 includes the IA and AC controls of the Active Directory as. a. system, controls used by the admins to maintain the service (the CSP's employees). The service provided to others though is a password-based authentication IDaaS. and not an MFA, and because of the bug I mentioned, the password length and complexity cannot be changed (or could not be changed 2 months ago) as described in the documentation due to the hardening of the system and the default configuration allows only for passwords with 8 characters and reduced complexity. The CDef of the Active Directory as a component of another system, will not describe an IL5 capability, nor will it include the Active Directory's own controls. Whoever users of the Active Directory- the ones that want to use it to control access to their systems, will have to use the dashboard to configure the service (aka finish implementing the component and associated controls for their system) and decide, in the process, the password length and complexity (when the bug I mentioned will be fixed). So, to summarize, 1) Azure Active Directory gets implemented by the CSP, the SSP is used to ATO the system, then 2) the authentication and access control service (IDaaS) is offered to other systems, and gets described in the CDef, and 3) is implemented as a component onto any system that uses this password-based authentication. This last system that will have an Active Directory component implementing identity and authentication controls will have its own SSP and will be ATOed separately and independently from Active directory ATO. When you make the

I hope this helps...

[openprivacy]

If the control or control statement is not fully implemented, why include it in the component in the first place?

Given access to a library of reusable components, it seems reasonable that component controls could make the claim that they fully implement the control (and thus may be considered "Fully Inherited") or they may only partially implement the control ("Hybrid"). In either case, the ISSO managing the SSP must decide if they will consider the controls as fully inherited or not, but such hints will be useful.

[iMichaela]

@openprivacy - we have in our oscal-content repo a component definition example which describs MongoDB's TLS which would implement SC-8(1) BUT it requires the customer to configure it in order to enable it. The component definition describes the control implementation, but until MongoDB becomes part of a system and the system owner accepts to configure the TLS 1.x & documents it, the control is not implemented. There is a risk when marking such control 'implemented', that a system owner might misinterpret it as fully done and not configure.

[openprivacy]

@iMichaela Thank you for the pointer. Two related questions:

1. If an Agency provides MongoDB-as-a-Service, they may also be in a position to provide a vetted technology-based component that includes sc-8(1) as "fully inheritable" - does this seem reasonable?
2. Could assurance of implementation (e.g. configuration /etc/mongod.conf) be handled by an associated Assessment?

[iMichaela]

If we were to add an implementation-status to a component in a component-definition, what would this status indicate?

We are finding it useful for component authors to indicate (in the CDEF)

• component-class (e.g., reusable_component, example_template, system_specific) in components/props and
• control-type (e.g., inherited, hybrid, allocated) in components/control-implementations/implemented-requirements/props.

External to the component will be agency maintained metadata that provides records containing a pointer to the component along with its vetted status (by who, when, trust "score") and usage statistics. This could influence the implementation-status and other "default" attributes when assembling an SSP, perhaps initially marking well-vetted controls as inherited or even satisfied in a leveraging system.

These are all good points, @openprivacy but I sense that the implementation-status you are envisioning is more of a product quality scoring than an implementation. I am trying to understand @ancatri and @degenaro cloud services case. Which service would a CSP provide if not already implemented? It might come with some customer responsibility. That I understand. And we've discussed at length and @Compton-NIST was looking into it while working on the CRM. Because the service provided by IBM is most likely implemented, and can be described in a component definition, which becomes a component of the customer's system and needs to be documented in the SSP. At this point, the customer's responsibility should be identified and fulfilled. We also discussed that a component definition should be allowed to indicate, when applicable, what can be exported by the system the component becomes part of, and leveraged by other systems.

[Arminta-Jenkins-NIST]

At the 11/2 Triage Meeting: This is currently being partially worked as part of DEFINE: Spiral 4

[iMichaela]

Following the research done as part of the DEFINE spiral 4, the issue will be (experimentally) addressed in the release candidate OSCAL 1.3.0 by allowing the declaration of the implementation-status for cases like cloud services and to support devops. The documentation will explain its specific usage.