CAM OSCAL

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CAM OSCAL

    The CAM OSCAL integration supports the Open Security Controls Assessment Language (OSCAL) version 1.1.2, a standardized, machine-readable format developed by NIST to automate security control assessments, compliance reporting, and risk management processes. CAM exclusively supports the JSON format for OSCAL data and enables ServiceNow customers to import and export security control information efficiently across Catalog and System Security Plan (SSP) models.

    Show full answer Show less

    Supported OSCAL Models

    • Catalog Model: Provides structured, machine-readable catalogs of controls, including control objectives mapped to NIST controls, control objective requirements, test templates, and assessment procedures. It also supports overlay catalogs, which include additional policies not part of NIST but usable in authorization packages.
    • Profile Model: Represents baselines of selected controls from catalogs, auto-populated based on impact determined by the information type of an authorization package. Profiles include baseline controls marked as included or excluded (Not Applicable) and consist of both catalog and overlay controls.
    • System Security Plan (SSP) Model: Expresses the system implementation of controls within a specific baseline or profile context. Key concepts include the authorization boundary (scope of system management), authorization packages (aligned with NIST RMF steps), information types (impact levels), and control states such as implemented, inherited, or hybrid controls.

    Practical Use for ServiceNow Customers

    CAM’s support for OSCAL enables ServiceNow customers to:

    • Automate the exchange of control-related information in a consistent, standardized format that aligns with NIST requirements.
    • Import OSCAL Catalog and SSP data to streamline integration and reduce manual input, ensuring up-to-date and accurate security control documentation.
    • Export CAM data as OSCAL to support external compliance reporting, audits, and risk management activities.
    • Leverage custom namespaces to include CAM-specific details such as impact and tailored content within OSCAL data.

    Key Benefits

    • Improved interoperability and collaboration through standardized control data formats.
    • Enhanced automation of security control assessments and compliance workflows.
    • Consistent and accurate representation of controls across catalogs, profiles, and system security plans.
    • Support for complex control inheritance scenarios including inherited and hybrid controls within authorization packages.

    Open Security Controls Assessment Language (OSCAL) provides a standardized way to express control-related information, enabling interoperability, consistency, and automation in IT security. It supports the JSON format only. CAM supports OSCAL version 1.1.2.

    OSCAL is a set of machine-readable formats developed by the National Institute of Standards and Technology (NIST). It’s designed to support the automation of security control assessments, compliance reporting, and risk management processes.

    CAM supports the export and import of OSCAL data for both Catalog and System Security Plan (SSP) models.

    CAM supported OSCAL models

    CAM OSCAL supports the following models:
    Catalog
    According to NIST, the catalog model provides a structured, machine-readable representation of a catalog of controls. Therefore, as part of the catalog model, using CAM you can get the following control-related information:
    • Control objectives: These are mapped to controls. The Reference field in a control objective maps to the NIST control. The requirements of a control objective map to the statements of the NIST's control. Therefore, each part of the Description field in a control objective align with the sub-part of the NIST's control. The child control objectives of each control objective are mapped to the control field. Related control objectives of the control objective are mapped to the links field.
    • Control objective requirements: Statements or control requirements that are further broken down from a control objective's description.
    • Test templates: Tests done on controls. Each control has at least one test template, which has one assessment objective.
    • Assessment Procedures: These are assessment objectives of a test template or the tests done on controls.
    Overlay catalog
    Overlay controls: These are policies that consist of control objectives and are not part of NIST but can be in an authorization package.
    Profile
    According to NIST, the profile model provides a structured, machine-readable representation of a baseline. The profile model also represents a baseline of selected controls from one or more control catalogs.

    Baseline controls: Small set of control objectives that are auto-populated based on the impact. Impact is decided based on the Information Type of an authorization package.

    • Include-controls: These are baseline controls, which are part of the authorization package.
    • Exclude-controls: These are baseline controls that have been marked as Not Applicable.

    Profile consists of both Catalog and Overlay Catalog.

    System Security Plan (SSP)
    According to NIST, OSCAL SSP model enables a system owner to express the system implementation of an information system within the context of a specific baseline or OSCAL profile. Or, it represents a description of the control implementation of an information system.
    • Authorization boundary: An authorization boundary defines the scope of a particular system that can be continuously managed and monitored using the CAM application.
    • Authorization package: Created for the purpose of processing the assets or systems through the seven steps mandated by the RMF. For more information, see NIST RMF process overview.
    • Information type: Information type defines the impact level of the package, which is based on the criticality of the information system defined in the Categorize step.
    • Control: When control objectives move to Implementation state, they become controls.
    • Control requirement: When control objectives move to Implementation state, they become controls. Correspondingly, the control objective requirements convert to control requirement.
    • Inherited Control: Controls that are entirely inherited from parent authorization package. Then, it means that all the control requirements of each such control are also inherited completely.
    • Hybrid Control: These are partially inherited from the parent authorization package.