SSP Completeness Checks: 9 Services, Ports, and Protocols

[brian-ruf]

This is a ...

fix - something needs to be different

This relates to ...

• the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP OSCAL Validations

User Story

As a consumer of FedRAMP automated completeness checks I want the following OSCAL-based SSP items to be automatically verified for completeness by metaschema constraints:

• There should always be some PPS
• Need some analysis as to:
  • exact data that should be present
  • Minimum and typical number of entries
  • Alignment with components
    • For example an RDBMS should have at least a SQL port

Goals

SSP Completeness checks are defined, tested and documented

Dependencies

No response

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption (https://github.com/GSA/fedramp-automation) 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.
• all constraints associated with the review task have been converted/created
• automate.fedramp.gov content has been updated accordingly
• the metaschema help prop has an appropriate link to the constraint
• the template has an content that models the desired OSCAL presentation
• the constraint runs against the example template
• known-bad content has been created
• the constraint appropriately flags the known-bad content as invalid

Other information

No response

TASKS

• Add constraint requiring protocol for certain components #962
• Add constraint requiring "used-by" links for components with protocol assemblies #963
• Add constraint to validate component "used-by" link #964

[brian-ruf]

Per @aj-stein-gsa: Check #881 and #882 for alignment with this issue.

[brian-ruf]

[I wrote this comment almost two weeks ago, but just found it unsaved in a browser tab.]
#881 is focused on the presence of //inventory-item.

PPS is addressed strictly using //component. While there is a relationship between the two, the scope of #881 does not impact this issue.

Similarly #882 is specifically about inventory items having an asset-id. This also has no impact to our approach to modeling PPS for FedRAMP SSPs.

[aj-stein-gsa]

PPS is addressed strictly using //component. While there is a relationship between the two, the scope of #881 does not impact this issue.

Similarly #882 is specifically about inventory items having an asset-id. This also has no impact to our approach to modeling PPS for FedRAMP SSPs.

By the time we moved ahead the work was almost done, so I let it go (I realized I had not properly categorized the constraints, but the scope of work was clear and in review before I could recategorize). Apologies. 🤦

So I should have update this issue and had not.

[brian-ruf]

From the SSP:

Complete this table even if leveraging a pre-existing FedRAMP authorization. Add more rows as needed. If you are unclear as to what should be included in this table, refer to: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.
Ensure that the services, ports, and protocols match the data collected in the rest of this SSP.
The developer of the system, system component, or system service is required to identify the functions, ports, protocols, and services intended for organizational use. This list must be kept current. It becomes resource-intensive to retrofit security controls after the system, component, or service has been implemented.
Reference #: Match this number to the reference number (“Ref #”) column in Appendix Q.
Purpose: Provide a general description of how it is used in the CSO, such as for Web access or database connection.
Used By: List the CSO components accessed by this port and the stated purpose.

[brian-ruf]

Analysis

The term "service" as it is used above is similar, but not equivalent to an OSCAL "service" Component.
FedRAMP's use of the term is in reference to IANA-registered communication protocols, and the "service name" in this context is the IANA-registered service name.
An OSCAL "service" component includes this information, yet is much broader and includes information about the actual application.

For example, an IaaS provides a PostgreSQL server database service to a SaaS customer. The SaaS SSP documents the entire database service as an OSCAL "service" component. This OSCAL component lists the PostgreSQL product and version, indicates who administers it, and includes a protocol assembly capturing an IANA registered service name of "postgresql", port number "5432" and both "tcp" and "udp" transport protocols.

The SSP ports, protocols and services table is intended to be a summary of that protocol OSCAL content, along with some additional information about

Summary

Every component that "listens" on one or more ports must have a protocol assembly and one or more "used-by" links that identifies each component that may communicate with this component via that(those) listening port(s).

If this is enforced, the OSCAL ports, protocols and services table becomes a summary of required documentation.

[aj-stein-gsa]

Every component that "listens" on one or more ports must have a protocol assembly and one or more "used-by" links that identifies each component that may communicate with this component via that(those) listening port(s).

If this is enforced, the OSCAL ports, protocols and services table becomes a summary of required documentation.

If we can have components with one direction that is outgoing, does that not mean it is more whatever port is used for ingoing or outgoing communication if not in the ephemeral range? We can have "write-only" outbound services that are not daemonized system services listening on a TCP/UDP/what-have-you-port, correct?

[brian-ruf]

@aj-stein-gsa Sorry - I stepped away from dinner while I was still working here, but I'm not sure I fully follow your question.

The PPS is about the communication happening within the boundary between components or across the boundary. To the best of my understanding of the way IP works, one component has to be "listening" for another component to initiate communication. The initiating component uses a random port to do so, while the "listening" component is on a pre-defined port.

It's the pre-defined ports we are interested in capturing, as well as the protocol and IANA-registered service name associated with those ports.

I think it's also important to clarify that the direction of information flow is separate from the direction of connection initiation.

• Component A initiates a connection with Component B for the purpose of sending information. The ports are on Component B and the direction is "outgoing" relative to Component A.
• Component A again initiates a connection with Component B, but this time for the purpose of retrieving information. The ports are still on Component B, but the direction is now "incoming" relative to Component A.

Regardless, we are interested in the ports on Component B and the protocols associated with those ports. Even if Component A is only writing.

The NIST OSCAL definitions for incoming and outgoing are data focused:

• incoming: Data from the remote system flows into this system.
• outgoing: Data from this system flows to the remote system.

Although this raises a good point that a few of the constrains I defined for Table 7-1 may have inadvertently conflated data flow and connection initiation. I added a comment to #930 suggesting we pause any work involving protocol until we can ensure our use of protocol there aligns with what we are saying here. Can we discuss at the backlog grooming session tomorrow morning?

[aj-stein-gsa]

Can we discuss at the backlog grooming session tomorrow morning?

Sure thing.

It's the pre-defined ports we are interested in capturing, as well as the protocol and IANA-registered service name associated with those ports.

I think it's also important to clarify that the direction of information flow is separate from the direction of connection initiation.

My question is hypothesizing that Component A is part a system in boundary that communicates only with Component B as a form of interconnection to offload application logs in a secure append-only location. Component A can only send log records to B with outgoing communication over HTTPS (TCP 443 for a client to send data to the consuming service, very much like but not exactly the Splunk HTTP Event Collector or HEC; many log provider services operate this way).

So my question given this scenario: do inventory items that compose Component A have to declare HTTPS (TCP 443) even though the listening daemon on HTTPS inventory items that compose Component B? I'll skip the ephemeral port stuff and not complicate it further but this still for A is outgoing only and does not have a service listening so I am curious if and how the protocol declaration for inventory is required.

[brian-ruf]

Constraints Needed

The following component types MUST have a protocol assembly:

• service
• software with the following "asset-type" property values:
  • database
  • web-server
  • dns-server
  • email-server
  • directory-server
  • pbx

The following MAY also have a protocol assembly, but it is not required in all use cases, thus we cannot enforce it:

• system
• interconnection

Further, any component with a protocol assembly MUST have one or more used-by links. Each link must reference an existing component via a URI fragment containing the other component's UUID.

---

Constraints

context="/system-security-plan/system-implementation/component"

• The protocol assembly must exist for certain components: (ERROR)

  • target="//component[ ( @type='service' ) or ( @type='software' and ./prop[@name='asset-type' and @value=('database', 'web-server', 'dns-server', 'email-server', 'directory-server', 'pbx')] ) ]"
  • count(./protocol) >= 1
  • Message: This component is missing port, protocol, and service information.

• In any component where the protocol assembly exists (may be in others beyond where it is required above), there must be one or more "used-by" links. (ERROR)

  • target="//component[./protocol]"
  • count(./link[@rel='used-by']) >= 1
  • Message: This component exposes ports for other components to connect; however, it does not indicate which other components use it. s

• Any component with a "used-by" link must have a URI fragment that represents the UUID of a valid component within the SSP.' (ERROR)

  • target="//component[./protocol]/link[@rel='used-by']"
  • count(//component[@uuid=substring-after(./@href, "#")]) = 1

NOTE: Documentation to be handled in GSA/automate.fedramp.gov#131

[brian-ruf]

@aj-stein-gsa

My question is hypothesizing that Component A is part a system in boundary that communicates only with Component B as a form of interconnection to offload application logs in a secure append-only location. Component A can only send log records to B with outgoing communication over HTTPS (TCP 443 for a client to send data to the consuming service, very much like but not exactly the Splunk HTTP Event Collector or HEC; many log provider services operate this way).

So my question given this scenario: do inventory items that compose Component A have to declare HTTPS (TCP 443) even though the listening daemon on HTTPS inventory items that compose Component B? I'll skip the ephemeral port stuff and not complicate it further but this still for A is outgoing only and does not have a service listening so I am curious if and how the protocol declaration for inventory is required.

This is a great example, and it's considered a Scenario 3 from #808.
Component B would appear in the OSCAL SSP as an external service, which means:

• component of type = "service"
• "implementation-point" property of "external"

Because it listens on 443/SSL, component B would have a protocol assembly.
Because internal system components are sending their logs to component B, it would have a "direction" property with a value of "outgoing"

If Components A, X, Y, and Z all send their logs to Component B, then Component B would have four "used-by" links:

• <link rel='used-by' href='uuid-of-component-A' />
• <link rel='used-by' href='uuid-of-component-X' />
• <link rel='used-by' href='uuid-of-component-Y' />
• <link rel='used-by' href='uuid-of-component-Z' />

There is no content required within Component A's information regarding its communication with Component B.

The many-to-many relationship that can exist when documenting communication pairs among components is only documented on the "listening" side in OSCAL.
You can then use the following query to learn that Component A communicates with Component B:
Query: //component[./link[@rel='used-by' and @href='#uuid-of-component-A']]/title
Result: Title of Component B

[brian-ruf]

@aj-stein-gsa / @Rene2mt this is ready to have tasks issued against it

[vmangat]

A lot of this discourse is assuming all interactions are point to point. In the cloud world when egress and ingress rules are written and they control communication flow between "gates" you don't really establish point to point....that is inherent with the endpoint addressing. The provided-by is of course required because a cloud service is providing the "gating" and operating the ports. The Used-by can be more challenging.
Although its in the table, we need more discourse to make sure requiring "used-by" can actually be satisfied.

[brian-ruf]

@vmangat you raised some good points. Also, after performing analysis for Appendix Q Cryptographic Modules, it seems we have a few challenges.

1. Meet or exceed the information requirements defined in the MS-Word based FedRAMP SSP Template. (The FedRAMP Automation Team has a guiding principle of preferring more granularity in OSCAL where practical.)
2. Consider how this information ties in with Appendix Q as evolving in issue [Feedback]: Not clear how to represent Appendix Q: Cryptographic Modules #606
3. Consider how this information ties in with Table 7-1 as covered in issue SSP Completeness Checks: 7 External Systems and Services Not Having FedRAMP Authorization #808
4. Consider how this information relates to the architecture, network, and dataflow diagrams (The FedRAMP Automation Team continues to consider how FedRAMP OSCAL SSP information requirements can better align with infrastructure as code and diagram generation from code.)
5. Consider the dynamic nature of communication using cloud technologies both inter- and intra-boundary.

Can we schedule some time to better discuss the technologies you have in mind and make sure we fully understand your use case(s)?

In the mean time, I am working on a diagram that will attempt to depict the relationship between:

• Section 9: Services/Ports/Protocols
• Table 7-1: 7 External Systems and Services Not Having FedRAMP Authorization
• Appendix Q: Cryptographic Modules

I'll provide a draft here when ready.

[aj-stein-gsa]

Although it's in the table, we need more discourse to make sure requiring "used-by" can actually be satisfied.

So I better understand you and b
@brian-ruf, can you give more detail about the challenges of used-by so we better understand, @vmangat? We are also more than happy to schedule an office hours as well like Brian proposed.

[vmangat]

@brian-ruf yes we are also looking at correlating software/protocols/networkdiagrams/by-component-statements so that the information provided in the SSP correlates well. Yes this is going beyond the word templates as those tables are not really designed for real correlation.
@brian-ruf in your narrative, you have also eluded to a notion of a software and a cloud service being have to be modeled differently as a "software" component or a "service" component which is departing from prior guidance. This will require very strong guidance as to what scenarios qualify as "software" and what scenarios qualify as "service".

@aj-stein-gsa we will request office hours to have a further discussion, we may reserve 2 consequent 30 min sessions to make sure we have enough time.

[brian-ruf]

@vmangat Thank you for calling out that there is some ambiguity between "software" and "service" components. I think that is a fair observations. While I have some thoughts on that topic, which may be better hashed out in those office hours.

For now I'll just offer the way I have been personally thinking about the difference between these two.
This is not guidance. Just a sharing of thoughts.

I believe there is overlap between the two, and it may be best to simply allow them to be largely interchangeable.
In the example I've been working on, I've considered a database component, and found myself thinking "software" vs "service" is somewhat a matter of perspective or perhaps scope-of-control.

From the perspective of my own system:

• If I am installing an RDBMS implementation on an asset I control, it is "software".
  • Example 1: I installed PostgreSQL on a virtual Ubuntu 22.04 server. I control both. This is "software"
  • Example 2: I spun up a PostgreSQL container in my K2 cluster. This is "software".
• If I am instantiating an RDBMS capability for myself, but don't have full control, it's a "service".
  • Example 3: I am using an AWS RDS instance that I configured and is dedicated to my workload, but I have no insight/control into the underlying platform. This is a "service"

Similarly, if I expose Example 1 above (PostgreSQL on Ubuntu) to downstream customers that don't have insight/control into how I am deploying/managing that PostgreSQL instance, it may be a "software" component for me, but it is a "service" component for them.

Again, it may be that these nuances are too subtle and it is best to just treat the two as interchangeable.
I'd welcome thoughts here and/or in office hours.