Expansion of Protocol Tag to other components

[Telos-sa]

User Story:

As a project {stakeholder}, I need to be able to understand how information is flowing throughout the accreditation boundary and how these ports and protocols are being leveraged.

Communication via API

• Would this be a new type of component, or should it be leveraged as an interconnection?
• What if the API is not leaving the boundary, how to describe within-boundary (but not local) connections?
• Should it be references as a service, or define the software that is using the API, then link to service.

Software that leverage services:

• Confirm logical tie to inventory: Should the service point to the software, and the software be an implemented component?
• Does it matter if the software is just running locally?
• What if the service is not just running locally?
• Are there any other components that should be included in the list of "provided-by" and/or "used-by"?

Communication between two inventory items (Web server and DB):

• Should this be considered an interconnection or a service?
• If a service, do I need to identify the service on both edges of the connection?
• how should we evaluate the security of these connections?

Are cryptographic modules considered a component?

• Should they be included in the "provided-by" and/or "used-by"?
• Should there be a new tag for the encryption deployed by the service?
• Is this only required in specific circumstances (local, external interconnection, internal connection).

Goals:

Expand the use case of Components and protocols to meet the edge use cases of many interconnections, or support guidance for how to define edge.

Dependencies:

Link https://github.com/usnistgov/oscal-cli/issues/186

Acceptance Criteria

• [ ] All website and readme documentation affected by the changes in this issue have been updated.
• [ ] 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.

[aj-stein-nist]

@Telos-sa, you have expressed two requests:

1. Examples of how to use protocols with the current supported syntax. You say this explicitly and a lot of questions revolve around that.
2. You imply you have use cases for the use of protocol in a component that is not of type="service" and alternative ones, the most obvious being those with type="software". Others may be less clear but implied did I understand that correctly?

I had asked the FedRAMP Automation Team if there was a historical or outstanding current reason protocol is only for type="service" components in their documentation and guidance, and they did not have one on record.

Re 2, is there any other type of component you are asking about to support protocol without error or warning? Can you give examples of a software component? If you recommend others, can you provide examples of those?

[Arminta-Jenkins-NIST]

During the 9/21 Triage Meeting, we decided to mark this ticket as More Analysis Needed for another week as we await feedback from FedRAMP.

[aj-stein-nist]

@Arminta-Jenkins-NIST I meant feedback from @Telos-sa, not FedRAMP, sorry I didn't catch this sooner. Regarding FR PMO and Automation Team feedback from my previous comment https://github.com/usnistgov/OSCAL/issues/1913#issuecomment-1729933677:

I had asked the FedRAMP Automation Team if there was a historical or outstanding current reason protocol is only for type="service" components in their documentation and guidance, and they did not have one on record.

[Telos-sa]

Thanks AJ. One of the new ones that may leverage the protocol tag for FedRAMP is their "Validations" for encryption. Since there are some, openSSL for instance, that should have their specific port or ports identified to support their use case. IE, how they are going to use the validation.

Another use case, and the one that kicked this off, would be "Interconnection". If data is flowing via an interconnection, should it identify the specific port and protocol.

If the overall goal is to leverage the service component as the owner of "protocol" then we may need some additional guidance on how to leverage the used by and provided by links, to demonstrate how the service is being leveraged by the interconnection. How the service is using the validation and/or software to support the connection.

It may be that we leverage the "depends-on" and "uses-service" tags to support the components. In that case, would the depends on be owned by the service component as well, to identify the different validations/software that is required to make the service work? Then would the "uses-service" need to be used by the interconnection to show the upstream dependencies?

If this is the case, and may be the best use case to support edge cases, then is the demonstration of the relationship owned solely by the down stream dependencies?

[aj-stein-nist]

Thanks AJ. One of the new ones that may leverage the protocol tag for FedRAMP is their "Validations" for encryption. Since there are some, openSSL for instance, that should have their specific port or ports identified to support their use case. IE, how they are going to use the validation.

For a type="validation" component, I am not sure that is how it has been designed or intended for use in OSCAL. FedRAMP is following the guidance from core OSCAL as we provide, and I believe FIPS 140 test validation is the example.

https://pages.nist.gov/OSCAL/learn/tutorials/implementation/validation-modeling/

1. You have a this component, let's say Component 1, explaining the FIPS-140 conformance with a CMVP certification in a component.
2. This component, Component 2, references that component and includes the system/service information that uses TLS termination for HTTPS for an Apache web server and a properly configured Linux server running the compiled OpenSSL linked to the CMVP certification in Component 1. This is where protocol and port information would go about network, not in Component 1 (because OpenSSL's CMVP information is about algorithm implementations, it doesn't know about HTTPS and TCP network information).

Does this make sense? Given our current documentation, I am not sure adding protocol here is sensible. Can you give an example as to why beyond what was said before?

Another use case, and the one that kicked this off, would be "Interconnection". If data is flowing via an interconnection, should it identify the specific port and protocol.

If the overall goal is to leverage the service component as the owner of "protocol" then we may need some additional guidance on how to leverage the used by and provided by links, to demonstrate how the service is being leveraged by the interconnection. How the service is using the validation and/or software to support the connection.

It may be that we leverage the "depends-on" and "uses-service" tags to support the components. In that case, would the depends on be owned by the service component as well, to identify the different validations/software that is required to make the service work? Then would the "uses-service" need to be used by the interconnection to show the upstream dependencies?

If this is the case, and may be the best use case to support edge cases, then is the demonstration of the relationship owned solely by the down stream dependencies?

This recommendation around type="interconnection" seems more plausible, can we work through a minimal example and what stops you from doing this today with the current models?

[iMichaela]

@aj-stein-nist and @Telos-sa -- All comments above are addressing more than what the issue is calling for: "how information is flowing throughout the accreditation boundary and how these ports and protocols are being leveraged.". The FIPS 140 validation certificate is addressed in #1922. Continuing discussion the validation component type and the FIPS 140 validation certificate as component in two places is counter productive and risks providing inconsistent conclusions/outcomes.