Clarification on Granularity of implementation-status

[telosBA]

• This is a ...

  • [ ] concern - I think something needs to be different.
  • [x] question - I didn't understand something.
  • [ ] kudos - I found something helpful and want to encourage it in future FedRAMP publications.
  • [ ] request - I would like to see something additional provided.

• This relates to ...

  • [ ] the FedRAMP OSCAL Registry (Excel File)
  • [ ] the Guide to OSCAL-based FedRAMP Content (PDF)
  • [x] the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
  • [ ] the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
  • [ ] the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
  • [ ] the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
  • [ ] 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)
  • [ ] General/Overall
  • [ ] Other

NOTE: For feedback related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

• Where, exactly?
  • For the registry, please indicate the tab and cell, or other clear identifier
  • For the guide, please indicate the section number and printed page number (lower right corner)
  • For the OSCAL XML or JSON files, please indicate XML or JSON; and indicate the line number, field id, or other clear location identifier

FedRAMP SSP Guide p.38

• What is your feedback?

• What version of OSCAL are you using? (Check our info on supported OSCAL versions) 1.0.2

• What action would you like to see from the FedRAMP PMO?

What is the granularity of Implementation Status? I.e. if assessors review at the part level, it should be inherited up to the control parent level. Is that acceptable in the reverse?

• Other information (e.g. detailed explanation, related issues, suggestions how to fix, links for us to have context, eg. slack, gitter, etc)

[david-waltermire]

The intent here from an OSCAL perspective is that definition of implementation-status at the control level would apply to all statements, while implementation-status at the statement level would apply to only that statement. This means that implementation-status at the statement level would override the inherited value at the control level for a given component.

This means that for a given component, all effective statement level implementation-status values would need to be the same for the control to have that value. Otherwise, the individual statement level effective values should be used.

[telosBA]

@david-waltermire-nist Is this acceptable?

<implemented-requirement control-id="AC-7.1.a" uuid="eee8697a-bc39-45aa-accc-d3e534932efb">
    <prop name="control-origination" value="organization"/>
    <prop name="control-origination" value="customer-configured"/>
    <link href="same as href from backmatter(FilePath)" rel="artifact"/>       
    <set-parameter param-id="AC01AccConPol1">
      <value>$parameter.answer</value>
    </set-parameter>
    <responsible-role role-id="fedramp-pmo">
      <party-uuid>77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d</party-uuid>
    </responsible-role>
    <statement statement-id="ac-7.1.a-private" uuid="240fa015-01df-4741-bff5-6958c7fb85e5">
        <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f4" uuid="d9d1ce66-ff47-474d-8596-5fdf2af60179">
          <description>
            <p>Text from the system implementation details - system, since control is shared</p>
          </description>  
          <implementation-status state="implemented"></implementation-status>
        </by-component> 
        <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f5" uuid="d9d1ce66-ff47-474d-8596-5fdf2af60179">
          <description>
            <p>Text from the system implementation details - provider project</p>
          </description>  
          <implementation-status state="planned"></implementation-status>
        </by-component> 
    </statement> 
    <statement statement-id="ac-7.1.a-public" uuid="240fa015-01df-4741-bff5-6958c7fb85e5">
        <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f4" uuid="d9d1ce66-ff47-474d-8596-5fdf2af60179">
          <description>
            <p>Text from the system implementation details - system, since control is shared</p>
          </description>  
          <implementation-status state="implemented"></implementation-status>
        </by-component> 
        <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f5" uuid="d9d1ce66-ff47-474d-8596-5fdf2af60179">
          <description>
            <p>Text from the system implementation details - provider project</p>
          </description>  
          <implementation-status state="planned"></implementation-status>
        </by-component> 
    </statement>   
</implemented-requirement>

[telosBA]

The intent here from an OSCAL perspective is that definition of implementation-status at the control level would apply to all statements, while implementation-status at the statement level would apply to only that statement. This means that implementation-status at the statement level would override the inherited value at the control level for a given component.

This means that for a given component, all effective statement level implementation-status values would need to be the same for the control to have that value. Otherwise, the individual statement level effective values should be used.

@david-waltermire-nist please see comment with sample XML to confirm acceptability.