Skip to main content

New Adoption Path

If you are approaching OSCAL to intially create your system security plan and do not have legacy documentaiton to convert, follow this path.

If you need to convert legacy documentation to OSCAL, follow the Retrofit Adoption path.

Organizations seekingadopting OSCAL for initial SSP creation must be mindful of OSCAL's relational dependencies to createensure aefficient newcontent authorizationpopulation. packageThe shouldNew beginAdoption theirPath OSCAL adoption journeystarts with OSCALcomponents and other core system details, then builds on those components in later phases to achieve highly normalized and iteratecomplete withSSP additionalcontent.

detail

This overapproach time.prioritzes data normalization from the start. It establishes foundational data elements on which later phases build. This ensures logical sequencing of activties and efficient progression of SSP detail.

SSP New Adoption Overview

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

[INSERT DIAGRAM HERE]

CORE

  • Minimum Information Required in an OSCAL SSP

    • metadata includes:

      • title, last-modified, version, oscal-version (required OSCAL fields)

    • system-characteristics includes:

      • system-id, system-name, system-name-short, description

  • Focus on Defining Components

    • system-implementation
      • components:
        • Exactly one "this system" component (type= this-system) (Represents the system as a whole.)
        • One for each technical component (hardware, software, virtual appliance, service) used in the system
        • One for each required document (policies, procedures, plans, user guides, Rules of Behavior)
        • See [Section citation and link] for more information.

Technical Component Granularity

In the Core phase, a technical component should be defined in an OSCAL SSP's components if it has:

  • control relevance; and / or
  • vulnerability management relevance.

More advanced use of OSCAL components will be addressed in later phases.

Examples of technical components include, operating systems, container images, applications, cloud native services, databases, identity management capabilities, routers, switches, and firewalls.

Control Relevance

Where a control's imiplementation is likely to be discussed relative to specific technical components, the cited component must be defined in an OSCAL SSP's components.

Vulnerability Management Relevance

Where a technical component is subject to vulnerability management or discovery scans it must be defined in an OSCAL SSP's components.

DETAILS

  • Required SSP Roles

  • Information Types / FIPS-199 Categorization

  • Leveraged Authorizations and External Services (needed for Controls below.)

    • system-implementation includes:
      • users: Required by OSCAL, but no longer required by FedRAMP.
        • Single authorized-privilegesentry with emptytitleandfunction-performed` set to "none"

  • Minimum Front-Matter and OSCAL-required Content.

    • metadata includes:
      • title, published, last-modified, version, oscal-version

      • roles: CSP,Core ISSO,set othersof asrolls citedwith inrole controlsIDs that align with required FedRAMP SSP roles (See [section name and link])

      • parties: One for the CSPCSP, and additional for the individuals and teams/organizations that need to be assigned to FedRAMP-required roles.

      • responsible-partyparties: one for each FedRAMP-required role. Each responsible-parties links roles to parties.

      • system-information: exactly one,one linkingentry with Appendix K pasted into the CSP party to the CSP role

      description

    • status: Required field. Use as-is

    • authorization-boundary: description and links entry identifying the external attachment.

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

  • **

  • Components

    • this-system (Core OSCAL Mandatory)
    • technical components. Appropriate level of granularity for:
      • SSP control responses: If you need to reference an element of the system in a control response, there should be a defined OSCAL component.
      • normalizing inventory reporting: for any item appearing in the inventory, details about its vendor, product/service name, version or other details should be a defined component.
    • Document Components for Policies, Procedures, Plans, RoB, User Guides

DETAILS

  • Required SSP Roles
  • Information Types / FIPS-199 Categorization
  • Leveraged Authorizations and External Services (needed for Controls below.)
  • Cryptographic Module representation

CONTROLS

  • Assign Components
  • Responses at the Component Level
  • Derived from included components:
    • Roles
    • Implementaiton Status
  • Add roles where they are not inherited from cited components
  • Override implementation status only where necessary. Examples:
    • Cited components don't represent all components.
    • Planned upgrades or replacement of components

TARGET

Advanced topics.

  • Cryptographic Module representation

  • 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