Investigate implementation-status FedRAMP extension for possible retirement

[brian-ruf]

This is a ...

improvement - something could be better

This relates to ...

• the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)

User Story

The implementation-status FedRAMP extension in the /control-implementation/implemented-requirement SSP assembly pre-dates OSCAL 1.0.0 and the by-component/implementation-status fields.

It was established to maintain fidelity with the existing FedRAMP SSP Word templates that require a control-level implementation status rather than the OSCAL-favored implementation status at the component level.

There are two competing principles that impact the continued use or retirement of this prop:

• meeting CSPs where they are when converting legacy SSPs from Word to OSCAL
• utilizing core OSCAL syntax whenever possible, and only using FedRAMP extensions when a use case cannot be satisfied by core OSCAL.

At the heart of these competing principles is the notion that the implementation status of a control as a whole should always be reflective of the implementation status of the individual components linked to that control. While this intuitively seems to be a fair assertion, we must be certain any possible exceptions are understood and addressed.

The real-world FedRAMP control implementation status scenarios need to be documented, and an attempt should be made to model these scenarios using core OSCAL syntax to the greatest degree practical.

Goals

• Ensure all real-world control implementation status scenarios are understood and appropriately modeled
• Ensure core OSCAL is used to the greatest degree practical and FedRAMP extensions are only used when necessary
• Minimize complexity for OSCAL implementers

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.

Other information

No response

[wandmagic]

Proposed deprecation approach for implementation-status FedRAMP extension:

1. Mandate by-component/implementation-status with required this-system component for control-level status
2. Remove 'planned' from allowed values - track separately using planned-completion-date
3. Deprecation timeline:
   • Phase 1: Allow both props, warn on legacy usage (6 months)
   • Phase 2: Require core OSCAL for new submissions (6-12 months)
   • Phase 3: Remove legacy support (12+ months)

This aligns with core OSCAL while providing migration path. Implementation status moves to component level with system-wide status determined by this-system component.

[brian-ruf]

@wandmagic while I like that approach >IF< we decide we can depreciate it, this issue is first about enumerating the use cases to ensure we no longer need the extension first.

[brian-ruf]

Legacy Responses to Implementation Status

The legacy FedRAMP SSP template in MS Word SSP asks the author to select one or more of the following implementation status choices for each control that represents the entire control.

• Implemented
• Partially Implemented
• Planned
• Alternative Implementation
• Not Applicable

---

Current FedRAMP OSCAL Guidance:

FedRAMP only accepts only one of five values for implementation-status: implemented, partial, planned, alternative, and not-applicable. A control may be marked “partial” and “planned” (using two separate implementation-status fields). All other choices are mutually exclusive.

If the implementation-status is partial, the gap must be explained in the remarks field.

If the implementation-status is planned, a brief description of the plan to address the gap, including major milestones must be explained in the remarks field. There must also be a prop (name="planned-completion-date" ns="https://fedramp.gov/ns/oscal") field containing the intended completion date. With XML, prop fields must appear before other sibling fields (such as set-parmeter, responsible-role, etc.), even though that sequence is counter-intuitive in this situation.

If the implementation-status is alternative, the alternative implementation must be summarized in the remarks field.

If the implementation-status is not-applicable, the N/A justification must be provided in the remarks field.

---

Core OSCAL Implementation Status Representation

The implementation-status field exists within the SSP's by-component assembly. This assembly exists both at the implemented-requirement (control) level and at the implemented-requirement/statement (control statement) level.

FedRAMP's OSCAL approach expects all responses at the statement-level. As all responses must be within a by-component assembly, this means there is an implementation-status field associated with every component's statement response.

• //control-implementation/implemented-requirement/by-component/description: describes how a component satisfies an entire control (Not used by FedRAMP)

• //control-implementation/implemented-requirement/by-component/implementation-status: provides the implementation status of the above component at the control level

• //control-implementation/implemented-requirement/statement/by-component/description; describes how a component satisfies an implementation statement within a control. (Used by FedRAMP)

• //control-implementation/implemented-requirement/statement/by-component/implementation-status; provides the implementation status of the above component at the statement level

The PMO expects every statement to have at least one by-component assembly that references component[@type='this-system'].

The core OSCAL allowed values for implementation-status are:

• implemented: The control is fully implemented.
• partial: The control is partially implemented.
• planned: There is a plan for implementing the control as explained in the remarks.
• alternative: There is an alternative implementation for this control as explained in the remarks.
• not-applicable: This control does not apply to this system as justified in the remarks.

Finally, FedRAMP SSP control responses can be represented in OSCAL with one of three approaches:

• Least Granular: Each control statement has exactly one by-component referencing this-system.
• Most Granular: Each control statements has by-component assemblies referencing all applicable components.
• Mixed Granularity: For systems migrating from Least to Most granular. A mix of this-system and specific component references.

---

Core Scenarios:

There are four core scenarios; however, a control may be in a hybrid state where two or more of these scenarios exist simultaneously:

• fully implemented: Only if all statements in the control are fully addressed for all applicable components.
• not applicable: In rare instances, a control does not apply to a system. FedRAMP rarely allows this and always requires a justification, which must be reviewed by assessors and approved by AOs.
• alternative implementation: The spirit and intent of control statements are implemented with a solution that doesn't strictly satisfy the statements, yet satisfy the spirit and intent. FedRAMP rarely allows this and always requires a justification, which must be reviewed by assessors and approved by AOs.
• not implemented: A control is not implemented. FedRAMP rarely allows this and always requires a planned completion date as well as a POA&M entry to track the progress, which must be reviewed by assessors and approved by AOs.

---

FedRAMP Guidance

The following is from the CSP Authorization Playbook, Section 2.4.1.2, page 31:

• Implementation Status: At least one status must be selected for each control.
  • For controls with multiple requirements, a CSP may need to select more than one status. For
    example, AC-8 requires the system to:
    • (a) display a system use notification message before granting access to the system; AND
    • (b) retain the message on screen until the user acknowledges the usage conditions by
      taking an explicit action
  • If the CSP has successfully implemented (a) but is still figuring out a way to implement (b), the
    CSP would select both “Implemented” and “Planned”.

Legacy Reviewer Guidance:

• If an entire control is marked "not applicable", a justification is required and other status values are invalid.
• If a control is applicable (not "not-applicable") and not fully implemented, a planned completion date is required.

---

Analysis and Assertions

Per the Playbook's example, two statements within a control can have different implementation states. Therefore we at least recognize that a whole control has more than one implementation state.

Assertion: A single statement within a control may have more than one implementation status.

Ideally, implementation status should be provided at the statement/component level and derived for the entire control.

Examples

Example #1: AU-3, part f, requires audit log entries to identify all entities associated with an event.
9 of 10 components are configured this way, but the 10th is not. There is a plan to fix the 10th component by the end of the year.

The legacy/Word-template representation of this is to mark the implementation status for AU-3 as "Partially Implemented", with a planned implementation date of Dec 31. The reviewer is then left to read details in an attempt to understand what portion of the control is not implemented.

The OSCAL approach to this can happen one of two ways:

• component approach: is that all 10 components are associated with AU-3 statement f, where nine are described as having been configured to provide entity detail, each with an implementation status of "implemented". The 10th is described as having that capability at a future date with an implementation status of "planned" and as well as the "planned-date" property. The implementation status for the whole control can be derived as "partial" and "planned" with the planned date on the planned portion. A tool has the data necessary to show the user exactly which component is not yet implemented.

• flat approach: there is only one by-component object representing "this-system" and all components are described in that one response. There is only one implementation-status field, yet we need to somehow indicate the control is both "partially implemented" and "planned".

Example #2: AU-4 requires an audit retention capacity that can store all logs for an extended period of time.
The organization plans to do this, but has not yet identified exactly what product will be used. The OSCAL content must reflect that a TBD component is planned.

[brian-ruf]

Discussion

I generally like the recommendation from @wandmagic, and believe it is on-target with some nuances to be worked out.

First, FedRAMP OSCAL SSP guidance does not use the control-level by-component (implemented-requirement/by-component) assembly. It strictly uses the statement-level by-component (implemented-requirement/statement/by-component) assemblies. I'd like to stick to that and not make an exception just to capture implementation status.

Second, I'd prefer to see implementation-status on all by-component assemblies. Not just the "this-system" by-component assembly. Then I'd like to derive the overall control implementation status from the individual values. (i.e. if all are marked "implemented" the control is derived to be "implemented". If most are marked "implemented", but one is partial or planned, the overall control is derived to be "partially" implemented.

Likewise, the planned-completion-date property can be applied to each by-component representing something less than fully implemented. Then planned completion date for the entire control is derived to be the latest of all planned-completion-dates.

Third, FedRAMP OSCAL SSP guidance is that the "this-system" is required for anything less than full component fidelity within a control response. It becomes optional if all relevant components are fully expressed within a control. I'd like to not require it just for implementation-status, yet would love to leave that as a mechanism as a way overriding the derived implementation status.

Finally, all of this works until we get to "Not Applicable", which always applies to the entire control under current FedRAMP conventions. (At some point we should ask FedRAMP reviewers if they will accept N/A at the statement level for OSCAL-based SSPs.) I see three options:

• Option 1: Strictly statement level. All conventions honored:
  • Every statement in the control must have a single by-component assembly referencing "this-system" and an implementation-status of "not-applicable" (this is messy and I don't like this option.)
• Option 2: Strictly statement level, but ignore the response-point convention:
  • N/A is applied only to the top-level statement (i.e. id=ac-1_smt) regardless of the response points defined for that control.
  • This still requires a single by-component that references "this-system" and an implementation-status of "not-applicable"
• Option 3: Deviate from statement-level for N/A only:
  • Uses the control-level by-component instead of statement level only for N/A.
  • This still requires a single by-component that references "this-system" and an implementation-status of "not-applicable"

Recommendation

With the exception of how to handle "Not Applicable" (above) I recommend the following, which is similar to the recommendation from @wandmagic:

• OSCAL FedRAMP SSPs to provide implementation status strictly at the statement level.:

  • The OSCAL representation of implementation status moves away from a property representing the whole control and always requires implementation status at the statement level.
    • This is likely a non-trivial change for tool developers and should be socialized before finalizing.
  • FedRAMP already requires all control responses within implemented-requirement/statement/by-component/description
  • This essentially changes the cardinality of implemented-requirement/statement/by-component/implementation-status from [0 or 1] to [exactly 1], but leaves the cardinality of implemented-requirement/by-component/implementation-status to the core OSCAL default of [0 or 1].
  • The implementation status for the control as a whole is no longer represented in a defined field. It is always derived from the implementation status of its statements and components.

• Support for least/most/transitioning granularity of components within individual statement responses:

  • Least granular (only a single by-component reference to "this-system"):
    • The implementation-status field in the "this-system" by-component assembly represents the status for the entire statement.
  • Most granular (where "this-system" is optional):
    • Every by-component assembly present in the statement response must have an implementation-status.
    • If a by-component representing "this-system" is present, its implementation status is considered holistic for the entire statement.
      • This should typically match the derived implementation status resulting from the other components; however, this may be used to override that derived value where it does not accurately reflect the whole.
      • This offers a way to overcome an issue where all deployed components are "implemented"; however a TBD component is missing.
      • A mismatch of derived status to explicit status within the "this-system" by-component reference should yield a WARNING and warrant further investigation when it appears to decrease the derived implementation status. (i.e. the derived status suggests "implemented", but the explicit "this-system" status is set to "partially implemented")
      • A mismatch of derived status to explicit status within the "this-system" by-component reference should yield an ERROR when it appears to improve the derived implementation status. (i.e. the derived status suggests "partially implemented", but the explicit "this-system" status is set to "implemented")
  • Transitioning granularity (other by-component assemblies are present and the "this-system" by-component reference is required):
    • This will follow the same approach as "Most granular" above, with the only exception being that "this-system" is always a present component.

• Always require exactly one implementation-status in every by-component assembly

  • Move away from including both "partial" and "planned".
  • For the statement\by-component referencing the "this-system" component:
    • implemented: Relative to this control statement, this component is fully implemented.
    • partial: Relative to this control statement, this component is partially implemented.
    • planned: (Equivalent to "not implemented") Relative to this control statement, nothing has been implemented at this time.
    • alternative: Relative to this control statement, this component represents an alternative implementation for this control as explained in the remarks.
    • not-applicable: TBD (see options above)

• The planned-completion-date property is applied at the statement/by-component level:

  • It is required when the implementation-status value is "partial" or "planned".
  • It is optional when the implementation-status is "alternative"
  • It is invalid when the implementation-status is "implemented" or "not-applicable"

[brian-ruf]

After some team discussion, I am leaning toward Option 2 for expression "not applicable".
@Rene2mt was leaning toward Option 3.

[aj-stein-gsa]

@brian-ruf, per discussion today during standup, this is on the agenda for tomorrow's constraint meeting, correct?

[brian-ruf]

Yep! 😊

[brian-ruf]

Variations discussed in today's working session:

• Example 1: Hyperscale CSO is adding a new service to an existing system

  • The service is planned, but not deployed
  • The service is deployed for testing, but does not yet fully satisfy a certain control

• Example 2: CSP converts legacy SSP to OSCAL, but hasn't yet moved to component-based approach and only has "this-system" components at the control level.

Looking for three-passes on this:

• simple use case (only this-system)
• ideal (by-component for every component)
• transition situation (mix)

Explore this approach:

• Eliminate the implementation-status prop (FedRAMP extensions)
• /implemented-requirement/statement/by-component/implementation-status cardinality is 1
• /implemented-requirement/by-component/implementation-status cardinality remains [0 or 1]