Skip to main content

Creating a Profile

This tutorial covers creating and modifying a subset of controls from a catalog in OSCAL by using the OSCAL profile model. Such a subset of controls is often referred to as a "control baseline".

Before reading this tutorial you should:

What is an OSCAL Profile?

An OSCAL profile is a specific set of security controls selected and modified when needed from one or more control catalogs for use in managing risks in an information system. Such a profile is also known as baseline, or overlay in the Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy (NIST SP 800-37 Revision 2).

An OSCAL profile is a machine-readable representation of a baseline, expressed using the OSCAL profile model, which includes contextualizing documentation and metadata. In the most basic sense, an OSCAL profile is a collection of "pointers" to controls from other catalog(s), along with instructions to tailor the controls and change how the controls are grouped.

An OSCAL profile can be transformed into an OSCAL catalog through a process named profile resolution, which is described in the Profile Resolution Specification. The output resolved catalog contains the controls selected, tailored, or (optionally) grouped by the profile.

This tutorial illustrates how to create an OSCAL profile using the OSCAL XML, JSON, and YAML formats, which each implement the OSCAL profile model. The OSCAL project provides an XML Schema and documentation, which is useful for validating an XML profile, and a JSON Schema and documentation, which is useful for validating JSON and YAML profiles.

Creating an OSCAL Profile

The examples below illustrate the top-level structure of the OSCAL profile model.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<?xml version="1.0" encoding="UTF-8"?>
<profile xmlns="http://csrc.nist.gov/ns/oscal/1.0"
    uuid="9510e179-7744-4afa-a9d3-92beadffd85f">
    <!-- To be filled in: -->
    <metadata/>
    <import/>
    <merge/>
    <modify/>
    <back-matter/>
</profile>

The root of the OSCAL profile model is <profile>.

In the example above, the contents of the <profile> element is provided as empty data items. These are included to illustrate the content model of an OSCAL profile, and we will be covering each element's syntax later in this tutorial.

The @uuid attribute (on line 3) is the document's universally unique identifier (UUID), a unique 128-bit number displayed as a string of hyphenated hexadecimal digits as defined by RFC 4122. OSCAL documents use a version 4 UUID (randomly generated) to uniquely identify the document.

A <profile> contains:

  • <metadata> (required) - Provides document metadata for the profile. As OSCAL Metadata sections use a shared structure across all models, refer to the metadata tutorial for more information.
  • <import> (required) - This is explored below in the import phase section of this tutorial.
  • <merge> (optional) - This is explored below in the merge phase section of this tutorial.
  • <modify> (optional) - This is explored below in the modify phase section of this tutorial.
  • <back-matter> (optional) – Contains references used within the profile. Use of <back-matter> is not covered in this tutorial.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "profile": {
    "uuid": "9510e179-7744-4afa-a9d3-92beadffd85f",
    // To be filled in:
    "metadata": {},
    "import": {},
    "merge": {},
    "modify": {},
    "back-matter": {}
  }
}

The root of the OSCAL profile model is profile.

In the example above, the contents of the profile object are provided as empty data items. These are included to illustrate the content model of an OSCAL profile, and we will be covering each element's syntax later in this tutorial.

The uuid property (on line 3) is the document's universally unique identifier (UUID), a unique 128-bit number displayed as a string of hyphenated hexadecimal digits as defined by RFC 4122. OSCAL documents use a version 4 UUID (randomly generated) to uniquely identify the document.

A profile contains:

  • metadata (required) - Provides document metadata for the profile. As OSCAL Metadata sections use a shared structure across all models, refer to the metadata tutorial for more information.
  • import (required) - This is explored below in the import phase section of this tutorial.
  • merge (optional) - This is explored below in the merge phase section of this tutorial.
  • modify (optional) - This is explored below in the modify phase section of this tutorial.
  • back-matter (optional) – Contains references used within the profile. Use of back-matter is not covered in this tutorial.
1
2
3
4
5
6
7
8

profile:
  uuid: "9510e179-7744-4afa-a9d3-92beadffd85f",
  # To be filled in:
  metadata: ~
  import: ~
  merge: ~
  modify: ~
  back-matter: ~

The root of the OSCAL profile model is profile.

In the example above, the contents of the profile object are provided as empty data items. These are included to illustrate the content model of an OSCAL profile, and we will be covering each element's syntax later in this tutorial.

The uuid property (on line 3) is the document's universally unique identifier (UUID), a unique 128-bit number displayed as a string of hyphenated hexadecimal digits as defined by RFC 4122. OSCAL documents use a version 4 UUID (randomly generated) to uniquely identify the document.

A profile contains:

  • metadata (required) - Provides document metadata for the profile. As OSCAL Metadata sections use a shared structure across all models, refer to the metadata tutorial for more information.
  • import (required) - This is explored below in the import phase section of this tutorial.
  • merge (optional) - This is explored below in the merge phase section of this tutorial.
  • modify (optional) - This is explored below in the modify phase section of this tutorial.
  • back-matter (optional) – Contains references used within the profile. Use of back-matter is not covered in this tutorial.

We will now discuss each of these data structures in the following sections and identify how they each can be used to represent our baseline.

The Three Sections (or Phases) of Profiles

OSCAL profiles are broken up into three main sections, each representing a "phase" of operations to be applied to the source catalog(s).

They are:

  • Import: Selects which controls from the source catalog(s) are to be used in the baseline
  • Merge: Defines how to merge objects when importing from multiple catalogs, and defines the structure of the baseline
  • Modify: Defines a list of modifications to make to the imported controls, such as setting parameters or changing values

As this is a basic tutorial, and many baselines are simply a subset of controls pulled from a larger catalog, we will be focusing mainly on the "Import" section, which covers many of the core use cases of OSCAL profiles.

Import Phase

The first major part of an OSCAL profile is the import section. In this section, the source catalog(s) are identified, and the subset of controls to be imported into the resulting catalog are selected.

There will be one import object per catalog referenced, so in the simple case of building a baseline from a single catalog, there will be a single import object. Let's look at a basic example.

For the rest of this tutorial, we'll be using the catalog we created during the last tutorial.

1
2
3
4
5
6
7
8

<import href="https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json">
    <include-controls>
      <matching pattern="s1.1.*"/>
    </include-controls>
    <include-controls>
      <with-id>s2.1.1</with-id>
    </include-controls>
  </import>

Here we can see the <import> element inside an example OSCAL profile.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

"imports": [
      {
        "href": "https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json",
        "include-controls": [
          {
            "matching": [
              {
                "pattern": "s1.1.*"
              }
            ]
          },
          {
            "with-ids": [
              "s2.1.1"
            ]
          }
        ]
      }
    ],

Here we can see the import object inside an example OSCAL profile.

1
2
3
4
5
6
7

 imports:
    - href: https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json
      include-controls:
        - matching:
            - pattern: s1.1.*
        - with-ids:
            - s2.1.1

Here we can see the import object inside an example OSCAL profile.

Notice that for all three examples, we import a catalog defined in XML. The profile resolution specification allows us to import multiple documents irrespective of the input format (as long as it is valid, well-formed OSCAL).

Now that we've seen a basic example, let's take a quick walkthrough of some of the basic functions of this section and how to use them.

Including Controls from a Catalog

Each import object contains directives on which catalog will be included and present in the outcome.

Controls can be included based on pattern matching:

1
2
3
4
5

<import href="https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json">
    <include-controls>
      <matching pattern="s1.1.*"/>
    </include-controls>
</import>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

"imports": [
      {
        "href": "https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json",
        "include-controls": [
          {
            "matching": [
              {
                "pattern": "s1.1.*"
              }
            ]
          },

1
2
3
4
5

  imports:
    - href: https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json
      include-controls:
        - matching:
            - pattern: s1.1.*

Controls can also be included based on id matching:

1
2
3
4
5

<import href="https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json">
    <include-controls>
      <with-id>s2.1.1</with-id>
    </include-controls>
</import>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

 "imports": [
      {
        "href": "https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json",
        "include-controls": [
          {
            "with-ids": [
              "s2.1.1"
            ]
          }
        ]
      }
    ],

1
2
3
4
5

imports:
    - href: https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json
      include-controls:
        - with-ids:
            - s2.1.1

Excluding Controls from a Catalog

It is possible to exclude controls from a catalog. Exclusions work the same way as inclusions, except in this case the indicated control(s) do not appear in the target catalog. The OSCAL profile Resolution Specification Draft contains a more detailed explanation of excluding controls.

1
2
3
4
5

<import href="https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json">
    <exclude-controls>
     <with-id>s2.1.2</with-id>
    </exclude-controls>    
</import>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

"imports": [
      {
        "href": "https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json",
        "exclude-controls": [
          {
            "with-ids": [
              "s2.1.2"
            ]
          }
        ]
      }
    ],

1
2
3
4
5

imports:
    - href: https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json
      exclude-controls:
        - with-ids:
            - s2.1.2

Merge Phase

The second part of an OSCAL profile represents the merge phase. In this section, the profile describes how the set of included objects from the import phase are to be combined.

The merge section provides directives as to how controls should be organized. It also provides directives for resolving conflicts where two or more variations of a control are imported as a result of multiple import statements. The three optional structuring directives are flat, as-is, and custom.

Profiles with the flat merge directive must be resolved as unstructured catalogs, with no groupings or nesting of controls. The flat directive was used in the profile as follows:

1
2
3

<merge>
    <flat/>
</merge>

1
2
3

"merge": {
    "flat": {}
},

1
2

merge:
    flat: {}

The flat merge directive will produce an unstructured catalog with the following requirements: All included controls are output to the target as a flat list directly under catalog.

  • Any included "loose parameters" are output to the target as a flat list directly under catalog.
  • Any groups are discarded.

An as-is directive is used to reproduce the structure of the source documents in the target catalog.

A custom directive provides the target catalog with a custom structure.

Modify Phase

The third and final part of an OSCAL profile is the modify section. In this section fine-grained edits can be made to the output resolved catalog.

These edits can be used to tailor controls to match an organization's needs, such as adding specific guidance, removing extraneous details, or even changing the meaning of a control. This section offers a great deal of in-depth functionality; here we cover only the most useful basics.

Setting Parameters

The set-parameters directive can be used to modify all aspects of a parameter.

Let's say in our profile we wanted to change the label on the parameter s1.1.1-prm_2 from our example catalog:

1
2
3

<param id="s1.1.1-prm_2">
    <label>a duration</label>
</param>

As profile authors, let's say we'd like to modify the parameter's label to be more specific:

1
2
3

<set-parameter param-id="s1.1.1-prm_2">
  <label>a duration (maximum 30 minutes)</label>
</set-parameter>

The <modify> element can have any number of <set-parameter> elements within it. <set-parameter> selects a parameter via the mandatory @param-id attribute and modifies the child items of the parameter (label, class, usage, etc.).

1
2
3
4
5
6
7
8

{
  "params": [
    {
      "id": "s1.1.1-prm_2",
      "label": "a duration"
    }
  ]
}

As profile authors, let's say we'd like to modify the parameter's label to be more specific:

1
2
3
4
5
6
7
8

{
  "set-parameters": [
    {
      "param-id": "s1.1.1-prm_2",
      "label": "a duration (maximum 30 minutes)"
    }
  ],
}

The modify contains an optional array set-parameters within it. set-parameters selects a parameter via the mandatory param-id field and modifies the child items of the parameter (label, class, usage, etc.).

1
2
3

params:
  - id: s1.1.1-prm_2
    label: a duration

As profile authors, let's say we'd like to modify the parameter's label to be more specific:

1
2
3

set-parameters:
    param-id: s1.1.1-prm_2
    label: a duration (maximum 30 minutes)

The modify contains an optional array set-parameters within it. set-parameters selects a parameter via the mandatory param-id field and modifies the child items of the parameter (label, class, usage, etc.).

Altering

The alter directive is extremely powerful, and allows us to:

  • Add content (links, params, props, and parts) to a given control at any position.
  • Remove content from a control.

Note that the alter statement cannot add subcontrols to, or remove them from, a target control, as that would conflict semantically with the include directive.

For our example profile, let's say we wanted to add some supplemental guidance to control s1.1.1 "Information security roles and responsibilities" from our example catalog:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

<control id="s1.1.1">
  <title>Information security roles and responsibilities</title>
  <!-- Omitting non-relevant params, props, and parts for brevity -->
  <part id="s1.1.1_gdn" name="guidance">
      <part id="s1.1.1_gdn.1" name="item">
        <p>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.</p>
      </part>
      <part id="s1.1.1_gdn.2" name="item">
        <p>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.</p>
      </part>
      <part id="s1.1.1_gdn.3" name="item">
        <p>Areas for which individuals are responsible should be stated. In particular the following should take place:</p>
        <ol>
            <li>the assets and information security processes should be identified and defined;</li>
            <li>the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented;</li>
            <li>authorization levels should be defined and documented;</li>
            <li>to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments;</li>
            <li>coordination and oversight of information security aspects of supplier relationships should be identified and documented.</li>
        </ol>
      </part>
  </part>
</control>

As profile authors, let's say we'd like to insert a new part after s.1.1.1_gdn.3 with additional guidance on setting an automatic lock on a specific platform:

1
2
3
4
5
6
7
8

<alter control-id="s1.1.1">
  <add position="after" by-id="s1.1.1_gdn.3">
    <!-- new part to be inserted within s1.1.1 after s1.1.1_gdn.3 -->
    <part id="s1.1.1_gdn.4" name="item">
      <p>Users of devices running Gnome can adjust the inactivity timeout using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en</p>
    </part>
  </add>
</alter>

A <modify> element can have any number of <alter> elements inside of it. <alter> selects a single control through the mandatory @control-id attribute and modifies them with the following sub-elements:

  • <add> elements can add some content to a control at a position specified by @position, which can be "before", "after", "starting", and "ending". If @position is set to "before" or "after", an object must be selected via the @by-id attribute.

  • <remove> elements can remove some content from a control as selected by the @by-class, @by-id, @by-item-name, @by-name, or @by-ns attributes, singly or in combination. If more than one of these match directives is used, only objects identified by all these criteria (for example, by both @by-name and @by-ns if those are given together) are identified for removal.

A single <alter> element can have multiple <add> and <remove> sub-elements.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
  "id": "s1.1.1",
  "title": "Information security roles and responsibilities",
  // Omitting non-relevant params, props, and parts for brevity
  "parts": [
    {
      "id": "s1.1.1_gdn",
      "name": "guidance",
      "parts": [
        {
          "id": "s1.1.1_gdn.1",
          "name": "item",
          "prose": "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."
        },
        {
          "id": "s1.1.1_gdn.2",
          "name": "item",
          "prose": "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."
        },
        {
          "id": "s1.1.1_gdn.3",
          "name": "item",
          "prose": "Areas for which individuals are responsible should be stated. In particular the following should take place:\n\n1. the assets and information security processes should be identified and defined;\n1. the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented;\n1. authorization levels should be defined and documented;\n1. to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments;\n1. coordination and oversight of information security aspects of supplier relationships should be identified and documented.\n"
        }
      ]
    }
  ]
}

As profile authors, let's say we'd like to insert a new part after s.1.1.1_gdn.3 with additional guidance on setting an automatic lock on a specific platform:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "alters": [
    {
      "control-id": "s1.1.1",
      "adds": [
        {
          "by-id": "s1.1.1_gdn.3",
          "position": "after",
          "parts": [
            {
              "id": "s1.1.1_gdn.4",
              "name": "item",
              "prose": "Users of devices running Gnome can adjust the inactivity timeout using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en"
            }
          ]
        }
      ]
    }
  ]
}

A modify object has an optional array of alters objects. alters objects select a single control through the mandatory control-id field and modifies them with the following sub-objects:

  • adds is an array of objects can add some content to a control at a position specified by the position field, which can be "before", "after", "starting", and "ending". If position is set to "before" or "after", an object must be selected via the by-id field.

  • removes is an array of objects that can remove some content from a control as selected by the by-class, by-id, by-item-name, by-name, or by-ns fields, singly or in combination. If more than one of these match directives is used, only objects identified by all these criteria (for example, by both by-name and by-ns if those are given together) are identified for removal.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

---
id: s1.1.1
title: Information security roles and responsibilities
parts:
- id: s1.1.1_gdn
  name: guidance
  parts:
  - id: s1.1.1_gdn.1
    name: item
    prose: 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.
  - id: s1.1.1_gdn.2
    name: item
    prose: 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.
  - id: s1.1.1_gdn.3
    name: item
    prose: |
      Areas for which individuals are responsible should be stated. In particular the following should take place:

      1. the assets and information security processes should be identified and defined;
      1. the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented;
      1. authorization levels should be defined and documented;
      1. to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments;
      1. coordination and oversight of information security aspects of supplier relationships should be identified and documented.

As profile authors, let's say we'd like to insert a new part after s.1.1.1_gdn.3 with additional guidance on setting an automatic lock on a specific platform:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
alters:
- control-id: s1.1.1
  adds:
  - by-id: s1.1.1_gdn.3
    position: after
    parts:
    - id: s1.1.1_gdn.4
      name: item
      prose: 'Users of devices running Gnome can adjust the inactivity timeout using
        the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en'

A modify object has an optional array of alters objects. alters objects select a single control through the mandatory control-id field and modifies them with the following sub-objects:

  • adds is an array of objects can add some content to a control at a position specified by the position field, which can be "before", "after", "starting", and "ending". If position is set to "before" or "after", an object must be selected via the by-id field.

  • removes is an array of objects that can remove some content from a control as selected by the by-class, by-id, by-item-name, by-name, or by-ns fields, singly or in combination. If more than one of these match directives is used, only objects identified by all these criteria (for example, by both by-name and by-ns if those are given together) are identified for removal.

The Final Profile

After applying all of the techniques discussed in this tutorial, we obtain an OSCAL profile with the following structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

<?xml version="1.0" encoding="UTF-8"?>
<profile xmlns="http://csrc.nist.gov/ns/oscal/1.0" uuid="c0dc468c-934e-4fe9-b5bf-9fc63f5a2915">
  <metadata>
    <title>Sample Security Profile 
      <em>for Demonstration</em> and Testing
    </title>
    <last-modified>2023-04-10T10:31:28.355446-04:00</last-modified>
    <version>1.0</version>
    <oscal-version>1.0.4</oscal-version>
    <revisions/>
    <remarks>
      <p>The following document is used in the OSCAL Profile Tutorial and builds on the catalog created for the OSCAL Catalog Tutorial</p>
    </remarks>
  </metadata>
  <import href="https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json">
    <include-controls>
      <matching pattern="s1.1.*"/>
    </include-controls>
    <include-controls>
      <with-id>s2.1.1</with-id>
    </include-controls>
    <exclude-controls>
        <with-id>s2.1.2</with-id>
    </exclude-controls>
  </import>
  <merge>
    <flat/>
  </merge>
  <modify>
    <set-parameter param-id="s1.1.1-prm_2">
      <label>a duration (maximum 30 minutes)</label>
    </set-parameter>
    <alter control-id="s1.1.1">
      <add position="after" by-id="s1.1.1_gdn.3">
        <part id="s1.1.1_gdn.4" name="item">
          <p>Users of devices running Gnome can adjust the inactivity timeout using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en</p>
        </part>
      </add>
    </alter>
  </modify>
</profile>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

{
  "profile": {
    "uuid": "c0dc468c-934e-4fe9-b5bf-9fc63f5a2915",
    "metadata": {
      "title": "Sample Security Profile *for Demonstration* and Testing",
      "last-modified": "2023-04-10T10:31:28.355446-04:00",
      "version": "1.0",
      "oscal-version": "1.04",
      "remarks": "The following document is used in the OSCAL Profile Tutorial and builds on the catalog created for the OSCAL Catalog Tutorial"
    },
    "imports": [
      {
        "href": "https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json",
        "include-controls": [
          {
            "matching": [
              {
                "pattern": "s1.1.*"
              }
            ]
          },
          {
            "with-ids": [
              "s2.1.1"
            ],
          "exclude-controls": [
            {
              "with-ids": [
                "s2.1.2"
              ]
            }
          ]
          }
        ]
      }
    ],
    "merge": {
      "flat": {}
    },
    "modify": {
      "set-parameters": [
        {
          "param-id": "s1.1.1-prm_2",
          "label": "a duration (maximum 30 minutes)"
        }
      ],
      "alters": [
        {
          "control-id": "s1.1.1",
          "adds": [
            {
              "by-id": "s1.1.1_gdn.3",
              "position": "after",
              "parts": [
                {
                  "id": "s1.1.1_gdn.4",
                  "name": "item",
                  "prose": "Users of devices running Gnome can adjust the inactivity timeout using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en"
                }
              ]
            }
          ]
        }
      ]
    }
  }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

---
profile:
  uuid: c0dc468c-934e-4fe9-b5bf-9fc63f5a2915
  metadata:
    title: Sample Security Profile *for Demonstration* and Testing
    last-modified: "2023-04-10T10:31:28.355446-04:00"
    version: "1.0"
    oscal-version: "1.04"
    remarks:
      The following document is used in the OSCAL Profile Tutorial and builds
      on the catalog created for the OSCAL Catalog Tutorial
  imports:
    - href: https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/json/basic-catalog.json
      include-controls:
        - matching:
            - pattern: s1.1.*
        - with-ids:
            - s2.1.1
      exclude-controls:
        - with-ids:
            - s2.1.2
  merge:
    flat: {}
  modify:
    set-parameters:
      - param-id: s1.1.1-prm_2
        label: a duration (maximum 30 minutes)
    alters:
      - control-id: s1.1.1
        adds:
          - by-id: s1.1.1_gdn.3
            position: after
            parts:
              - id: s1.1.1_gdn.4
                name: item
                prose:
                  "Users of devices running Gnome can adjust the inactivity timeout
                  using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en"

Creating the Resolved Catalog from a Profile

The profile resolution specification describes how to use an input profile to generate a new resolved catalog that captures the selection, arrangement and changes made to the controls listed in the profile. The profile resolution specification has multiple NIST implementations, and is open to third party implementations maintained by the community.

For this example, let's use the NIST-maintained OSCAL Command Line Interface (CLI). Upon installation, a user can perform profile resolution with the OSCAL-CLI as follows:

# Resolve input profile saved to "profile.xml"
$ oscal-cli profile resolve profile.xml

Notice, that the OSCAL CLI automatically detects the file type of the profile and produces the following output catalog:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182

<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="http://csrc.nist.gov/ns/oscal/1.0" uuid="9ed3e413-1404-45b2-8608-192d41bf3785">
  <metadata>
    <title>Sample Security Profile 
      <em>for Demonstration</em> and Testing
    </title>
    <last-modified>2023-05-13T22:06:43.017554394Z</last-modified>
    <version>1.0</version>
    <oscal-version>1.0.4</oscal-version>
  </metadata>
  <control id="s1.1.1">
    <title>Information security roles and responsibilities</title>
    <param id="s1.1.1-prm1">
      <label>a choice from a selection</label>
      <select how-many="one-or-more">
        <choice>initiating a device lock after 
          <insert type="param" id-ref="s1.1.1-prm_2"/> of inactivity
        </choice>
        <choice>requiring the user to initiate a device lock before leaving the system unattended</choice>
      </select>
    </param>
    <param id="s1.1.1-prm_2">
      <label>a duration (maximum 30 minutes)</label>
    </param>
    <prop name="label" value="1.1.1"/>
    <part id="s1.1.1_stm" name="statement">
      <p>All information security responsibilities should be defined and allocated.</p>
      <p>A value has been assigned to 
        <insert type="param" id-ref="s1.1.1-prm1"/>.
      </p>
      <p>A cross link has been established with a choppy syntax: 
        <a href="#s1.2">(choppy)</a>.
      </p>
    </part>
    <part id="s1.1.1_gdn" name="guidance">
      <part id="s1.1.1_gdn.1" name="item">
        <p>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.</p>
      </part>
      <part id="s1.1.1_gdn.2" name="item">
        <p>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.</p>
      </part>
      <part id="s1.1.1_gdn.3" name="item">
        <p>Areas for which individuals are responsible should be stated. In particular the following should take place:</p>
        <ol>
          <li>
            <p>the assets and information security processes should be identified and defined;</p>
          </li>
          <li>
            <p>the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented;</p>
          </li>
          <li>
            <p>authorization levels should be defined and documented;</p>
          </li>
          <li>
            <p>to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments;</p>
          </li>
          <li>
            <p>coordination and oversight of information security aspects of supplier relationships should be identified and documented.</p>
          </li>
        </ol>
      </part>
      <part id="s1.1.1_gdn.4" name="item">
        <p>Users of devices running Gnome can adjust the inactivity timeout using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en</p>
      </part>
    </part>
    <part id="s1.1.1_inf" name="information">
      <prop name="label" value="Other information"/>
      <p>Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of controls.</p>
      <p>However, responsibility for resourcing and implementing the controls will often remain with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection.</p>
    </part>
  </control>
  <control id="s1.1.2">
    <title>Segregation of duties</title>
    <prop name="label" value="1.1.2"/>
    <part id="s1.1.2_stm" name="statement">
      <p>Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets.</p>
    </part>
    <part id="s1.1.2_gdn" name="guidance">
      <part id="s1.1.2_gdn.1" name="item">
        <p>Care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered in designing the controls.</p>
      </part>
      <part id="s1.1.2_gdn.2" name="item">
        <p>Small organizations may find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision should be considered.</p>
      </part>
    </part>
    <part id="s1.1.2_inf" name="information">
      <p>Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization’s assets.</p>
    </part>
  </control>
  <control id="s2.1.1">
    <title>Access control policy</title>
    <prop name="label" value="2.1.1"/>
    <part id="s2.1.1_stm" name="statement">
      <p>An access control policy should be established, documented and reviewed based on business and information security requirements.</p>
    </part>
    <part id="s2.1.1_gdn" name="guidance">
      <part id="s2.1.1_gdn.1" name="item">
        <p>Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks.</p>
      </part>
      <part id="s2.1.1_gdn.2" name="item">
        <p>Access controls are both logical and physical and these should be considered together.</p>
      </part>
      <part id="s2.1.1_gdn.3" name="item">
        <p>Users and service providers should be given a clear statement of the business requirements to be met by access controls.</p>
      </part>
      <part id="s2.1.1_gdn.4" name="item">
        <p>The policy should take account of the following:</p>
        <ol>
          <li>
            <p>security requirements of business applications;</p>
          </li>
          <li>
            <p>policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information;</p>
          </li>
          <li>
            <p>consistency between the access rights and information classification policies of systems and networks;</p>
          </li>
          <li>
            <p>relevant legislation and any contractual obligations regarding limitation of access to data or services;</p>
          </li>
          <li>
            <p>management of access rights in a distributed and networked environment which recognizes all types of connections available;</p>
          </li>
          <li>
            <p>segregation of access control roles, e.g. access request, access authorization, access administration;</p>
          </li>
          <li>
            <p>requirements for formal authorization of access requests;</p>
          </li>
          <li>
            <p>requirements for periodic review of access rights;</p>
          </li>
          <li>
            <p>removal of access rights;</p>
          </li>
          <li>
            <p>archiving of records of all significant events concerning the use and management of user identities and secret authentication information;,</p>
          </li>
          <li>
            <p>roles with privileged access.</p>
          </li>
        </ol>
      </part>
    </part>
    <part id="s2.1.1_stm" name="information">
      <part id="s2.1.1_stm.1" name="item">
        <p>Care should be taken when specifying access control rules to consider:</p>
        <ol>
          <li>
            <p>establishing rules based on the premise “Everything is generally forbidden unless expressly permitted” rather than the weaker rule “Everything is generally permitted unless expressly forbidden”;</p>
          </li>
          <li>
            <p>changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user;</p>
          </li>
          <li>
            <p>changes in user permissions that are initiated automatically by the information system and those initiated by an administrator;</p>
          </li>
          <li>
            <p>rules which require specific approval before enactment and those which do not.</p>
          </li>
        </ol>
      </part>
      <part id="s2.1.1_stm.2" name="item">
        <p>Access control rules should be supported by formal procedures and defined responsibilities.</p>
      </part>
      <part id="s2.1.1_stm.3" name="item">
        <p>Role based access control is an approach used successfully by many organizations to link access rights with business roles.</p>
      </part>
      <part id="s2.1.1_stm.4" name="item">
        <p>Two of the frequent principles directing the access control policy are:</p>
        <ol>
          <li>
            <p>Need-to-know: you are only granted access to the information you need to perform your tasks (different tasks/roles mean different need-to-know and hence different access profile);</p>
          </li>
          <li>
            <p>Need-to-use: you are only granted access to the information processing facilities (IT equipment, applications, procedures, rooms) you need to perform your task/job/role.</p>
          </li>
        </ol>
      </part>
    </part>
  </control>
</catalog>

# Resolve input profile saved to "profile.json"
$ oscal-cli profile resolve profile.json

Notice, that the OSCAL CLI automatically detects the file type of the profile and produces the following output catalog:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191

{
  "catalog": {
    "uuid": "b51ff9bb-5ffd-415d-a25c-7eef2fd6d48b",
    "metadata": {
      "title": "Sample Security Profile *for Demonstration* and Testing",
      "last-modified": "2023-05-13T22:08:03.596582192Z",
      "version": "1.0",
      "oscal-version": "1.0.4"
    },
    "controls": [
      {
        "id": "s1.1.1",
        "title": "Information security roles and responsibilities",
        "params": [
          {
            "id": "s1.1.1-prm1",
            "label": "a choice from a selection",
            "select": {
              "how-many": "one-or-more",
              "choice": [
                "initiating a device lock after {{ insert: param, s1.1.1-prm_2 }} of inactivity",
                "requiring the user to initiate a device lock before leaving the system unattended"
              ]
            }
          },
          {
            "id": "s1.1.1-prm_2",
            "label": "a duration (maximum 30 minutes)"
          }
        ],
        "props": [
          {
            "name": "label",
            "value": "1.1.1"
          }
        ],
        "parts": [
          {
            "id": "s1.1.1_stm",
            "name": "statement",
            "prose": "All information security responsibilities should be defined and allocated.\n\nA value has been assigned to {{ insert: param, s1.1.1-prm1 }}.\n\nA cross link has been established with a choppy syntax: [(choppy)](#s1.2)."
          },
          {
            "id": "s1.1.1_gdn",
            "name": "guidance",
            "parts": [
              {
                "id": "s1.1.1_gdn.1",
                "name": "item",
                "prose": "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."
              },
              {
                "id": "s1.1.1_gdn.2",
                "name": "item",
                "prose": "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."
              },
              {
                "id": "s1.1.1_gdn.3",
                "name": "item",
                "prose": "Areas for which individuals are responsible should be stated. In particular the following should take place:\n\n1. the assets and information security processes should be identified and defined;\n2. the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented;\n3. authorization levels should be defined and documented;\n4. to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments;\n5. coordination and oversight of information security aspects of supplier relationships should be identified and documented."
              },
              {
                "id": "s1.1.1_gdn.4",
                "name": "item",
                "prose": "Users of devices running Gnome can adjust the inactivity timeout using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en"
              }
            ]
          },
          {
            "id": "s1.1.1_inf",
            "name": "information",
            "props": [
              {
                "name": "label",
                "value": "Other information"
              }
            ],
            "prose": "Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of controls.\n\nHowever, responsibility for resourcing and implementing the controls will often remain with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection."
          }
        ]
      },
      {
        "id": "s1.1.2",
        "title": "Segregation of duties",
        "props": [
          {
            "name": "label",
            "value": "1.1.2"
          }
        ],
        "parts": [
          {
            "id": "s1.1.2_stm",
            "name": "statement",
            "prose": "Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets."
          },
          {
            "id": "s1.1.2_gdn",
            "name": "guidance",
            "parts": [
              {
                "id": "s1.1.2_gdn.1",
                "name": "item",
                "prose": "Care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered in designing the controls."
              },
              {
                "id": "s1.1.2_gdn.2",
                "name": "item",
                "prose": "Small organizations may find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision should be considered."
              }
            ]
          },
          {
            "id": "s1.1.2_inf",
            "name": "information",
            "prose": "Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization’s assets."
          }
        ]
      },
      {
        "id": "s2.1.1",
        "title": "Access control policy",
        "props": [
          {
            "name": "label",
            "value": "2.1.1"
          }
        ],
        "parts": [
          {
            "id": "s2.1.1_stm",
            "name": "statement",
            "prose": "An access control policy should be established, documented and reviewed based on business and information security requirements."
          },
          {
            "id": "s2.1.1_gdn",
            "name": "guidance",
            "parts": [
              {
                "id": "s2.1.1_gdn.1",
                "name": "item",
                "prose": "Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks."
              },
              {
                "id": "s2.1.1_gdn.2",
                "name": "item",
                "prose": "Access controls are both logical and physical and these should be considered together."
              },
              {
                "id": "s2.1.1_gdn.3",
                "name": "item",
                "prose": "Users and service providers should be given a clear statement of the business requirements to be met by access controls."
              },
              {
                "id": "s2.1.1_gdn.4",
                "name": "item",
                "prose": "The policy should take account of the following:\n\n1. security requirements of business applications;\n2. policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information;\n3. consistency between the access rights and information classification policies of systems and networks;\n4. relevant legislation and any contractual obligations regarding limitation of access to data or services;\n5. management of access rights in a distributed and networked environment which recognizes all types of connections available;\n6. segregation of access control roles, e.g. access request, access authorization, access administration;\n7. requirements for formal authorization of access requests;\n8. requirements for periodic review of access rights;\n9. removal of access rights;\n10. archiving of records of all significant events concerning the use and management of user identities and secret authentication information;,\n11. roles with privileged access."
              }
            ]
          },
          {
            "id": "s2.1.1_stm",
            "name": "information",
            "parts": [
              {
                "id": "s2.1.1_stm.1",
                "name": "item",
                "prose": "Care should be taken when specifying access control rules to consider:\n\n1. establishing rules based on the premise “Everything is generally forbidden unless expressly permitted” rather than the weaker rule “Everything is generally permitted unless expressly forbidden”;\n2. changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user;\n3. changes in user permissions that are initiated automatically by the information system and those initiated by an administrator;\n4. rules which require specific approval before enactment and those which do not."
              },
              {
                "id": "s2.1.1_stm.2",
                "name": "item",
                "prose": "Access control rules should be supported by formal procedures and defined responsibilities."
              },
              {
                "id": "s2.1.1_stm.3",
                "name": "item",
                "prose": "Role based access control is an approach used successfully by many organizations to link access rights with business roles."
              },
              {
                "id": "s2.1.1_stm.4",
                "name": "item",
                "prose": "Two of the frequent principles directing the access control policy are:\n\n1. Need-to-know: you are only granted access to the information you need to perform your tasks (different tasks/roles mean different need-to-know and hence different access profile);\n2. Need-to-use: you are only granted access to the information processing facilities (IT equipment, applications, procedures, rooms) you need to perform your task/job/role."
              }
            ]
          }
        ]
      }
    ]
  }
}

# Resolve input profile saved to "profile.yaml"
$ oscal-cli profile resolve profile.yaml

Notice, that the OSCAL CLI automatically detects the file type of the profile and produces the following output catalog:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147

---
catalog:
  uuid: b1296da4-4ada-40f1-bbeb-20e3429bef41
  metadata:
    title: Sample Security Profile *for Demonstration* and Testing
    last-modified: 2023-05-13T22:08:16.76575041Z
    version: "1.0"
    oscal-version: 1.0.4
  controls:
  - id: s1.1.1
    title: Information security roles and responsibilities
    params:
    - id: s1.1.1-prm1
      label: a choice from a selection
      select:
        how-many: one-or-more
        choice:
        - "initiating a device lock after {{ insert: param, s1.1.1-prm_2 }} of inactivity"
        - requiring the user to initiate a device lock before leaving the system unattended
    - id: s1.1.1-prm_2
      label: a duration (maximum 30 minutes)
    props:
    - name: label
      value: 1.1.1
    parts:
    - id: s1.1.1_stm
      name: statement
      prose: |-
        All information security responsibilities should be defined and allocated.

        A value has been assigned to {{ insert: param, s1.1.1-prm1 }}.

        A cross link has been established with a choppy syntax: [(choppy)](#s1.2).        
    - id: s1.1.1_gdn
      name: guidance
      parts:
      - id: s1.1.1_gdn.1
        name: item
        prose: "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."
      - id: s1.1.1_gdn.2
        name: item
        prose: 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.
      - id: s1.1.1_gdn.3
        name: item
        prose: |-
          Areas for which individuals are responsible should be stated. In particular the following should take place:

          1. the assets and information security processes should be identified and defined;
          2. the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented;
          3. authorization levels should be defined and documented;
          4. to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments;
          5. coordination and oversight of information security aspects of supplier relationships should be identified and documented.          
      - id: s1.1.1_gdn.4
        name: item
        prose: "Users of devices running Gnome can adjust the inactivity timeout using the following link: https://help.gnome.org/admin/system-admin-guide/stable/desktop-lockscreen.html.en"
    - id: s1.1.1_inf
      name: information
      props:
      - name: label
        value: Other information
      prose: |-
        Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of controls.

        However, responsibility for resourcing and implementing the controls will often remain with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection.        
  - id: s1.1.2
    title: Segregation of duties
    props:
    - name: label
      value: 1.1.2
    parts:
    - id: s1.1.2_stm
      name: statement
      prose: Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets.
    - id: s1.1.2_gdn
      name: guidance
      parts:
      - id: s1.1.2_gdn.1
        name: item
        prose: "Care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered in designing the controls."
      - id: s1.1.2_gdn.2
        name: item
        prose: "Small organizations may find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision should be considered."
    - id: s1.1.2_inf
      name: information
      prose: Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization’s assets.
  - id: s2.1.1
    title: Access control policy
    props:
    - name: label
      value: 2.1.1
    parts:
    - id: s2.1.1_stm
      name: statement
      prose: "An access control policy should be established, documented and reviewed based on business and information security requirements."
    - id: s2.1.1_gdn
      name: guidance
      parts:
      - id: s2.1.1_gdn.1
        name: item
        prose: "Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks."
      - id: s2.1.1_gdn.2
        name: item
        prose: Access controls are both logical and physical and these should be considered together.
      - id: s2.1.1_gdn.3
        name: item
        prose: Users and service providers should be given a clear statement of the business requirements to be met by access controls.
      - id: s2.1.1_gdn.4
        name: item
        prose: |-
          The policy should take account of the following:

          1. security requirements of business applications;
          2. policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information;
          3. consistency between the access rights and information classification policies of systems and networks;
          4. relevant legislation and any contractual obligations regarding limitation of access to data or services;
          5. management of access rights in a distributed and networked environment which recognizes all types of connections available;
          6. segregation of access control roles, e.g. access request, access authorization, access administration;
          7. requirements for formal authorization of access requests;
          8. requirements for periodic review of access rights;
          9. removal of access rights;
          10. archiving of records of all significant events concerning the use and management of user identities and secret authentication information;,
          11. roles with privileged access.          
    - id: s2.1.1_stm
      name: information
      parts:
      - id: s2.1.1_stm.1
        name: item
        prose: |-
          Care should be taken when specifying access control rules to consider:

          1. establishing rules based on the premise “Everything is generally forbidden unless expressly permitted” rather than the weaker rule “Everything is generally permitted unless expressly forbidden”;
          2. changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user;
          3. changes in user permissions that are initiated automatically by the information system and those initiated by an administrator;
          4. rules which require specific approval before enactment and those which do not.          
      - id: s2.1.1_stm.2
        name: item
        prose: Access control rules should be supported by formal procedures and defined responsibilities.
      - id: s2.1.1_stm.3
        name: item
        prose: Role based access control is an approach used successfully by many organizations to link access rights with business roles.
      - id: s2.1.1_stm.4
        name: item
        prose: |-
          Two of the frequent principles directing the access control policy are:

          1. Need-to-know: you are only granted access to the information you need to perform your tasks (different tasks/roles mean different need-to-know and hence different access profile);
          2. Need-to-use: you are only granted access to the information processing facilities (IT equipment, applications, procedures, rooms) you need to perform your task/job/role.

Summary

This concludes the tutorial. At this point you should be familiar with:

  • The basic structure of a control baseline expressed in OSCAL.
  • The use of the "Import" section to select controls from a source catalog.
  • Using the "Merge" section to structure the output baseline.
  • The use of the "Modify" section to set the values of parameters.

For more information you can review the OSCAL profile model documentation.

This page was last updated on November 8, 2023.