### Implicit Binding Example: Add Prop at Starting Position Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html This example demonstrates an 'add' directive with implicit binding and the 'starting' position. It shows how a new 'prop' is added to the control. Despite the 'starting' position, the new 'prop' is placed after the existing 'prop' to maintain the required OSCAL content order (props must appear before parts). ```yaml control: id: a1 title: Basic precautions props: - name: status value: ready alter: control-id: a1 add: position: starting props: - name: basis value: enumerated parts: - name: caution prose: "\n\nPending scheduled testing." control: id: a1 title: Basic precautions props: - name: basis value: enumerated - name: status value: ready parts: - name: caution prose: "\n\nPending scheduled testing." ``` -------------------------------- ### OSCAL System Security Plan Example in JSON and YAML Source: https://context7.com/alex-kopylov/oscal-pages/llms.txt Provides an example of an OSCAL System Security Plan (SSP) in both JSON and YAML formats. This demonstrates the interchangeable nature of these formats within OSCAL, allowing for data to be represented and converted losslessly between them. ```json { "system-security-plan": { "uuid": "cff8385f-108e-40a5-8f7a-82f3dc0eaba8", "metadata": { "title": "Enterprise System Security Plan", "last-modified": "2025-01-15T14:20:00Z", "version": "1.2", "oscal-version": "1.0.4", "roles": [ { "id": "admin", "title": "System Administrator", "description": "Responsible for system configuration and maintenance" } ] }, "import-profile": { "href": "https://example.gov/profiles/moderate-baseline.json" }, "system-characteristics": { "system-ids": [ { "identifier-type": "https://fedramp.gov", "id": "F00000001" } ], "system-name": "Enterprise Resource Planning System", "description": "Core ERP system for financial and HR operations", "security-sensitivity-level": "moderate", "system-information": { "information-types": [ { "uuid": "7d28ac6e-5970-4f4c-a508-5a967abc123e", "title": "Financial Data", "categorizations": [ { "system": "https://doi.org/10.6028/NIST.SP.800-60v2r1", "information-type-ids": ["C.3.5.1"] } ] } ] } }, "control-implementation": { "description": "Control implementation for the ERP system", "implemented-requirements": [ { "uuid": "8d5d856f-1b04-4f8e-9f72-d7c6c8c0b0d1", "control-id": "ac-1", "statements": [ { "statement-id": "ac-1_smt", "uuid": "9e6e967a-2c15-5f9f-a083-e8d7d9d1c1e2", "description": "Access control policies are documented in the IT Security Policy Manual and reviewed annually." } ] } ] } } } ``` ```yaml # Equivalent YAML representation system-security-plan: uuid: cff8385f-108e-40a5-8f7a-82f3dc0eaba8 metadata: title: Enterprise System Security Plan last-modified: 2025-01-15T14:20:00Z version: '1.2' oscal-version: 1.0.4 roles: - id: admin title: System Administrator description: Responsible for system configuration and maintenance import-profile: href: https://example.gov/profiles/moderate-baseline.json system-characteristics: system-ids: - identifier-type: https://fedramp.gov id: F00000001 system-name: Enterprise Resource Planning System description: Core ERP system for financial and HR operations security-sensitivity-level: moderate ``` -------------------------------- ### Example Resolved OSCAL Catalog (XML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/control/basic-profile/index.html This is an example of a resolved OSCAL catalog in XML format, generated after profile resolution. It includes metadata and control definitions, showcasing the structure and content of a resolved catalog. This output is produced by the oscal-cli profile resolve command. ```xml Sample Security Profile <em>for Demonstration</em> and Testing 2023-05-13T22:06:43.017554394Z 1.0 1.0.4 Information security roles and responsibilities

All information security responsibilities should be defined and allocated.

A value has been assigned to .

A cross link has been established with a choppy syntax: (choppy).

Allocation of information security responsibilities should be done in accordance with the information security policies. Responsibilities for the protection of individual assets and for carrying out specific information security processes should be identified. Responsibilities for information security risk management activities and in particular for acceptance of residual risks should be defined. These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Local responsibilities for the protection of assets and for carrying out specific security processes should be defined.

Individuals with allocated information security responsibilities may delegate security tasks to others. Nevertheless they remain accountable and should determine that any delegated tasks have been correctly performed.

 ``` -------------------------------- ### OSCAL Profile Import Structure Example Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html Demonstrates the basic structure of an OSCAL Profile's import section, specifying how to include controls from catalog or profile resources using 'include-controls' or 'include-all'. This structure is fundamental for initiating the profile resolution process. ```yaml profile: uuid: ~ metadata: ~ imports: - href: "${{ catalog URI }}" include-controls: ${{ list of selected controls }} - href: "${{ profile URI }}" include-controls: ${{ list of selected controls }} ``` -------------------------------- ### Documenting Control Implementation in JSON - OSCAL Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This JSON snippet illustrates the equivalent structure for documenting control implementations within an OSCAL component definition as the XML example. It shows how to represent the component, its control implementations, and the details of how it satisfies specific controls. This format is useful for automated processing and data exchange. ```json { "component-definition": { "uuid": "a7ba800c-a432-44cd-9075-0862cd66da6b", "components": [{ "uuid": "91f646c5-b1b6-4786-9ec3-2305a044e217", "type": "software", "control-implementations": [{ "uuid": "49f0b690-ed9f-4f32-aae0-625b77aa6d27", "source": "https://github.com/usnistgov/oscal-content/blob/master/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_MODERATE-baseline_profile.json" }] }] } } ``` -------------------------------- ### Profile Importing Another Profile (XML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html Example of a profile importing another profile using XML syntax. The 'href' attribute specifies the resource to import. This structure is analogous to the YAML example and can also lead to circular imports. ```xml profile: id: "circular_profile.yaml" metadata: ~ imports: - href: "home_profile.yaml" include-controls: ${{ list of selected controls }} ``` -------------------------------- ### OSCAL Profile Import with Internal Reference Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html Example of an OSCAL profile snippet demonstrating how to import a catalog using an internal reference ('#nist-sp800-53_catalog') to a resource defined in the 'backmatter'. This showcases the mechanism for linking to local resources within an OSCAL document. ```yaml profile: metadata: ~ imports: - href: "#nist-sp800-53_catalog" include-controls: ${{ list of selected controls }} # Content Elided backmatter: resources: - uuid: "nist-sp800-53_catalog" description: "NIST SP 800-53 rev5 OSCAL format, on Github." rlinks: - rlink: href: >- https://github.com/usnistgov/oscal-content/tree /master/nist.gov/SP800-53/rev4/xml/NIST_SP-800-53_rev5_catalog.xml ``` -------------------------------- ### Clone OSCAL Content Repositories (Bash) Source: https://context7.com/alex-kopylov/oscal-pages/llms.txt These Bash commands demonstrate how to clone the official NIST OSCAL content repository and the OSCAL Club community examples repository. These repositories provide a wealth of examples for various OSCAL content types. ```bash # Official NIST OSCAL content repository # https://github.com/usnistgov/oscal-content git clone https://github.com/usnistgov/oscal-content.git cd oscal-content/examples # Available example categories: examples/ ├── catalog/ # Control catalog examples ├── profile/ # Baseline profile examples ├── component-definition/ # Component implementation examples ├── ssp/ # System security plan examples └── assessment-plan/ # Assessment planning examples └── assessment-results/ # Assessment finding examples # Community examples from OSCAL Club # https://github.com/oscal-club/examples git clone https://github.com/oscal-club/examples.git # Awesome OSCAL - curated tool list # https://github.com/oscal-club/awesome-oscal # Includes: # - Commercial and open-source tools # - Libraries and frameworks # - Validation utilities # - Content converters ``` -------------------------------- ### OSCAL Catalog Root Structure Example Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/control/basic-catalog/index.html This example illustrates the basic structure of an OSCAL catalog in YAML format. It shows the root 'catalog' key with optional fields like 'metadata', 'groups', 'controls', and 'back-matter' initialized as empty collections. The 'id' key, a universally unique identifier (UUID), is also highlighted. ```yaml catalog: uuid: 956c32af-8a15-4732-a4d9-f976a1149c4b metadata: groups: controls: back-matter: ``` -------------------------------- ### OSCAL Back Matter Resource Example Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/layer/control/catalog/sp800-53rev5-example/index.html Shows an example of a `` element within OSCAL's back matter, used to define bibliographic entries. This element contains a title and citation details for a reference, which can then be linked to from control elements. ```xml OMB A-130 Office of Management and Budget Memorandum Circular A-130, Managing Information as a Strategic Resource , July 2016. ``` -------------------------------- ### MongoDB Control Implementation Example Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This snippet details the control implementation for MongoDB, referencing NIST SP 800-53 revision 5. It includes a specific requirement (sc-8.1) for TLS encryption and instructions on how to configure it. ```json { "uuid": "49f0b690-ed9f-4f32-aae0-625b77aa6d27", "source": "", "description": ">- MongoDB control implementations for NIST SP 800-53rev5.", "implemented-requirements": [ { "uuid": "cf8338c5-fb6e-4593-a4a8-b3c4946ee2a0", "control-id": "sc-8.1", "description": ">- MongoDB supports TLS 1.x to encrypt data in transit, preventing unauthorized disclosure or changes to information during transmission. To implement TLS, set the PEMKeyFile option in the configuration file /etc/mongod.conf to the certificate file's path and restart the the component. } ] } ``` -------------------------------- ### Component Definition Metadata in JSON Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This JSON example demonstrates the structure for defining metadata within an OSCAL component definition. It specifies the component's UUID, metadata including title, timestamps, versioning, and structured data for roles and parties. ```json { "component-definition": { "uuid": "a7ba800c-a432-44cd-9075-0862cd66da6b", "metadata": { "title": "MongoDB Component Definition Example", "last-modified": "2001-12-17T09:30:47Z", "version": 20210507, "oscal-version": "1.0.0", "roles": [{ "id": "provider", "title": "Provider" }], "parties": [{ "uuid": "ef7c799a-c50e-49ab-83e0-515e989e6df1", "type": "organization", "name": "MongoDB", "links": [{ "href": "https://www.mongodb.com", "rel": "website" }] }] } } } ``` -------------------------------- ### Profile Importing Another Profile (YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html Example of a profile importing another profile using YAML syntax. The 'href' attribute specifies the resource to import. This can lead to circular imports if not managed carefully. ```yaml profile: id: "home_profile.yaml" metadata: ~ imports: - href: "circular_profile.yaml" include-controls: ${{ list of selected controls }} ``` -------------------------------- ### Structure of Control s1.1.1 (JSON) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/control/basic-profile/index.html This JSON snippet shows the structure of control 's1.1.1', including its 'parts' array. This is illustrative of how content might be represented in JSON, complementing the XML examples for the 'alter' directive. ```json { "id": "s1.1.1", "title": "Information security roles and responsibilities", // Omitting non-relevant params, props, and parts for brevity "parts": [ { ``` -------------------------------- ### Component Definition Metadata in YAML Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This YAML snippet provides an example of defining metadata for an OSCAL component definition. It outlines the essential metadata fields such as title, modification details, versioning, and nested structures for roles and parties. ```yaml --- component-definition: uuid: a7ba800c-a432-44cd-9075-0862cd66da6b metadata: title: MongoDB Component Definition Example last-modified: '2001-12-17T09:30:47Z' version: 20210507 oscal-version: 1.0.0 roles: - id: provider title: Provider parties: - uuid: ef7c799a-c50e-49ab-83e0-515e989e6df1 type: organization name: MongoDB ``` -------------------------------- ### Multiple Imports in a Profile (YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html Demonstrates how a single profile can import the same catalog multiple times with different control selections. Each import directive results in a separate set of controls, which are later merged. ```yaml profile: uuid: ~ metadata: ~ imports: - href: "#catalog" include-controls: - with-ids: - ac-1 - ac-2 - href: "#catalog" include-controls: - with-ids: - ac-3 - ac-4 ``` -------------------------------- ### Control ID Mapping Example in OSCAL Profile Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html This YAML snippet demonstrates how to use the 'mapping' directive within an 'import' to remap control IDs. It shows how to specify 'from' and 'to' IDs for controls to avoid collisions when importing from different catalogs. Processors must apply these mappings and update all references to the old IDs. ```YAML profile: uuid: ~ metadata: ~ imports: - href: "#catalog" include-controls: - with-ids: - ac-1 - ac-2 - href: "#catalog2" include-controls: - with-ids: - ac-1 - ac-2 mapping: - controls: - from: ac-1 to: map-ac-1 - from: ac-2 to: map-ac-2 ``` -------------------------------- ### OSCAL Catalog Metadata Example (YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/general/metadata/index.html This snippet presents the same OSCAL catalog metadata as the JSON example, but in YAML format. YAML's human-readable syntax makes it a convenient alternative for representing structured data like OSCAL metadata, simplifying configuration and data entry. ```yaml --- catalog: uuid: c3da6d1d-c20c-4c7c-ae73-4010167a186b metadata: title: Example OSCAL Catalog published: 2021-01-01T00:00:00-5:00 last-modified: 2021-01-05T00:00:00-5:00 version: 1.0.0 oscal-version: 1.0.4 document-ids: - scheme: http://www.doi.org/ value: 10.1000/182 props: - name: marking value: red class: http://www.first.org/tlp links: - rel: latest-version href: https://www.example.com/catalog/example-oscal-catalog/latest parties: - uuid: 15d2e37c-0452-4695-9c6a-ddc1ff15397b type: organization name: Example Company responsible-parties: - role-id: prepared-by party-uuid: 15d2e37c-0452-4695-9c6a-ddc1ff15397b ``` -------------------------------- ### OSCAL Property Definition (YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/general/extension/index.html Example of defining properties in YAML format, showcasing the use of 'name', 'value', 'ns' (namespace), and 'class' attributes to provide context and meaning to properties like 'glc'. This demonstrates extending OSCAL data items. ```yaml system-security-plan: uuid: ce16b9af-6853-4abe-9e27-b79d034c0adc metadata: title: OSCAL Basic Prop Example last-modified: '2022-01-01T09:30:00-005' version: 20220531 oscal-version: 1.0.0 locations: - title: ... props: - name: type value: security-operations-center class: regional - name: glc ns: http://example.com/ns/oscal value: '11' class: state-code - name: glc ns: http://example.com/ns/oscal value: '0010' class: city-code - name: glc ns: http://example.com/ns/oscal value: '840' class: country-code import-profile: ... system-characteristics: ... system-implementation: ... ``` -------------------------------- ### Resolve OSCAL Profiles using oscal-cli Source: https://context7.com/alex-kopylov/oscal-pages/llms.txt Provides a command-line example using 'oscal-cli' to resolve an OSCAL profile into a complete catalog. This process applies selected controls, modified parameters, and added elements from the profile to the referenced catalog, generating a ready-to-use artifact. ```bash # Resolve profile to generate complete catalog oscal-cli profile resolve \ --to=json \ custom-moderate-baseline.json \ resolved-catalog.json # The resolved catalog contains: # - Selected controls from source catalog # - Applied parameter settings # - Modifications and additions # - Ready for use in SSP or component definition ``` -------------------------------- ### XML Component Definition Example for MongoDB Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This XML snippet represents a complete OSCAL Component Definition for the MongoDB software. It includes metadata like title, last-modified date, version, and OSCAL version, as well as details about the component itself, such as its UUID, title, description, and purpose. ```xml MongoDB Component Definition Example 2001-08-26T23:11:47Z 20210826 1.0.0 Provider MongoDB MongoDB

MongoDB is a source-available, cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with optional schemas.

 Provides a NoSQL database service ``` -------------------------------- ### Include Controls by Specific IDs in OSCAL Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html This YAML example illustrates how to include specific controls from an imported catalog using the 'include-controls' directive with a 'with-ids' child. It specifies a list of control IDs that should be fetched and processed. This method is precise for selecting known controls. ```YAML include-controls: - with-ids: - id: ac-1 - id: ac-2 ``` -------------------------------- ### MongoDB Component Protocol Definitions Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This snippet defines the protocols used by the MongoDB component. It includes the primary daemon process (mongodb), sharding protocol (mongodb-shardsrv), and configuration server protocol (mongodb-configsvr), specifying their respective TCP port ranges. ```json { "uuid": "91f646c5-b1b6-4786-9ec3-2305a044e217", "type": "software", "title": "MongoDB", "description": ">- MongoDB is a source-available, cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with optional schemas. ", "purpose": "Provides a NoSQL database service", "responsible-roles": [ { "role-id": "provider", "party-uuid": "ef7c799a-c50e-49ab-83e0-515e989e6df1" } ], "protocols": [ { "uuid": "2b4a1b3a-cbc5-4cc8-bde6-7437c28c4e54", "name": "mongodb", "title": "Primary daemon process for the MongoDB system.", "port-ranges": [ { "start": 27017, "end": 27017, "transport": "TCP" } ] }, { "uuid": "99d8d4e5-e734-4e05-a2f9-7353097b8b61", "name": "mongodb-shardsrv", "title": "MongoDB protocol for sharding with shardsrv option.", "port-ranges": [ { "start": 27018, "end": 27018, "transport": "TCP" } ] }, { "uuid": "6fa762f1-09ca-44d5-a94c-cfceb57debd5", "name": "mongodb-configsvr", "title": "MongoDB protocol for configsrv operation.", "port-ranges": [ { "start": 27019, "end": 27019, "transport": "TCP" } ] } ] } ``` -------------------------------- ### OSCAL Component Definition Structure (YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This snippet illustrates the basic structure of an OSCAL component definition in YAML format. It highlights the root 'component-definition' object and its primary properties, including 'uuid', 'metadata', and other optional sections. ```yaml component-definition: uuid: a7ba800c-a432-44cd-9075-0862cd66da6b metadata: ~ import-component-definitions: ~ components: ~ capabilities: ~ back-matter: ~ ``` -------------------------------- ### OSCAL Control Properties Example Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/layer/control/catalog/sp800-53rev5-example/index.html Demonstrates the use of `` elements to define properties for an OSCAL control. Properties represent name-value pairs that provide additional metadata about the control, such as labels and sorting identifiers. The `class` attribute can be used for further qualification. ```xml ``` -------------------------------- ### OSCAL Control Links Example Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/layer/control/catalog/sp800-53rev5-example/index.html Illustrates how `` elements are used to associate external resources or related controls with an OSCAL control. The `rel` attribute specifies the type of relationship (e.g., 'reference' for bibliographic citations, 'related' for other controls), and `href` points to the target resource. ```xml ``` -------------------------------- ### OSCAL Property Extension Example (XML, JSON, YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/layer/overview/index.html Demonstrates how an OSCAL property can be extended with an organizational namespace ('ns') and a specific name, shown in XML, JSON, and YAML formats. This allows for custom organizational data within OSCAL models. ```xml fedramp-defined-status ``` ```json { "properties": [ { "name": "status", "ns": "https://fedramp.gov/ns/oscal", "value": "fedramp-defined-status" } ] } ``` ```yaml properties: - name: status ns: https://fedramp.gov/ns/oscal value: fedramp-defined-status ``` -------------------------------- ### OSCAL CLI for Validation and Conversion (Bash) Source: https://context7.com/alex-kopylov/oscal-pages/llms.txt This snippet shows common commands for the OSCAL CLI tool, used for validating and converting OSCAL content. It covers validating XML catalogs, converting between XML, JSON, and YAML formats, and resolving profiles. Ensure oscal-cli is installed and accessible in your PATH. ```bash # Validate XML catalog against schema oscal-cli catalog validate catalog.xml # Convert XML to JSON oscal-cli catalog convert --to=json catalog.xml catalog.json # Convert JSON to YAML oscal-cli catalog convert --to=yaml catalog.json catalog.yaml # Resolve a profile to generate a complete catalog oscal-cli profile resolve --to=json profile.json resolved-catalog.json ``` -------------------------------- ### OSCAL Link Example (YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/general/metadata/index.html Shows how to represent a 'latest-version' link in YAML format for OSCAL. The 'links' list includes items with 'rel' to define the relationship and 'href' for the resource's URI. ```yaml links: - rel: latest-version href: https://www.example.com/catalog/example-oscal-catalog/latest ``` -------------------------------- ### OSCAL Catalog Metadata Example (JSON) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/general/metadata/index.html This snippet shows an example of the metadata section within an OSCAL catalog in JSON format. It includes essential fields like UUID, title, dates, version, document identifiers, properties, links, parties, and responsible parties. This structure is crucial for identifying and managing OSCAL documents. ```json { "catalog": { "uuid": "c3da6d1d-c20c-4c7c-ae73-4010167a186b", "metadata": { "title": "Example OSCAL Catalog", "published": "2021-01-01T00:00:00-5:00", "last-modified": "2021-01-05T00:00:00-5:00", "version": "1.0.0", "oscal-version": "1.0.4", "document-ids": [ { "scheme": "http://www.doi.org/", "value": "10.1000/182" } ], "props": [ { "name": "marking", "value": "red", "class": "http://www.first.org/tlp" } ], "links": [ { "rel": "latest-version", "href": "https://www.example.com/catalog/example-oscal-catalog/latest" } ], "parties": [ { "uuid": "15d2e37c-0452-4695-9c6a-ddc1ff15397b", "type": "organization", "name": "Example Company" } ], "responsible-parties": [ { "role-id": "prepared-by", "party-uuid": "15d2e37c-0452-4695-9c6a-ddc1ff15397b" } ] } } } ``` -------------------------------- ### OSCAL Link Example (JSON) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/general/metadata/index.html Demonstrates the structure for a 'latest-version' link in JSON format for OSCAL. The 'links' array contains objects, each with 'rel' for the relationship type and 'href' for the resource URI. ```json { "links": [ { "rel": "latest-version", "href": "https://www.example.com/catalog/example-oscal-catalog/latest" } ] } ``` -------------------------------- ### Include All Controls in OSCAL Import Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html Demonstrates the use of the 'include-all' directive within an OSCAL import. When present, this directive instructs the processor to include ALL controls and nested groups from the referenced document. This is a broad inclusion strategy. ```YAML include-all: ~ ``` -------------------------------- ### OSCAL Control Definition with Parts Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/concepts/processing/profile-resolution/index.html This snippet defines a basic OSCAL control with an ID, title, properties, and nested parts. The 'parts' are further broken down into sub-parts, demonstrating a hierarchical structure within a control. This serves as the target for an 'add' directive. ```yaml control: id: a1 title: Basic precautions props: - name: status value: ready parts: - name: recommendations id: a1.b parts: - name: task1 id: a1.b1 prose: Collect recycling for pickup - name: task2 id: a1.b2 prose: Sweep surfaces free of dust ``` -------------------------------- ### OSCAL Component Definition for MongoDB Control Implementations (YAML) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This YAML snippet demonstrates the OSCAL component definition structure for documenting MongoDB's implementation of NIST SP 800-53 revision 5 controls. It includes component details, control implementations, and specific requirement mappings. ```yaml component-definition: uuid: a7ba800c-a432-44cd-9075-0862cd66da6b, components: - uuid: 91f646c5-b1b6-4786-9ec3-2305a044e217 type: software control-implementations: - uuid: 49f0b690-ed9f-4f32-aae0-625b77aa6d27 source: description: >- MongoDB control implementations for NIST SP 800-53rev5. implemented-requirements: - uuid: cf8338c5-fb6e-4593-a4a8-b3c4946ee2a0 control-id: sc-8.1 description: >- MongoDB supports TLS 1.x to encrypt data in transit, preventing unauthorized disclosure or changes to information during transmission. To implement TLS, set the PEMKeyFile option in the configuration file /etc/mongod.conf to the certificate file's path and restart the the component. ``` -------------------------------- ### Documenting Control Implementation in XML - OSCAL Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This XML snippet demonstrates how to define control implementations within an OSCAL component definition. It specifies how a software component satisfies a particular control (SC-8.1) by referencing a source profile and providing a detailed description of the implementation. The structure includes unique identifiers for the component, control implementation, and implemented requirement. ```xml

MongoDB control implementations for NIST SP 800-53 revision 5.

MongoDB supports TLS 1.x to encrypt data in transit, preventing unauthorized disclosure or changes to information during transmission. To implement TLS, set the PEMKeyFile option in the configuration /etc/mongod.conf to the certificate file's path and restart the the component.

 ``` -------------------------------- ### Reference Back-Matter Resource with Link (JSON) Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/general/extension/index.html This JSON example demonstrates referencing back-matter resources. A 'links' object with an 'href' pointing to a UUID fragment is used in metadata to reference a 'resource' within 'back-matter'. The 'resource' object contains 'rlinks' arrays with 'href' attributes for external content. ```json { "system-security-plan": { "uuid": "ce16b9af-6853-4abe-9e27-b79d034c0adc", "metadata": { "title": "OSCAL SSP Link to Back Matter Resource Example", "last-modified": "2022-01-01T09:30:00-005", "version": 20220531, "oscal-version": "1.0.0", "links": { "href": "#a7584118-3d2d-46c8-b388-df747309c0fa", "rel": "reference", "text": "Applicable Laws and Regulations, Standards, and Guides" } }, "import-profile": "...", "system-characteristics": "...", "control-implementation": "...", "back-matter": { "resources": { "uuid": "a7584118-3d2d-46c8-b388-df747309c0fa", "rlinks": [ { "href": "https://www.dhs.gov/homeland-security-presidential-directive-12" }, { "href": "https://csrc.nist.gov/csrc/media/publications/fips/199/final/documents/fips-pub-199-final.pdf", "media-type": "application/pdf" }, { "href": "/security/standards/IT-Rules-of-Behavior.docx", "media-type": "application/msword" }] } } } } ``` -------------------------------- ### OSCAL Component Definition JSON Structure Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This snippet illustrates the fundamental JSON structure for an OSCAL component definition. It mirrors the XML structure with a root object containing 'component-definition', which includes properties for 'uuid', 'metadata', 'import-component-definitions', 'components', 'capabilities', and 'back-matter'. ```json { "component-definition": { "uuid": "a7ba800c-a432-44cd-9075-0862cd66da6b", "metadata": {}, "import-component-definitions": [{}], "components": [{}], "capabilities": [{}], "back-matter": {} } } ``` -------------------------------- ### Component Definition Metadata in XML Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This XML snippet illustrates how to define metadata for an OSCAL component definition. It includes title, last-modified date, version, OSCAL version, and details about roles and parties involved in the component definition. ```xml MongoDB Component Definition Example 2001-08-26T23:11:47Z 20210826 1.0.0 Provider MongoDB ``` -------------------------------- ### Define Component Protocols in XML Source: https://github.com/alex-kopylov/oscal-pages/blob/published-pages/learn/tutorials/implementation/simple-component-definition/index.html This XML snippet demonstrates how to define network protocols and their associated port ranges for a component. It specifies details like UUID, name, title, port numbers, and transport protocols (e.g., TCP) for a MongoDB service. ```xml MongoDB Primary daemon process for the MongoDB system. MongoDB protocol for sharding with shardsrv option. MongoDB protocol for configsrv operation. ```