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