[Feedback]: Not clear how to represent Appendix Q: Cryptographic Modules

[devbytyler]

This is a ...

request - need something additional provided

This relates to ...

• the FedRAMP OSCAL Registry
• the FedRAMP OSCAL baselines
• the Guide to OSCAL-based FedRAMP Content
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)
• the Guide to OSCAL-based FedRAMP Security Assessment Results (SAR)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)
• the FedRAMP OSCAL Validations

What is your feedback?

The guide for OSCAL-based FedRAMP SSPs is unclear how to represent several concepts of Appendix Q, namely:

• The relationship between a "source" product/validation pair and "destination" product/validation pair.
• The reference number column, which is supposed to correlate back the "Ports, Protocols, and Services" table.
• Encryption Type (DAR only)
• The "Usage" column, comprising of free text and checkboxes for TLS for DIT.
• The "Notes" column.

For the last two item mentioned, the template language implies that "usage" and "notes" is commentary on the row itself, meaning that the "row" would require some type of data structure to capture the details.

Currently, the only direction given is to link validation and product components together, but that leaves the rest of the data unrepresented.

Internally, we've discussed representing the row as a "data-flow" component to capture the details, but we try to avoid going wild west as much as possible and would appreciate some official direction.

Talked this over with @david-waltermire and @Rene2mt a few weeks back and we agreed this required further discussion.

Where, exactly?

Pages 34 and 35 of the Guide to OSCAL-based FedRAMP System Security Plans (SSP)

Other information

No response

[aj-stein-gsa]

Thanks for the feedback. Constraints, and most importantly clearer documentation and examples, should come in tasks from the upcoming #809 epic. Stay tuned for more details.

UPDATE: Apologies, I made a typo slip up, edited from 807 tracker to 809 as intended.

[brian-ruf]

The analysis and (re)modeling of cryptographic modules will be tracked under this issue.
The following issues are closely related/overlap and will also be resolved as a result of this work:

• [Feedback]: components[@type=validation]props[prop@name=cryptographic-module-usage] #578
• ssp/component[@type="validation"] need additional props and links if prop[@name="cryptographic-module-usage"][@value="data-in-transit"]"] #585
• cryptographic Modules - DIT: How to identify Source and Destination #615

Note this issue also impacts the "validation" #813

[brian-ruf]

The PMO requests cryptographic modules be enumerated in three different categories:

• Data in Transit (DIT): requires information about the modules used at each end of the cryptographic communication.
• Data at Rest (DAR): requires information about the modules used to protect data while it is being stored, such as in a database or on a storage volume/disk
• Other: requires information about cryptography used in any other scenario, such as cryptography associated with checksums, digital signatures, and multi-factor authentication (MFA).

The table in the issue above is the DIT table. Including all three (DIT, DAR and Other) below to be complete:

DIT

DAR

Other

[brian-ruf]

The information needs of these three tables is very similar.

Field	DIT	DAR	Other
Ref #	X	X	X
Area of Use (DIT/DAR/Use)	X	X	X
Crypto-Module Validation
- Cert #	X	X	X
- Nature of Implementation	X	X	X
- Vendor Name	X	X	X
- Module Name	X	X	X
Area of Use (DIT/DAR/Use)	X
Crypto-Module Validation
- Cert #	X
- Nature of Implementation	X
- Vendor Name	X
- Module Name	X
Encryption Type		X	X
Usage
- Statement	X
- Specification	X
Notes	X	X	X

For all three there is a subject component with an associated validation component.

block-beta

   columns 1
    A["Component A"]
    space
    B["Validation A"]

    A --- B

Loading

With Data in Transit, the FedRAMP PMO is interested in both ends of the communication. From an OSCAL perspective, this results in two subject components, each with an associated validation component.

block-beta

   columns 3

   A["Component A"]
   blockArrowId5<["Encrypted<br />Communication"]>(x)
   D["Component B"]
   space
   space
   space
   A --- B["Validation A"]
   space
   D --- E["Validation B"]

Loading

From a data modeling perspective, this is a very similar relationship to interconnections, where the relationship is depicted as

block-beta

   columns 5

   A["'this-system'<br />component"]
   space
   C["'interconnection'<br />component"]
   space
   B["'system'<br />component"]

  C --- A
  C --- B

Loading

As a result, we are considering the following

block-beta

   columns 5

   A["'hardware'<br />'software'<br />or 'service'<br />component"]
   space
   C["Connection"]
   space
   D["'hardware'<br />'software'<br />or 'service'<br />component"]

   space
   space
   space
   space
   space

   A --- B["'validation' component"]
   space
   space
   space
   D --- E["'validation' component"]

   C --- A
   C --- D

Loading

This introduces a "connection" component type, where use the "asset-type" property to depict the nature of the connection. In this case, "encrypted-communication". We believe this construct, along with allowing other "asset-type" property values, will support infrastructure as code capabilities.

[brian-ruf]

Data In Transit (DIT) Example: An internal web server communicates with a database server via TLS 1.3.

block-beta

   columns 6

   A["Web Server<br />'software' component"]
   space
   C["Connection<br />TLS 1.3"]
   space
   D["Database<br />'software'<br />component"]
   space

   space
   space
   space
   space
   space
   space

   A --- B["Web Server's TLS 1.3<br />cryptographic module<br />'validation' component"]
   space
   space
   space
   D --- E["Database Server's TLS 1.3<br />cryptographic module<br />'validation' component"]
   space

   C --- A
   C --- D

Loading

• Represent the web server as a "software" component

• Represent the web server's TLS 1.3 cryptographic module validation as a "validation" component

• In the web server component, include a "validation" link that contains the web server's "validation" component

• Represent the database server as a "software" component

• Represent the database server's TLS 1.3 cryptographic module validation as a "validation" component

• In the database server component, include a "validation" link that contains the database server's "validation" component

• Represent the encrypted communication as a "communication" component (new component type)

• In the "communication" component:

  • include an "asset-type" prop with a value of "encrypted"
  • include an 'Implementation-point' prop with a value of "internal"
  • include a "connection-security" prop/extension with a value of "tls-1.3"
  • include a "used-by" link that contains the web server component's UUID
  • include a "used-by" link that contains the database server component's UUID

Web Server Component:

      <component uuid="11111111-2222-4000-8000-009000300200" type="software">
         <title>Web Server</title>
         <description>
            <p>This is a web server that communicates with a database via 
            an encrypted connection</p>
         </description>
         <prop name="asset-type" value="web-server"/>
         <prop name="baseline-configuration-name" value="Baseline Config. Name"/>
         <prop name="allows-authenticated-scan" value="no" />
         <prop name="scan-type" value="web" ns="http://fedramp.gov/ns/oscal" />
         <link rel="validation" href="#11111111-2222-4000-8000-009001200002" />
         <status state="operational"/>
      </component>

Web Server's Validation Component

      <component uuid="11111111-2222-4000-8000-009001200002" type="validation">
         <title>Cryptographic Module Name</title>
         <description>
            <p>Provide a description and any pertinent note regarding the use of this CM.</p>
            <p>For example, any supporting notes on FIPS status (e.g. historical) or lack of FIPS
               compliance (e.g., Module in Process).</p>
         </description>
         <prop name="asset-type" class="uses-os" value="cryptographic-module"/>
         <prop name="validation-type" value="fips-140-3"/>
         <prop name="validation-reference" value="3920"/>
         <prop name="vendor-name" value="CM Vendor" ns="http://fedramp.gov/ns/oscal" />
         <prop name="function" value="data-in-transit" ns="http://fedramp.gov/ns/oscal">
            <remarks>
               <p>Usage statement</p>
            </remarks>
         </prop>
         <link rel="proof-of-compliance"
            href="https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3920"/>
         <status state="operational"/>

      </component>

Database Server

      <component uuid="11111111-2222-4000-8000-009000300100" type="software">
         <title>Database Sample</title>
         <description>
            <p>None</p>
         </description>
         <prop name="asset-type" value="database"/>
         <prop name="baseline-configuration-name" value="Baseline Config. Name"/>
         <prop name="allows-authenticated-scan" value="yes"/>
         <prop name="scan-type" value="database" ns="http://fedramp.gov/ns/oscal" />
         <link rel="used-by" href="#11111111-2222-4000-8000-009000500006" />
         <link rel="validation" href="#11111111-2222-4000-8000-009001200001" />
         
         <status state="operational"/>
         <protocol name="postgresql">
            <port-range start="5432" end="5432" transport="TCP" />
            <port-range start="5432" end="5432" transport="UDP" />
         </protocol>
      </component>

Database Server's Validation Component

      <component uuid="11111111-2222-4000-8000-009001200001" type="validation">
         <title>Cryptographic Module Name</title>
         <description>
            <p>Provide a description and any pertinent note regarding the use of this CM.</p>
            <p>For data-at-rest modules, describe type of encryption implemented (e.g., full disk,
               file, record-level, etc.)</p>
            <p>Lastly, provide any supporting notes on FIPS status (e.g. historical) or lack of FIPS
               compliance (e.g., Module in Process).</p>
         </description>
         <prop name="asset-type" class="embedded" value="cryptographic-module" />
         <prop name="validation-type" value="fips-140-2"/>
         <prop name="validation-reference" value="3928"/>
         <prop name="vendor-name" value="CM Vendor" ns="http://fedramp.gov/ns/oscal" />
         <prop name="function" value="data-in-transit" ns="http://fedramp.gov/ns/oscal">
            <remarks>
               <p>Usage statement</p>
            </remarks>
         </prop>
         <link rel="proof-of-compliance"
            href="https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/3928"/>
         <status state="operational"/>
      </component>

Communication Component

      <component uuid="11111111-2222-4000-8000-009001400001" type="connection">
         <title>Encrypted Communication</title>
         <description>
            <p>An encryptred communication between the web server and 
            the database server for the purpose of performing SQL queries.</p>
         </description>
         <prop name="asset-type" value="encrypted" />
         <prop name="asset-id" value="ref-01" />
         <prop name="implementation-point" value="internal" />
         <prop name="connection-security" value="tls-1.3" ns="http://fedramp.gov/ns/oscal" />
         <link rel="used-by" href="#11111111-2222-4000-8000-009000300100" />
         <link rel="used-by" href="#11111111-2222-4000-8000-009000300200" />
         <status state="operational"></status>
      </component>      

[devbytyler]

Great to see some ideas on this. Where would your example factor in the service component associated via the Ref #? To me it seems like the service and the "connection" are very related. The service would facilitate the connection and each validation implements the service. Really, I would like to know which table owns the Ref # -- services or appendix q?

Also question: It seems like the connection could specify whether this was data-in-transit, but it could not specify if this was data at rest, since there is no connection in that scenario.

Ports, Protocols, and Services instructions

block-beta

columns 5

space
space
S["Service"]
space
space
A["Web Server Component"]
space
C["Connection"]
space
B["Database Component"]
AV["Validation"]
space
space
space
BV["Validation"]

S --> C
A --> AV
B --> BV
C --> A
C --> B

Loading

Connection Component

      <component uuid="11111111-2222-4000-8000-009001400001" type="connection">
         ...
         <prop name="service-uuid" value="11111111-2222-4000-8000-009001400002" ns="http://fedramp.gov/ns/oscal" />
      </component> 

[brian-ruf]

@devbytyler thank you for the great questions and participation! This is still a work in progress.

The "connection" component is only for data in transit.
DAR/Other will be covered by end of week. Instead of using five components, they will just use two: the subject component and its "validation" component.

Ref

Thank you for highlighting that "Ref #" isn't explicitly addressed yet. We have to determine if it is even necessary in OSCAL given how the OSCAL version of the content is used. The challenge is finding a way to apply it consistently across all three table types (DIT, DAR, and Other). With DIT it is most appropriately associated with the "connection" component from a data modeling and normalization perspective; however, with DAR and Other, the "validation" component is the most appropriate location for a reference number.

Any thoughts/insights are appreciated here.

Cryptographic Module Implementation Point

Please note, we still need to define a property to capture the module implementation check boxes. (Embedded, Third-party, Uses OS, In FIPS Mode, Other). This is best captured in the "validation" component.

I'd prefer to simply use core OSCAL's "implementation-point" property for this; however, the only allowed values for that property are "internal" and "external". We could create a FedRAMP Extension (FRX) by the same name, but have avoided doing that as a general rule to avoid confusion. (and because some tools are not good about checking whether a property is in the core OSCAL namespace or another namespace).

As a result, I am considering a FedRAMP Extension/prop name recommendation of "module-implementation" or "cm-implementation-point".
Again, I welcome thoughts on any of this.

Connection vs. Service

I am not sure we view "service" components the same way.
It appears you are using "service" components as another option to represent the interaction between components, which is interesting and a bit different from how I view components.

In my view the database is represented using either a "software" component or a "service" component.

• If the CSP is hosting it on a CSP managed VM, it's a "software" component.
• If the CSP is using something like an AWS RDS instance, it's represented as a "service" component.

Either way, the database component include the protocol information, and has an associated "validation" component representing its TLS 1.3 cryptographic module.

The "communication" component is the only representation of the interaction between the web server and the database.

block-beta

   columns 6

   A["Web Server<br />'software' component"]
   space
   C["TLS 1.3 Connection<br />'connection' component"]
   space
   D["Database Service<br />'service' component"]
   space

   space
   space
   space
   space
   space
   space

   A --- B["Web Server's TLS 1.3<br />cryptographic module<br />'validation' component"]
   space
   space
   space
   D --- E["Database Service's TLS 1.3<br />cryptographic module<br />'validation' component"]
   space

   C --- A
   C --- D

Loading

I want to better understand your thinking on this point.

[brian-ruf]

@devbytyler I just re-read your comment from Tuesday and realized that I missed an important part of what you were asking about Ref #. We will factor in the best way to link the Ports Protocols and Services table entries to Appendix Q in OSCAL. I still maintain that the Ref # may not be necessary in OSCAL, even when considering that use case, but more analysis is required before a definitive statement can be made.

[brian-ruf]

As a general comment to this issue, this analysis work attempts to keep the following guiding principles in mind:

• Use core OSCAL whenever possible
• Only use/create FedRAMP extensions (FRX) when absolutely necessary to meet FedRAMP information requirements
• Normalize the required information as much as practical.
• Cryptographic module information should be consistently maintained within the context of where it applies
• Appendix Q should simply be a summary of that in-context cryptographic module information
  • i.e. cryptography is always associated with its relevant component(s) and no additional effort should be required to generate Appendix Q.

[brian-ruf]

Cryptographic modules have been underdefined in FedRAMP's representation of OSCAL. This has been causing challenges when responding to Appendix Q.

For example, if a web server is using a FIPS validated OpenSSL cryptographic module within the underlying operating system, we have incorrectly attempted to model that as a direct relationship between the web server and the "validation" component.

Historic, but Wrong

block-beta

   columns 1
    A["Component A"]
    space
    B["Validation A"]

    A --- B

Loading

We should actually be attempting to model this:

I would like to propose the above situation is modeled like this:

This is interpreted as follows:

• The web server "depends-on" the Operating System (because it runs on the OS)
• The cryptographic module is "used-by" the web server
• The cryptographic module is "provided-by" the operating system (because it came bundled within the OS)
• The cryptographic module has received one independent validation as documented in the linked "validation" component. (If a CM has more than one validation, each would be in a separate "validation" component and linked from the one CM)

NOTE: Still working on the best way to clarify which crypto module is used by a component for a particular communication, when more than one communication scenario exists for the component.

[brian-ruf]

The following constraints are required and are not likely to change as a result of follow-up re-modeling efforts:

Per the above comment, cryptographic modules must be defined as their own component and linked to the components that use them.

Cryptographic Modules

A cryptographic module is represented as a "software" component with an "asset-type" property value of "cryptographic-module".

context="//component[@type='software' and ./prop[@name='asset-type' and @value='cryptographic-module']]"

All cryptographic modules must have the following, which are required of all software components and should already be addressed under other issues:

• "software-name" property

• "software-version" property

• "vendor-name" property

• "function" FedRAMP Extension

• "function" FedRAMP Extension / Remarks

• One difference from the above is a cryptographic software module's allowed values for "function" are:

  • data-at-rest: The cryptographic module is used to encrypt/decrypt data at rest, such as on a hard drive or in a database.

  • data-in-transit: The cryptographic module is used to encrypt/decrypt data being communicated, such as over a TLS connection.

  • other: The cryptographic module is used as described in the remarks.

  • NOTE: The above three align with Appendix Q requirements; however, there are a few other specific values we could add to this list, such as key-generation, key-validation, digital-signature, password-hash, and cryptographic-checksum.

  • At least one "provided-by" link, indicating where the module exists, such as an operating system component.

  • At least one "used-by" link indicating which components use this cryptographic module

  • At least one "validation" link, that references a FIPS 140-2 or 140-3 "validation" component.

    • A FIPS 140-2 or 140-3 "validation" component is identified by ALL of the following:
      • type="validation"
      • "asset-type" property = "cryptographic-module"
      • "validation-type" property = either "fips-140-2" or "fips-140-3"
      • //component[ @type='validation' and ./prop[@name='asset-type' and @value='cryptographic-module'] and ./prop[@name='validation-type' and @value=('fips-140-2', 'fips-140-3')] ]

  • A "cryptographic-module" component may identify more than one validation component. At least one must be a FIPS validation component

FIPS Validation Components

While other forms of validation may be documented in the SSP using "validation" components, FedRAMP is only interested in FIPS validation components. All others may be ignored.

context="//component[ @type='validation' and ./prop[@name='asset-type' and @value='cryptographic-module'] and ./prop[@name='validation-type' and @value=('fips-140-2', 'fips-140-3')] ]"

All FIPS validation components must have:

• a "validation-reference" property

• a "validation-reference" property containing the NIST Labs-assigned Certificate number

• a "proof-of-concept" link

• The "proof-of-concept" link must contain an @href value that is resolvable on the public Internet.

  • NOTE1: There are additional checks we could do here, but it would require us to keep pace with any changes NIST may make to the CMVP catalog. These include:
    • Ensuring the @href value starts with https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/
    • Appending the "validation" reference value to https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/ and checking for Internet resolution as a means of verifying the certificate number is at least recognized, since that is how the URL is currently crafted.

Automated Correlation

Unfortunately, I can find no information that the CMVP database offers an API nor an up-to-date XML or JSON file for machine-readable reference.

I sent an email to the NIST CMVP program managers this evening asking if any such capability exists or is in-plan.

If/when such a capability exists, we will want to validate the certificate #'s via the API and possibly even cross-check some of the information required above against the CMVP data, such as software name, vendor name, and version number.