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 usnistgov/oscal-cli#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 #1913 (comment):

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.

[brian-ruf]

I am encountering similar challenges with the "direction" property in components.
I think it is fair to say that every component that requires the protocol field also requires the "direction" property.
I am unable to find an issue discussing the "direction" property in this way.

@aj-stein-gsa / @iMichaela / @Telos-sa - Thoughts?

[aj-stein-gsa]

I am encountering similar challenges with the "direction" property in components. I think it is fair to say that every component that requires the protocol field also requires the "direction" property. I am unable to find an issue discussing the "direction" property in this way.

So can we clarify the issue with the constraint in question, is it one or more of the following?

1. I don't want the constraint of all?
2. I want the constraint, but not only for component[@type="interconnection"]?
3. I want the constraint, but the enum values for the prop[@name="direction"]?
4. A combination of 2 and 3.
5. Something else.

I just want to be clear because I definitely mislabeled my PR to be "mostly about 1913 and somewhat about 1922," when it was the inverse (it is actually "is mostly about 1922, and somewhat related to 1913"). For that I apologize, so I wanted to make sure I completely understood the the issue with direction.

[brian-ruf]

2. I want the constraint, but not only for component[@type="interconnection"]?

The second one!
The enums are correct.

The fundamental issue is to identify all component types that need to capture details about communication that crosses the boundary. I believe that means "interconnection", "service", and "software". Possibly also "validation" (I agree with @iMichaela's assertion that "validation" is a different conversation, but want to leave room for the possibility that "validation" has not yet been settled.)

The documentation requirements for any communication that crosses the boundary include:

• local/source and/or remote/destination address(es), which could be an ipv4 address, ipv6 address or URI.
• local/source and/or remote/destination port(s) and associated transport (TCP/UDP)
• direction of communication
• Other items that area already well addressed and don't need to be re-hashed here, such as information exchanged, authorized users, owning organizations and POCs.

I believe we need to:

• expand the existing "interconnection" constraint on properties to include one additional allowed value:
  • <enum value="uri">A Uniform Resource Identifier (URI) for the component.</enum>
• remove the existing "interconnection" constraint on protocol as your PR is already doing.
• add a new constraint for "service" and "software" that allows "ipv4-address", "ipv6-address", "direction", "uri" as follows:

                  <allowed-values target="(.)[@type=('service', 'software')]/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name">
                        <enum value="ipv4-address">An Internet Protocol Version 4 interconnection address</enum>
                        <enum value="ipv6-address">An Internet Protocol Version 6 interconnection address</enum>
                        <enum value="direction">An Internet Protocol Version 6 interconnection address</enum>
                        <enum value="uri">A Uniform Resource Identifier (URI) for the component.</enum>
                  </allowed-values>

NOTE "service" and "software" are not lumped into the "interconnection" constraint because "interconnection" has additional allowed values that do not pertain to the other two.

[aj-stein-gsa]

2. I want the constraint, but not only for component[@type="interconnection"]?

The second one! The enums are correct.

Cool. Are we saying we want that change or need it in the short-term? I did not necessarily include this in the scope of my proposal #2072 and did not know if it is blocking downstream constraint work. Are we saying the issue is significant and we want to amend that proposal?

[iMichaela]

An Internet Protocol Version 6 interconnection address

I believe there is an error in the description for 'direction" in the enumeration above. And the value fro the "direction" should be constrained to ingress , egress is it is not already. And IF it si bidirectional, do we specify it as a third allowed value or do not constrain the cardinality and assume the absence of the direction to imply a bidirectional traffic?

[brian-ruf]

@iMichaela currently, "direction" as a property name is only in the allowed values list for component type "interconnection". I am suggesting that it belongs anyplace protocol belongs, and that in this case both belong in "service", "software", and "interconnection".

As for the allowed values for the "direction" property, they are currently configured in metaschema as "incoming" and "outgoing" with the intention of having it twice when bi-directional. It has been this way since before 1.0.0.

   <allowed-values target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='direction']/@value">
         <enum value="incoming">Data from the remote system flows into this system.</enum>
         <enum value="outgoing">Data from this system flows to the remote system.</enum>
   </allowed-values>

While I don't personally care if they are incoming/outgoing or ingress/egress/bidirectional, I'm reluctant to make this change as it's currently working in its current sate. So it would be a breaking change for something that is not a bug fix.

[Telos-sa]

I think we are option 5.

I am comfortable with the current syntax and structure, I think the challenge is determining the different user stories to be able to showcase the relationships.

IE if we are treating service as a component and it is services and a collection of protocols (like ports protocols and services), that need to be referenced and used by other services, interconnections, and components. The question is really how complex should these relationships be? Would love to see if we can brainstorm how to deomonstrate PPSM in an OSCAL way, and do it better than the manually generated documentation.

[brian-ruf]

@Telos-sa I've been re-modeling Table 6.1 (Leveraged Authorizations) and 7.1 (External Systems and Services Not Having FedRAMP Authorization) from the Rev 5 FedRAMP SSP template here:

• SSP Completeness Checks: 6 Leveraged FedRAMP-Authorized Services GSA/fedramp-automation#807
• SSP Completeness Checks: 7 External Systems and Services Not Having FedRAMP Authorization GSA/fedramp-automation#808

I've decomposed the template instructions to use cases and fully re-modeled LAs. I'm still working on the remodeling of 7.1, but have a fair amount of analysis and thoughts in those two issues and their related task issues.

In particular, I think you are touching on this THIS COMMENT where I attempted to lay out the five scenarios that need to be clearly modeled and documented from an OSCAL perspective. Please let me know if these scenarios align with your thoughts on user stories.

[iMichaela]

@iMichaela currently, "direction" as a property name is only in the allowed values list for component type "interconnection". I am suggesting that it belongs anyplace protocol belongs, and that in this case both belong in "service", "software", and "interconnection".

As for the allowed values for the "direction" property, they are currently configured in metaschema as "incoming" and "outgoing" with the intention of having it twice when bi-directional. It has been this way since before 1.0.0.

   <allowed-values target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='direction']/@value">
         <enum value="incoming">Data from the remote system flows into this system.</enum>
         <enum value="outgoing">Data from this system flows to the remote system.</enum>
   </allowed-values>

While I don't personally care if they are incoming/outgoing or ingress/egress/bidirectional, I'm reluctant to make this change as it's currently working in its current sate. So it would be a breaking change for something that is not a bug fix.

I agree with you it should be supported in other models too, but addressing this issue is beyond the scope of a patch. Alos, there is no need to change the allowed values and using 2 props for bi-directional through composition is OK.

[iMichaela]

Per @aj-stein-gsa's note in the PR #2063, this initial issue should have addressed by that PR. Are we saying it si not because there are additional findings, or because the PR is not addressing it as expected?
If the lates conversation raised by @brian-ruf reflects additional requirements, I suggest moving the dialog to a new issue so we can close this one since the PR #2063 has been merged. Same suggestion for the FIPS 140-related comments - an issue that appear to have lost interest.

[aj-stein-gsa]

2. I want the constraint, but not only for component[@type="interconnection"]?

The second one! The enums are correct.

NOTE "service" and "software" are not lumped into the "interconnection" constraint because "interconnection" has additional allowed values that do not pertain to the other two.

@brian-ruf, so we are saying service and software, but not .[@type="system"] even though tracking connectivity through leveraged authorization is valuable at times? I will draft a PR and confirming with you, but we can also take this to a PR review.

[aj-stein-gsa]

For review by interested parties, I opened #2077.