Requesting new Component type for connections that are internal to system boundary

[Telos-sa]

User Story

There is currently a type for interconnection, defined as "A connection to something outside this system." There is also a service, which is defined as "A service that may provide APIs."

The FedRAMP OSCAL Rev 5 has added new requirement for a "validation" component to identify the approved encryption module, with additional locally defined props that denote the if it is protecting data in transit, and/or data at rest.

Would like to understand how the service component can be leveraged, and or if we need a new internal connection component, to identify the following use cases:

1. Server is communicating with the internal database.
   Is this considered a service? Or do we tie the cryptographic module to the software components on either side of the communication? What is the recommended methodology for identifying how information moves around within an accreditation boundary?

Relates to #1913

Goals

Determine the appropriate way to identify and document internal movement of data within the boundary, either locally on a single machine or to different machines and how to further link the cryptographic module components. IE should cryptography be referenced at the software level, or at the service level?

Dependencies

No response

Acceptance Criteria

• 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.
• 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.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

[Arminta-Jenkins-NIST]

At 9/21 Triage Meeting: Needs Further Analysis: Only use the component types we allow?

• @iMichaela agreed to look into it

[GaryGapinski]

The related Schematron may be of interest.

[Arminta-Jenkins-NIST]

At 9/28 Triage Meeting: @iMichaela and @Arminta-Jenkins-NIST didn't have time to look at this ticket during the sprint. We will circle back next Triage.

[Arminta-Jenkins-NIST]

At 10/5 Triage meeting: No movement made. @aj-stein-nist can help on Tuesday (10/10/23)

[aj-stein-nist]

At 10/5 Triage meeting: No movement made. @aj-stein-nist can help on Tuesday (10/10/23)

I am going to review the Metaschema constraints and summarize for analysis and pose some key takeaways and recommendations for the team and the @Telos-sa that reported the issue by Tuesday, so maybe before. 😎

[iMichaela]

10/05/2023 analysis

OSCAL allows local definitions for the components' type so, if a 'connection' component is necessary, that can be locally defined.

With that said, the question is deeper than the component type.
In this scenario, the system has the following important components of interest:

• a web server,
• a DB,
• a crypto module - that can be hardware or software:
  - has been FIPS 140 validated and has a validation certificate which lists the allowed and approved crypto algorithms
  - provides encryption in transit between Web server and DB, inside the authorization boundaries

FedRAMP is asserting (see Schematron), that under system-implementation, there is a FIPS 140 validated module by determining if the system has a component of type='validation', and that each citation has a validation reference and validation details such as CMVP certificate number using prop, and details through a link

To me, it makes sense that the the SSP will have the following components (locally defined or allowed values):

 <component uuid=" " type="web-server">
           <title> </title>
           <description>  </description>
          <status>  </status>
</component>
 <component uuid=" " type=" database">
           <title> </title>
           <description>  </description>
          <status>  </status>
</component>
 <component uuid=" " type="software">
           <title> Software Crypto Module</title>
           <description>  a validated crypto modules used to encrypt data in transit</description>
          <status>  </status>
</component>
 <component uuid=" " type="connection">
           <title> Data in transit encryption</title>
           <description> Encrypted communication between web server and DB </description>
           <prop name=> </prop>
           <link href=" " rel='validation-details">
           <protocol uuid= "" name="data-flow-1">  ... </protocol>
           <status state=" "> ...  </status>
</component>
 <component uuid=" " type=" validation">
           <title> CMVP-issued certificate</title>
           <description> The FIPS 140 validation certificate issued by CMVP </description>
           <status>  </status>
</component>

NOTE: more details can be captured above to demonstrate how to meet the FedRAMP's Schematron rules. This can be done once we agree this is one valid way of documenting the scenario.

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

[Telos-sa]

Found an instance in the FedRAMP RAR that violates this specific use case where they consider and API an interconnection, and not a service. With this requirement, the port and protocol is requested in their table, however this will violate the OSCAL schema requirement of protocol only for service.

First Image shows section 3.3, where NOTE, indicates API is a connection:

Second image is the table for API's, and the instruction text defining the data in transit assumption, which would include source and destination, as well as the protocol leveraged. Protocol is service.... Should we add tags to include local and remote IP to service and/or include protocol in interconnection. Or reference the service component of the API, to the interconnection.

[iMichaela]

@Telos-sa - did you ask FedRAMP for clarification since the Crypto module is called using its API? Is there another proposed approach?