SSP Completeness Checks: 7 External Systems and Services Not Having FedRAMP Authorization

[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:

• Check for presence
• If present, check for required fields

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

• Check allowed values for user authentication #891
• SSP Leveraged Authorization Entries #897
• Allowed Values for nature-of-agreement for external systems #907
• Add user-authentication Allowed Values #921
• Authentication Method Constraint for Leveraged Authorizations and External, Interconnected, and Unauthorized Systems #924
• Components representing inter-boundary communication need to declare the direction of data flow #930
• Each Interconnection, Service, or Software Connecting to an External Systems Must be Linked to a POA&M Entry #934
• Provider Constraint for Leveraged Authorizations and External, Interconnected, and Unauthorized Systems #937
• Authorized Users for Leveraged Authorizations and External, Interconnected, and Unauthorized Systems #893
• Information Types for for Leveraged Authorizations and External, Interconnected, and Unauthorized Systems #942

[brian-ruf]

There are five scenarios that require tracking as part of External Systems and Services Not Having FedRAMP Authorization:

• Scenario 1: A non-authorized service from a FedRAMP leveraged authorization
• Scenario 2: An interconnection between this system and an external system
• Scenario 3: A service from an external system other than the leveraged system
• Scenario 4: A service from this system offered to external systems
• Scenario 5: A CLI that connects to leveraged or external systems

In all scenarios:

• The "interconnection", "service", or "software" component is tied to an external "system" component:
  • For "service" and "software" this is via a "provided-by" link.
  • For "interconnection" this is via a "used-by" link.
• Details about the information exchanged stay with the "interconnection", "service", or "software" component
• Details about the provider stay with the "system" component.
• Still working on this list

Scenario 1: A non-authorized service from a FedRAMP leveraged authorization

A service from an underlying leveraged system, where the underlying system is FedRAMP-authorized; however, the service is not included in the underlying system's authorization. (The service is not included in the underlying's system's FedRAMP Marketplace details.)

• Create one //component[@type='service'] for each non-authorized leveraged service used by this system
• Unlike the use of services falling under the leveraged system's authorization, the above component must NOT have prop[@name='leveraged-authorization-uuid'].
  • This would incorrectly indicate the service is covered under the authorization. It is not.
• Link the service component to the leveraged system using the component UUID of the leveraged system in: //component[@type='service']/link[@ref='provided-by']/@value
  • Need to defer due to incorrect constraint in core OSCAL syntax.
• Include an "implementation-point" property with the value set to "external".
• Include one or two "direction" property

graph LR;
   A[This System<br />type='this-system']-->B[Non-Authorized Leveraged Service<br />type='service']-->C[Leveraged System<br />type='system'];

Loading

Scenario 2: An interconnection between this system and an external system

FedRAMP-Authorized System connecting to an external system that may or may not be FedRAMP-authorized.

• Create one //component[@type='system'] for each external system
• Create one //component[@type='interconnection'] for each connection between this system and the external system
• Link the interconnection component to the external system using the component UUID of the external system in: //component[@type='service']/prop[@name='connected-to-system-uuid'][@ns='http://fedramp.gov/ns/oscal']/@value
• Link the interconnection component to this system using the component UUID of the this systemin : //component[@type='service']/link[@rel='used-by']/@value
• Include an "implementation-point" property with the value set to "external".
• Provide Interconnection Security Agreement details
• Provide remote and local connection details
• Provide common external service details

graph LR;
   A[This System<br />type='this-system']-->B[Interconnection<br />type='interconnection']-->C[External System<br />type='system'];

Loading

Scenario 3: A service or API from an external system other than the leveraged system

FedRAMP-Authorized System using an API or service from an external system:

• Create one //component[@type='system'] for each external system
• Create one //component[@type='service'] for each service or API used
• Select the asset-type that best describes the function provided by the service or API.
  • Give preference to core OSCAL asset-type values, and only define/use others if none of those fit.
• Link the service component to the leveraged system using the component UUID of the leveraged system in: //component[@type='service']/link[@rel='provided-by']/@value
  • Need to defer due to incorrect constraint in core OSCAL syntax.
• Include an "implementation-point" property with the value set to "external".
• Provide remote connection details
• Provide common external service details

graph LR;
   A[This System<br />type='this-system']-->B[External Service<br />type='service']-->C[External System<br />type='system'];

Loading

Scenario 4: A service or API from this system and offered to external systems

FedRAMP-Authorized System offering an API or service for external systems:

• Create one //component[@type='service'] for each service or API used
• Select the asset-type that best describes the function provided by the service or API.
  • Give preference to core OSCAL asset-type values, and only define/use others if none of those fit.
• Include an "implementation-point" property with the value set to "internal".
• Provide local connection details
• Provide common external service details

graph LR;
   A[This System<br />type='this-system']-->B[Offered Service or API<br />type='service'];

Loading

Scenario 5: A CLI that connects to leveraged or external systems

FedRAMP-Authorized System using an CLI to manage remote or underlying system:

• Create one //component[@type='system'] for each system where the CLI can effect change
• Create one //component[@type='software'] for each CLI used
• Specify the software component's asset type as "cli"
• Link the software component to the leveraged system using the component UUID of the leveraged system in: //component[@type='service']/link[@rel='provided-by']/@value
• Include an "implementation-point" property with the value set to "external".
• Provide remote connection details
• Provide common external service details

graph LR;
   A[This System<br />type='this-system']-->B[Management CLI<br />type='software']-->C[External or Leveraged System<br />type='system'];

Loading

[brian-ruf]

TARGET:

• //system-implementation/component[((@type=('system', 'service')) and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='software' and ./prop[@name='asset-type' and @value='cli'])]

Data	Location	UnAuth Service from LA	Intercon	External Service	External API	Offered API	Management CLI
Component Type(s)	n/a	system service	system interconnection	system service	system service	this-system service	system service
link[@rel='provided-by']	n/a	1	0	1	1	1	1
link[@rel='used-by']	n/a	0+	2+	0+	0+	0+	0+
#	n/a / Sequential Numbering	n/a	n/a	n/a	n/a	n/a	n/a
System/Service/API/CLI Name	./title (required field)	1	1	1	1	1	1
Service Processor Name [in "system"]	./responsible-role[@name='provider']/party-uuid (in associated system per the "provided-by" or "used-by" link	1	1	1	1	n/a	1
Connection Details (Direction) [1 or 2]	./prop[@name='direction']/@value	1-2	1-2	1-2	1-2	1-2	1-2
Connection Details (Local IPv4 Address) [0+]	./prop[@name='ipv4-address' and @class='local']/@value	0+	0+	0+	0+	0+	0
Connection Details (Local IPv6 Address) [0+]	./prop[@name='ipv6-address' and @class='local']/@value	0+	0+	0+	0+	0+	0
Connection Details (Local Port) [0+]	./protocol[@name='local']/port-range	0+	0+	0+	0+	0+	0
Connection Details (Local URI/URL) [0+]	./link[@rel='api']/@value	0+	0+	0+	0+	0+	0
Connection Details (Remote URI/URL) [0+]	./link[@rel='api']/@value	0+	0+	0+	0+	0	0+
Connection Details (Remote IPv4 Address) [0+]	./prop[@name='ipv4-address' and @class='remote']/@value	0+	0+	0+	0+	0	0+
Connection Details (Remote IP6 Address) [0+]	./prop[@name='ipv6-address' and @class='remote']/@value	0+	0+	0+	0+	0	0+
Connection Details (Remote Port) [0+]	./protocol[@name='remote']/port-range	0+	0+	0+	0+	0	0+
Connection Details (Non-IP Based) [0 or 1]	./prop[@name='non-ip-based-connection' and @ns='http://fedramp.gov/ns/oscal']/@value	0+	0+	0+	0+	0+	0+
Connection Details (Security) [1+]	./prop[@name='connection-security' and @ns='http://fedramp.gov/ns/oscal']/@value	1+	1+	1+	1+	1+	1+
Nature of Agreement [1]	./prop[@name='nature-of-agreement' and @ns='http://fedramp.gov/ns/oscal']/@value	1	1	1	1	1	1
Still Supported? [1]	./prop[@name='still-supported' and @ns='http://fedramp.gov/ns/oscal']	1	1	1	1	1	1
Data Types [1+]	./prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']/@value	1+	1+	1+	1+	1+	1+
Data Categorization (Confidentiality) [from //system-information]	//system-characteristics/system-information/information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']/information-type-id/text()=./prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']/@value]/confidentiality-impact/selected	n/a	n/a	n/a	n/a	n/a	n/a
Data Categorization (Integrity) [from //system-information]	//system-characteristics/system-information/information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']/information-type-id/text()=./prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']/@value]/integrity-impact/selected	n/a	n/a	n/a	n/a	n/a	n/a
Data Categorization (Availability) [from //system-information]	//system-characteristics/system-information/information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']/information-type-id/text()=./prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']/@value]/availability-impact/selected	n/a	n/a	n/a	n/a	n/a	n/a
Authorized Users	//component/responsible-role[not(@role-id='provider']	1+	1+	1+	1+	n/a	1+
User Authentication Method	//component/prop[@name='authentication-method' and @ns='http://fedramp.gov/ns/oscal']	1+	1+	1+	1+	1+	1+
Other Compliance Programs [ may be in "system" or "interconnection", "service", "software" ]	./prop[@name='compliance-program' and @ns='http://fedramp.gov/ns/oscal']/@value	0+	0+	0+	0+	0+	0+
Description [1] OSCAL	./description (Required)	1	1	1	1	1	1
Hosting Environment [1]	./prop[@name='hosting-environment' and @ns='http://fedramp.gov/ns/oscal']	N/A	1	1	1	1	1
poam-item [1]	./link[@rel='poam-item'	1	1	1	1	1	1

[brian-ruf]

Table 7.1 Constraint Goals

There are two primary goals to constraints related to table 7.1:

1. Ensuring every communication path that crosses the authorization boundary is represented by a component pair.
2. Ensuring the required content is present, which differs slightly due to differences in the ways communication can cross the authorization boundary.

Although all of table 7.1 is represented using components, only the "interconnection" component type always represents communication that crosses the authorization boundary. Additional content is required in "service" and "software" component types to determine if they represent communication that crosses the boundary.

---

Constraints

Checkboxes Below

The checkboxes are to track the inclusion of the constraint in a defined task issue. Checked indicates the constraint should be fully covered by a task that appears in the task list at the top.

Critical Constraints

Some component types can represent either inter- or intra- boundary communication. As a result, certain fields are required to disambiguate.
target="//component [@type='service' or (@type='software' and ./prop[@name='asset-type' and @value='cli']) ]"

• All "service" components and all "software"/"cli" components must have exactly one "implementation-point" property.
  • count(./prop[@name='implementation-point']) = 1

Constraints that apply to the entire group:

target="//component[ (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction']) or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ]"

• There must be at least one direction property, with no more than one incoming and no more than one outgoing direction:

  • count(./prop[@name='direction'])>=1
  • count(./prop[@name='direction' and @value='incoming']) <= 1
  • count(./prop[@name='direction' and @value='outgoing']) <= 1

• If ./prop[@name='direction' and @value='incoming']

  • If direction is incoming there must be at least one local ipv4 address, ipv6 address, or URI to an API.
    • count( (./prop[@class='local' and @name=('ipv4-address', 'ipv6-address')]) or (./link[@rel='uri']) ) >=1
  • If direction is incoming there must be at least one local protocol entry.
    • count(./protocol[@name='local']/port-range/@start)

• If ./prop[@name='direction' and @value='outgoing']

  • If direction is outgoing there must be at least one remote ipv4 address, ipv6 address or URI to an API.
    • count( (./prop[@class='remote' and @name=('ipv4-address', 'ipv6-address')]) or (./link[@rel='uri']) ) >=1
  • If direction is outgoing there must be at least one remote ports entry.
    • count(./protocol[@name='remote']/port-range/@start)

• There must be at least one connection security property:

  • count(./prop[@name='connection-security' and @ns='http://fedramp.gov/ns/oscal']) >= 1

• There must be exactly one nature of agreement property:

  • count(./prop[@name='nature-of-agreement' and @ns='http://fedramp.gov/ns/oscal']) = 1

• Every role defined in //component/responsible-role/@role-id must exists in //metadata/role/@id index (Should be enforced by core OSCAL, but isn't)

• Every party defined in //component/responsible-role/@role-id/party-uuid references a valid party in //metadata/party/@uuid index

  • This is enforced by core OSCAL. No constraint needed.

• There must be at least one responsible-role entry other than the required provider's role:

  • count(./responsible-role[not(@role-id='provider')]) >= 1

• All responsible-role/@role-id values must be in the //metadata/role/@id index.

• All ./responsible-role[]/party-uuid values must exists in the //metadata/party index.

  • This may already be addressed by core OSCAL metaschema

• There must be at least one user authentication method property:

  • count(./prop[@name='authentication-method' and @ns='http://fedramp.gov/ns/oscal']) >= 1

• Each user authentication property must have a remarks field

  • count(./prop[@name='authentication-method' and @ns='http://fedramp.gov/ns/oscal']) = count(./prop[@name='authentication-method' and @ns='http://fedramp.gov/ns/oscal']/remarks) (I'm pretty sure there is a better way to do this)

• Allowed values for the authentication-method property:

  • yes
  • no
  • not-applicable

• There must be at least one risk property, either stating a risk or stating there is no risk.

  • count(./prop[@name='risk' and @ns='http://fedramp.gov/ns/oscal']) >= 1
  • Based on feedback from reviewers in # This has been revised. Now there must be exactly one "poam-item" link as described in issue Each Interconnection, Service, or Software Connecting to an External Systems Must be Linked to a POA&M Entry #934

• There must be one or more "information-type" property/extensions. The value of each, must be included in the system information.

  • count(./prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']/@value) >= 1
  • target="//component[ (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction']) or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ] /prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']"
    • count(//system-characteristics/system-information/information-type/categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1' and ./information-type-id=./@value]) = 1

Allowed Values:

• Allowed values for "compliance" property/extensions:

  • target="//component[ (@type='system' and ./prop[@name='leveraged-authorization-uuid']) or (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction']) or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ] /prop[@name='compliance' and @ns='http://fedramp.gov/ns/oscal'] "
  • Allow Others = "yes"
    • pci-dss: Payment Card Industry Data Security Standard (PCI DSS)
    • iso-27001: ISO/IEC 27001
    • soc-2-type-1: System and Organization Controls 2 (SOC 2) Type 1 Assessment
    • soc-2-type-2: System and Organization Controls 2 (SOC 2) Type 2 Assessment
    • hipaa: Health Insurance Portability and Accountability Act
    • csa-star-level-1: Cloud Security Alliance (CSA) Security Trust Assurance and Risk (STAR) Level 1
    • csa-star-level-2: Cloud Security Alliance (CSA) Security Trust Assurance and Risk (STAR) Level 2

• Allowed values for "asset-type" property:

  • target="//component[@type='system']"
  • Allow Others = "yes"
    • saas: A Software-as-a-Service cloud;-based system
    • paas: A Platform-as-a-Service cloud;-based system
    • iaas: An Infrastructure -as-a-Service cloud;-based system
    • other: Another

Constraint Grouping:

There is some variance in the the required information based on the nature of the communication crossing the boundary. Some constraints must be applied to a sub-set of the components.

Constraints that apply only to interconnections:

target="//component[ @type='interconnection' ]"

• There must be at least two "used-by" links (one that points to this-system and one that points to an external system):

  • count(./link[@rel='used-by'])>=2

• Exactly one "used-by" link's href should contain a URI fragment that includes the UUID of the "this-system" component.

  • count(//component[@type='this-system' and @uuid=./link[@rel='used-by']/substring-after(@href, "#")])

• One or more "used-by" link's href should contain a URI fragment that includes the UUID of a "system" component with an "implementation-point" property value set to "external".

  • count(//component[@type='system' and @uuid=./link[@rel='used-by']/substring-after(@href, "#") and ./prop[@name='implementation-point' and @value='external']]) >= 1

• One or more interconnection security agreements must be attached as a back-matter resource, each with an "agreement" link.

  • count(//resource[@uuid=substring-after( ./link[@rel='agreement']/@href, "#")]) >= 1
  • By requiring the ISA to be a back-matter resource, we can simply enforce the title and version at the resource, and do not need separate properties for this data in the "interconnection" component.
    • count(//resource[@uuid=substring-after( ./link[@rel='agreement']/@href, "#")]) = count(//resource[@uuid=substring-after( ./link[@rel='agreement']/@href, "#")]/title)
    • count(//resource[@uuid=substring-after( ./link[@rel='agreement']/@href, "#")]) = count(//resource[@uuid=substring-after( ./link[@rel='agreement']/@href, "#")]/prop[@name='published'])
    • count(//resource[@uuid=substring-after( ./link[@rel='agreement']/@href, "#")]) = count(//resource[@uuid=substring-after( ./link[@rel='agreement']/@href, "#")]/version)

• The ISA Remote system name is available via the "used-by" link to the "system" component.

  • count(//component[@uuid=//component[@type='interconnection']/link[@rel='used-by']/substring-after(@href, "#") and @type='system']/title) = ( count(./link[@rel='used-by']) - 1)

• NOTE: The FedRAMP Rev 5 requirements no longer include POC details about the interconnection. While these fields are still encouraged, they are not required, thus no constraints are necessary.

Constraints that apply to external communication other-than interconnections

target="//component[ (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction']) or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ]"

• There must be exactly one "provided-by" link:
  • count(./link[@rel='provided-by'])=1
• The "provided-by" link's href should contain a URI fragment that includes the UUID of a "system" component with an "implementation-point" property value set to "external".
  • ./link[@rel='provided-by']/@href
  • //component[@type='system' and ./prop[@name='implementation-point' and @value='external'] and @uuid=[ --uuid-portion-of-href-URI-fragment-- ]]

Constraints that apply to external communications other an offered services/APIs

target="//component[ (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ]"

• There must be exactly one Service Processor / Provider

  • count(./responsible-role[@name='provider']/party-uuid)=1

• There must be exactly one still supported property:

  • count(./prop[@name='still-supported' and @ns='http://fedramp.gov/ns/oscal']) = 1

• There must be exactly one linked external system

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

Constraints that apply to external communications other an non-authorized leveraged services

target="//component[ (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction']) or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ]"

• There must be exactly one hosting environment property
  • count(./prop[@name='hosting-environment' and @ns='http://fedramp.gov/ns/oscal']) = 1

NOTE: There may be no way to exclude this property only from external services that are non-authorized services of a leveraged system as the relationship between the service and its system (which would have a leveraged authorization property) is via an href with a URI fragment. I am unaware of how to decompose a URI fragment to just the resolvable UUID portion (essentially by dropping the leading hash/#).

Worst case, we can make the hosting environment property required for all components in the group and not make this distinction.

[brian-ruf]

NIST OSCAL Issues Blocking This Issue

• Expansion of Protocol Tag to other components usnistgov/OSCAL#1913
• Error with port range definition in Component-def usnistgov/OSCAL#2023
• Warning raised for not providing a protocol>uuid usnistgov/OSCAL#2044

These are being addressed by PR usnistgov/OSCAL#2077

[Telos-sa]

@brian-ruf for the first scenario, are you also taking into account the additional props for a service that does not have a FedRAMP ATO? Since it is "offered by" the packaged, but not actually authorized, will the iso-poc's still be required, and the connection agreement, or can we still piggy back off of the lev-auth poc and sla? This may be a @aj-stein-gsa question, but I like this structure.
Didnt see "offered-by" in the core oscal constraints, but this could be a bespoke prop created by FedRAMP to support their specific use case (especially if they make determinations of all elements required for this use case).

Scenario's 2-5 seem like they are fully covered under OSCAL and defined in the FedRAMP use case.

For the constraint grouping, what is the use case for linking the interconnection component to this-system? Is it strictly for external implementation points? I am not sure that this constraint should be included, as the this-system already represents the entire package. Specificity should be included where more detail is needed and provides value to the reviewer. It could maybe be a conditional constraint, but I would want to understand what value that constraint brings to the assessor and Authorization process.

[brian-ruf]

@Telos-sa you actually caught a mistake. It was supposed to be "provided-by", not "offered-by". I've corrected. "provided-by" is part of the core OSCAL syntax.

Yes the goals here are as follows:

• use core OSCAL syntax as much as possible.
• keep the data constructs the same as much as possible between 6.1 (LAs) and 7.1 (external and unauthorized)
• Keep the data normalized as much as possible, which includes referring to the to information from the leveraged system on behalf of the service, rather than duplicating that information into the service.

It's still a work in progress, but I'm working on one example for each of the above scenarios here:
https://github.com/brian-ruf/fedramp-automation/blob/example-ssp/src/content/rev5/examples/ssp/xml/FedRAMP-SSP-Example.OSCAL.xml

[brian-ruf]

Changed user-authentication property/extension to authentication-method.

[brian-ruf]

Modifying the "user-authentication" property/extension to an "authentication-method" property/extension as the true intention of this information is to document the nature of any authentication method, whether it be external users or external systems/automation accounts.

[aj-stein-gsa]

Changed user-authentication property/extension to authentication-method.

@brian-ruf, just a heads up because I can tell this may be the same thing as the leveraged authorization prop will likely be the same thing, that prop elsewhere is already wrapping on a review. If we wanted to change that, we may want to notify Gabe as he is working on #891.

[brian-ruf]

@aj-stein-gsa thank you. Yes, I actually needed to make notes/revisions to PR #921, as well as issues #807, #891, #893, #897, and created issue #924.

The good news is this will check boxes in both 807 and 808. While I did have to tweak the language associated with the allowed values, it turned out that language was missing from the PR anyway. So we can get the updated language in when that gets corrected.

[brian-ruf]

After consultation with the review team as captured in #935, we have eliminated "risk", "mitigation", and "impact" property/extensions in favor of a "poam-item" link. This is based on the assertion that every entry in Table 7.1 is required to have a corresponding POA&M entry.

The primary benefits of referring to the POA&M entry can include:

• elimination of redundancy
• simplicity of data modeling and tool development
• the POA&M model offers far more comprehensive treatment of risk and mitigation vs property/extensions