Skip to main content

Retrofit Adoption

Compliance frameworks vary greatly. Within a framework, the granularity of required information can also vary from one organization to the next.

OSCAL is designed to normalizes the variability between frameworks. It also offers flexibility to handle information at varying levels of granularity. As a result, representing content in OSCAL can be ambiguous to early adoptors.

As with any technology project, OSCAL adoption should start with the minimum viable product (MVP) and evolve to more comprehensive use cases.

SSP Adoption Overview

The OSCAL Foundation recommends the following addoption path for FedRAMP SSP creation.

SSP_Adoption_Path.png

  • MinimumTo Viable Product (MVP): Simplefacilitate conversion of controlslegacy andWord inentory.content, MinimumOSCAL necessaryallows front-matter.
  • Intermediate: Begin including required attachments and additional front-matter.
  • Advanced: Include most remaining SSP topics, convert inventory to use components.
  • Ideal: Include remaining SSP topics that rely heavily on the use of components. Begin convertinglegacy control responses to align with relevant components.
OSCAL is designed so that controls can start with legacy responsesbe associated with the "this-system" componentcomponent. andCSPs can migrate slowly over time to the OSCAL-preferred, component-specific responses. The two may be mixed as needed during transition.

See details below.

SSP Adoption Path

Minimum Viable Product (MVP)

  • Minimum Front-Matter and OSCAL-required Content.

    • metadata includes:
      • title, published, last-modified, version, oscal-version
      • roles: CSP, ISSO, others as cited in controls
      • parties: the CSP
      • responsible-party: exactly one, linking the CSP party to the CSP role
    • system-characteristics includes:
      • system-id, system-name, system-name-short, description
      • cloud-service-model prop and cloud-deployment-model prop
      • security-sensitivity-level (fips-199-high, fips-199-moderate, fips-199-low)
      • system-information: exactly one entry with Appendix K pasted into the description
      • status: Required field. Use as-is
      • authorization-boundary: description and links entry identifying the external attachment.
      • network-architecture: description and links entry identifying the external attachment.
      • data-flow: description and links entry identifying the external attachment.
    • system-implementation includes:
      • users: Required by OSCAL, but no longer required by FedRAMP.
        • Single authorized-privilegesentry with emptytitleandfunction-performed` set to "none"
      • this-system components entry

  • Convert controls without modification, with all response statements in the "this-system" component.

    • control-implementation
      • implemented-requirement (AC-1, AC-2, etc.)
        • set-parameters: set parameters as needed
        • statement (part a, part b, etc.
          • by-component ("this system")
            • description: Content directly from legacy Word SSP (part a, part b, etc.)
            • implementation-status
            • responsible-roles: One entry per role. Use role-id. Must match metadata/roles/id.

  • Flat Inventory, converted directly from spreadsheet. No corrisponding components.

    • system-implementation:
      • inventory-items: All inventory converted from Excel spreadsheet

Intermediate

  • Required attachments

    • Add direct links from the appropriate controls to identify relevant attachments

  • Required SSP roles

    • metadata/roles The roles required by SSP (System owner, ISSO, AO, etc.)
    • metada/parties: the people, teams and organizations responsible for the above roles
    • metadata/responsible-parties: links the above roles and parties

  • Information types

    • system-characteristics/system-information/information-types
      • a single entry for each row in appendix K.

  • leveraged authorizations

    • system-implementation/leveraged-authorizations:
      • one entry for leveraged authorization
      • corrisponding metadata/parties entry for each
      • corrisponding system-implementation/components for each.

  • Separation of Duties Matrix

    • system-implementation/users
      • one entry per row in Table 11.1
      • ./authorized-privilege/functions-performed: SSP Table 11.1 Duty Description (just one entry in the array)
      • ./authorized-privilege/title: Required by OSCAL, not by FedRAMP. Recommend duplicating the functions-performed content.
      • role-ids: links metadata/roles to functions-performed

  • Customer Responsibility and Inheritance:

    • Move customer responsibility statements to //by-components/export/responsibilities

Advanced

  • Normalize Inventory: Transition flat inventory to component-based inventory.

    • Use components to the greatest degree practical
    • inventory-items become implemented instances of components

  • external systems and services

    • system-implementation/components entries for each

  • Transition to resources

    • Where practical, links entries use URI fragments to reference resources instead of direct links.

  • Components for Required Documents

    • policy components entries for each required policy
    • process-procedure components entries for each required process
    • plan components entries for each required plan
    • _useradd components for policies, processes, plans and other documents

Ideal

  • Services, Ports and Protocols

  • Cryptographic Modules (App Q table)

  • Migrateto component-based control responses

    • Add by-components entries to implemented-requirements for each relevant component
    • Add/move component-specific control responses to their associated by-components response.
    • Migrate slowly over time.
Back to top