Skip to main content

Adoption Strategy

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 Path

    Minimum Viable Product (MVP)

    • ExtremeMinimum MVPFront-Matter and OSCAL-required Content.

      • Metadatametadata includesincludes:
        • title, published, last-modified, version, oscal-version
        • roles: CSP, ISSO, others as cited in controls
        • parties: the CSP
        • responsible-party: only one, linking the CSP party to the CSP role and party
        • OSCAL syntax minimum necessary system information
          • paste App K table into a single information-types entry
          • Link directly to architecture, network and data flow diagrams
          • plus service-model, deployment-model
        • Only a this-systemsystem-characteristics component
        • Control Responses (representing 90% of legacy SSP content)includes:
          • All responses atsystem-id, this-systemsystem-name, componentsystem-name-short, description
          • Onlycloud-service-model responsible-rolesprop and cloud-deployment-model prop
          • security-sensitivity-level (fips-199-high, fips-199-moderate, fips-199-low)
          • system-information: only a single 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 childlonger required by FedRAMP.
            • Single authorized-privilegesentry with emptytitleandfunction-performed` set to "none"
          • this-system party-uuidscomponents entry

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

        • convertcontrol-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 excelWord fileSSP and/or(part begina, generatingpart inventoryb, asetc.)
                  • OSCAL
                • implementation-status
                • responsible-roles: One entry per role. Use inventory-itemsrole-id. Must match metadata/roles/id.

      • Architecture,Flat network,Inventory, dataconverted flowdirectly diagramsfrom spreadsheet. No corrisponding components.

        • addsystem-implementation: links
          • 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:

          Thethe followingpeople, inteams anyand order:

          organizations
            responsible
          • Informationfor typesthe above roles
          • leveragedmetadata/responsible-parties: authorizations
            • links
          • externalthe systemsabove roles and services
          • Separation of Duties Matrixparties

        • 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: (dependsTransition onflat "Addinventory Flatto Inventory")component-based [MAJOR TRANSITION POINT]inventory.

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

        • Theexternal followingsystems inand any order:services

          • Services,system-implementation/components Portsentries andfor Protocols (depends on normalized inventory)
          • Cryptographic Modules (App Q table) (depends on nornalized inventory)each

        • Transition to resources

          • all attachments are represented as resources
          • links use URI fragments to reference resources instead of direct links where practical

        • Components for Required Documents

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

        • EvolvingServices, Ports and Protocols

        • Cryptographic Modules (App Q table)

        • Move to component-based control responses (depends on "Normalize Inventory" and "Components for Documents")

          • within implemented-requirements add by-components entries for each relevant component
          • add/move component-specific control responses to their associated by-components response.

        • Customer Responsibility and Inheritence:

          • Move customer responibility statements to //by-components/export/responsibilities
Back to top