Retrofit Adoption Path

If you need to convert legacy documentation to OSCAL, follow this path.

If you are approaching OSCAL to intially create your system security plan and do not have legacy documentaiton to convert, follow the New Adoption Path.

Organizations with existing Word and Excel based authorization packages must first migrate their content to OSCAL with only the minimum necessary refactoring. The Retrofit Adoption Path starts with a minimum viable product (MVP) and evolves to more comprehensive use cases in phases.

This approach initially sacrifices data normalization in favor of a more rapid transition to OSCAL. It allows conversion of content as-is, then gradually eliminates redundancy and normalizes data in subsequent phases. This is possible because OSCAL is designed to meet you where you are, and it allows gradual progress toward its more normalized ideal representation.

SSP Retrofit Adoption Overview

The OSCAL Foundation recommends the following addoption path for migrating legacy FedRAMP SSP content to OSCAL.

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: cloud-service-provider, information-system-security-officer, others as cited in controls. See [section and link] for more information.
    • parties: the CSP, the ISSO
    • responsible-parties: 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:
    • `components:
      • Exactly one, with type= this-system (Known as the "this-system" component, which represents the system as a whole.)

• ConvertMigrate controlsControls

  without
  modification,
  • Minimum-necessary withadjustments allfor OSCAL.
  • 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,Inventory

    converted
    • Convert directly from spreadsheet.
    • Non-normalized. No corrisponding components.
      • system-implementation:
        • inventory-items: All inventory converted from Excel spreadsheet

    ---

    INTERMEDIATE

    • Required attachmentsAttachments

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

    • Required SSP rolesRoles

      • 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 typesTypes

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

    • leveragedLeveraged authorizationsAuthorizations

      • 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

    ---

    ADAVANCED

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

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

    • externalExternal systemsSystems and servicesServices

      • system-implementation/components entries for each

    • Transition to resources

      • Where practical, links entries use URI fragments in links to reference resources instead of direct links. See [section citation and link] for more information.

    • Components for Required Documents

      • policy components entriesOne for each required policydocument (policies, procedures, plans, user guides, Rules of Behavior)
      • See process-procedure[Section citation and link] components entries for eachmore required process
      • plan components entries for each required plan
      • _useradd components for policies, processes, plans and other documentsinformation.

    ---

    TARGET

    • 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.

    ---