From aeffda6636c7f83b2ab9a8244d421a513836e424 Mon Sep 17 00:00:00 2001 From: Michaela Iorga Date: Thu, 20 Feb 2020 08:22:53 -0500 Subject: [PATCH 01/10] adding sample catalog based on ISO/IEC 27002 in markdown and OSCAL XML and WIP tutorial --- docs/tutorials/catalog/Catalog Sample.md | 122 +++++++++++ docs/tutorials/catalog/Catalog Sample.xml | 231 +++++++++++++++++++++ docs/tutorials/catalog/Catalog Tutorial.md | 50 +++++ 3 files changed, 403 insertions(+) create mode 100644 docs/tutorials/catalog/Catalog Sample.md create mode 100755 docs/tutorials/catalog/Catalog Sample.xml create mode 100644 docs/tutorials/catalog/Catalog Tutorial.md diff --git a/docs/tutorials/catalog/Catalog Sample.md b/docs/tutorials/catalog/Catalog Sample.md new file mode 100644 index 0000000000..17d2e603fb --- /dev/null +++ b/docs/tutorials/catalog/Catalog Sample.md @@ -0,0 +1,122 @@ + + +# Sample Security Catalog + Version 1.0 + Published: 02.02.2020 + Last Modified: 02.10.2020 + +## 1 Organization of Information Security + +### 1.1 Internal Organization + +**Objective:** To establish a management framework to initiate and control the implementation and +operation of information security within the organization. + +#### 1.1.1 Information security roles and responsibilities + +**Control** + +All information security responsibilities should be defined and allocated. + +**Implementation guidance** + +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. +Areas for which individuals are responsible should be stated. In particular the following should take place: +a) the assets and information security processes should be identified and defined; +b) the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented; +d) authorization levels should be defined and documented; +e) 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; +g) coordination and oversight of information security aspects of supplier relationships should be identified and documented. + +**Other information** + +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. + +#### 1.1.2 Segregation of duties + +**Control** + +Conflicting duties and areas of responsibility should be segregated to reduce opportunities for +unauthorized or unintentional modification or misuse of the organization�s assets. + +**Implementation guidance** + +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. +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. + +**Other information** + +Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization�s assets. + +## 2 Access Control + +### 2.1 Business Requirements of Access Control + +**Objective:** To limit access to information and information processing facilities. + +#### 2.1.1 Access control policy + +**Control** + +An access control policy should be established, documented and reviewed based on business and +information security requirements. + +**Implementation guidance** + +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. +Access controls are both logical and physical and these should be considered together. +Users and service providers should be given a clear statement of the business requirements to be met by access controls. +The policy should take account of the following: +a) security requirements of business applications; +b) policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information; +d) consistency between the access rights and information classification policies of systems and networks; +e) relevant legislation and any contractual obligations regarding limitation of access to data or services; +f) management of access rights in a distributed and networked environment which recognizes all + types of connections available; +g) segregation of access control roles, e.g. access request, access authorization, access administration; +h) requirements for formal authorization of access requests; +i) requirements for periodic review of access rights; +j) removal of access rights; +k) archiving of records of all significant events concerning the use and management of user identities and secret authentication information; +l) roles with privileged access. + +**Other information** + +Care should be taken when specifying access control rules to consider: +a) 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"; +b) changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user; +c) changes in user permissions that are initiated automatically by the information system and those initiated by an administrator; +d) rules which require specific approval before enactment and those which do not. +Access control rules should be supported by formal procedures and defined +responsibilities. +Role based access control is an approach used successfully by many organizations to link access rights +with business roles. +Two of the frequent principles directing the access control policy are: +a) 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); +b) 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. + +#### 2.1.2 Access to networks and network services + +**Control** + +Users should only be provided with access to the network and network services that they have been specifically authorized to use. + +**Implementation guidance** + +A policy should be formulated concerning the use of networks and network services. This policy +should cover: +a) the networks and network services which are allowed to be accessed; +b) authorization procedures for determining who is allowed to access which networks and networked services; +c) management controls and procedures to protect access to network connections and network services; +d) the means used to access networks and network services (e.g. use of VPN or wireless network); +e) user authentication requirements for accessing various network services; +f) monitoring of the use of network services. +The policy on the use of network services should be consistent with the organization's access control policy. + +**Other information** + +Unauthorized and insecure connections to network services can affect the whole organization. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the organization's information security management and control. diff --git a/docs/tutorials/catalog/Catalog Sample.xml b/docs/tutorials/catalog/Catalog Sample.xml new file mode 100755 index 0000000000..2eea406eab --- /dev/null +++ b/docs/tutorials/catalog/Catalog Sample.xml @@ -0,0 +1,231 @@ + + + + Sample Security Catalog + 2020-02-02T11:01:04.736-04:00 + 2020-10-02T11:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + Organization of Information Security + + Internal Organization + 1.1 + + Objective: +

To establish a management framework to initiate and control the implementation and operation of information security within the organization.

+ + + Information security roles and responsibilities + 1.1.1 + c01 + + Control +

All information security responsibilities should be defined and + allocated.

+ + + Implementation guidance + +

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.

+ + +

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. +
  2. the entity responsible for each asset or information security + process should be assigned and the details of this responsibility + should be documented;
    3. +
  3. authorization levels should be defined and documented;
    4. +
  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. +
  5. coordination and oversight of information security aspects of + supplier relationships should be identified and documented.
    6. +
+ + + + Other information +

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.

+ + + + + Segregation of duties + 1.1.2 + c02 + + Control +

Conflicting duties and areas of responsibility should be segregated to + reduce opportunities for unauthorized or unintentional modification or + misuse of the organization’s assets.

+ + + Implementation guidance + +

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.

+ + +

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.

+ + + + Other information +

Segregation of duties is a method for reducing the risk of accidental + or deliberate misuse of an organization’s assets.

+ + + + + + Access control + + Business requirements of access control + 2.1 + + Objective: +

To limit access to information and information processing facilities.

+ + + Access control policy + 2.1.1 + c03 + + Control +

An access control policy should be established, documented and reviewed based on business and information security requirements.

+ + + Implementation guidance + +

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.

+ + +

Access controls are both logical and physical and these should be considered together.

+ + +

Users and service providers should be given a clear statement of the business requirements to be met by access controls.

+ + +

The policy should take account of the following:

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

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. +
  2. changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user;
    3. +
  3. changes in user permissions that are initiated automatically by the information system and those initiated by an administrator;
    4. +
  4. rules which require specific approval before enactment and those which do not.
    5. +
+ + +

Access control rules should be supported by formal procedures and defined responsibilities.

+ + +

Role based access control is an approach used successfully by many organizations to link access rights with business roles.

+ + +

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. +
  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.
    3. +
+ + + + + Access to networks and network services + 2.1.2 + c04 + + Control +

Users should only be provided with access to the network and network services that they have been specifically authorized to use.

+ + + Implementation guidance + +

A policy should be formulated concerning the use of networks and network services. This policy should cover:

+
    +
  1. the networks and network services which are allowed to be accessed;
    2. +
  2. authorization procedures for determining who is allowed to access which networks and networked services;
    3. +
  3. management controls and procedures to protect access to network connections and network services;
    4. +
  4. the means used to access networks and network services (e.g. use of VPN or wireless network);
    5. +
  5. user authentication requirements for accessing various network services;
    6. +
  6. monitoring of the use of network service
    7. +
+ + +

The policy on the use of network services should be consistent with the organization’s access control policy

+ + + + + + + + + + diff --git a/docs/tutorials/catalog/Catalog Tutorial.md b/docs/tutorials/catalog/Catalog Tutorial.md new file mode 100644 index 0000000000..29408e90b1 --- /dev/null +++ b/docs/tutorials/catalog/Catalog Tutorial.md @@ -0,0 +1,50 @@ +# OSCAL Catalog Tutorial + +Prerequisite: [OSCAL Data Types](https://pages.nist.gov/OSCAL/documentation/schema/datatypes/) + +## What is an OSCAL Catalog +## Example of a Proprietary Catalog + +An [OSCAL](https://www.nist.gov/oscal) Control Catalog is a machine-readable representation of a catalog of security controls which is a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. + +For the purpose of this tutorial, a proprietary catalog is created. The file is available for view or download [here](./Catalog Sample.pdf) + +## Reformatting the Control Catalog into an OSCAL Catalog (XML and JSON) +### Catalog Schemas + +The OSCAL Catalog Model can be used to describe a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. The [OSCAL](https://www.nist.gov/oscal) website provides comprehensive information about the [OSCAL Catalog Model](https://pages.nist.gov/OSCAL/documentation/schema/catalog/) + +There are two schemas for the Catalog Model: +- an XML Schema based on the [XML Schema Definition Language (XSD) 1.1](https://www.w3.org/TR/xmlschema11-1/) that describes the XML tag set for the OSCAL Catalog Model, and +- a JSON Schema based on the [JSON Schema Draft-07](https://json-schema.org/specification.html) that describes a JSON data object for the OSCAL Catalog Model. + +The two schema files are listed below. The schemas are necessary to validate the content created in OSCAL. + +| XML Schema | JSON Schema | +| :---------:|:---------:| +| [oscal_catalog_schema.xsd](https://github.com/usnistgov/OSCAL/blob/master/xml/schema/oscal_catalog_schema.xsd) | [oscal_catalog_schema.json](https://github.com/usnistgov/OSCAL/blob/master/json/schema/oscal_catalog_schema.json) | + +### Control Catalog Model + +This tutorial is not focusoing on the schemas themselves but rather on the formatting in OSCAL of a control catalog. For more detail information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/json-schema/), respectivly. + +Current tutorial highlight only the high-level elements of the schemas, to give an overview of the problem. + + The root of the Control Catalog format is `catalog`. + +A `catalog` contains: +- `metadata` – mandatory to have one +- `groups` – may have none, or as many as necessary +- `controls` – may have none, or as many as necessary +- `back-matter` – may have none, or as many as necessary + +| ![Catalog elements](./Catalog_1_x_s.png) | ![Catalog elements](./Catalog_1_j_s.png) | + +#### Catalog's Metadata +The `metadata` has identical structure for all OSCAL files. A separate tutorial is discussing all the elements of a `metadata`. This tutorial is only ilustrating the mandatory elements based on the information in the [Sample Security Catalog](./Catalog%20Sample.md) + +#### Formatting a Control in OSCAL + +#### Formatting a Back-matter + + From b65b607d384e4c10a8c19b3f54f5a2e426f98c4b Mon Sep 17 00:00:00 2001 From: Michaela Iorga <13984545+iMichaela@users.noreply.github.com> Date: Thu, 5 Mar 2020 01:40:53 -0500 Subject: [PATCH 02/10] More progress made on the tutorial --- docs/tutorials/catalog/Catalog Sample.xml | 4 +- docs/tutorials/catalog/Catalog Tutorial.md | 213 ++++++++++++++++++--- 2 files changed, 185 insertions(+), 32 deletions(-) diff --git a/docs/tutorials/catalog/Catalog Sample.xml b/docs/tutorials/catalog/Catalog Sample.xml index 2eea406eab..d42ecf82c6 100755 --- a/docs/tutorials/catalog/Catalog Sample.xml +++ b/docs/tutorials/catalog/Catalog Sample.xml @@ -1,13 +1,13 @@ - + Sample Security Catalog 2020-02-02T11:01:04.736-04:00 2020-10-02T11:01:04.736-04:00 1.0 1.0.0 - Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements + Assurance, computer security, FISM, security controls, security requirements Document creator diff --git a/docs/tutorials/catalog/Catalog Tutorial.md b/docs/tutorials/catalog/Catalog Tutorial.md index 29408e90b1..44d8631128 100644 --- a/docs/tutorials/catalog/Catalog Tutorial.md +++ b/docs/tutorials/catalog/Catalog Tutorial.md @@ -1,50 +1,203 @@ # OSCAL Catalog Tutorial -Prerequisite: [OSCAL Data Types](https://pages.nist.gov/OSCAL/documentation/schema/datatypes/) - ## What is an OSCAL Catalog ## Example of a Proprietary Catalog -An [OSCAL](https://www.nist.gov/oscal) Control Catalog is a machine-readable representation of a catalog of security controls which is a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. - -For the purpose of this tutorial, a proprietary catalog is created. The file is available for view or download [here](./Catalog Sample.pdf) - -## Reformatting the Control Catalog into an OSCAL Catalog (XML and JSON) -### Catalog Schemas - -The OSCAL Catalog Model can be used to describe a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. The [OSCAL](https://www.nist.gov/oscal) website provides comprehensive information about the [OSCAL Catalog Model](https://pages.nist.gov/OSCAL/documentation/schema/catalog/) +An [OSCAL](https://www.nist.gov/oscal) Control Catalog is a machine-readable representation of a *catalog of security controls* which is a collection of *security controls* and related *control enhancements*, along with contextualizing documentation and metadata. -There are two schemas for the Catalog Model: -- an XML Schema based on the [XML Schema Definition Language (XSD) 1.1](https://www.w3.org/TR/xmlschema11-1/) that describes the XML tag set for the OSCAL Catalog Model, and -- a JSON Schema based on the [JSON Schema Draft-07](https://json-schema.org/specification.html) that describes a JSON data object for the OSCAL Catalog Model. +For the purpose of this tutorial, a proprietary catalog is created. The file is available for download [here](./Catalog%20Sample.md) -The two schema files are listed below. The schemas are necessary to validate the content created in OSCAL. +## Formatting the Control Catalog into an OSCAL Catalog -| XML Schema | JSON Schema | -| :---------:|:---------:| -| [oscal_catalog_schema.xsd](https://github.com/usnistgov/OSCAL/blob/master/xml/schema/oscal_catalog_schema.xsd) | [oscal_catalog_schema.json](https://github.com/usnistgov/OSCAL/blob/master/json/schema/oscal_catalog_schema.json) | +The OSCAL Catalog Model supports representation of a *catalog of security controls* in either XML or JSON. +This tutorial describes the formatting of such catalog in XML. +The [OSCAL](https://www.nist.gov/oscal) website provides comprehensive information about the [OSCAL Catalog Model](https://pages.nist.gov/OSCAL/documentation/schema/catalog/) ### Control Catalog Model -This tutorial is not focusoing on the schemas themselves but rather on the formatting in OSCAL of a control catalog. For more detail information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/json-schema/), respectivly. +An OSCAL catalog (in XML or JSON) uses the respective schemas that describe the XML tag sets or the JSON data objects. +However, this tutorial is not focusing on the schemas themselves but rather on the formatting in OSCAL of the proprietary control catalog listed above. +For more detail information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/json-schema/), respectivly. -Current tutorial highlight only the high-level elements of the schemas, to give an overview of the problem. +The root of the Control Catalog format is `catalog`. The tag also captures the document's *universally unique identifier* (`uuid`), a unique 128-bit number made of hexadecimal digits dispalyed as 32 characters with four hyphens in between. - The root of the Control Catalog format is `catalog`. - -A `catalog` contains: -- `metadata` – mandatory to have one -- `groups` – may have none, or as many as necessary -- `controls` – may have none, or as many as necessary -- `back-matter` – may have none, or as many as necessary +```xml + + +``` -| ![Catalog elements](./Catalog_1_x_s.png) | ![Catalog elements](./Catalog_1_j_s.png) | +A `catalog` contains: -#### Catalog's Metadata -The `metadata` has identical structure for all OSCAL files. A separate tutorial is discussing all the elements of a `metadata`. This tutorial is only ilustrating the mandatory elements based on the information in the [Sample Security Catalog](./Catalog%20Sample.md) +- `metadata` – it is mandatory to have one metadata +- `groups` – may have none, or as many as necessary, and they can be nested +- `controls` – may have none, or as many as necessary, and they can be nested +- `back-matter` – may have none, or as many as necessary -#### Formatting a Control in OSCAL +Let's discuss each of these elements in the following sections and identify which ones can be used to represent our catalog. +#### Catalog's Metadata +The `metadata` has identical structure for all OSCAL files. + +A separate tutorial focuses on the elements of the `metadata`. +Current tutorial will only ilustrate next the mandatory elements used to represent the information available in the [Sample Security Catalog](./Catalog%20Sample.md) + +``` +# Sample Security Catalog + Version 1.0 + Published: 02.02.2020 + Last Modified: 02.10.2020 +``` +The `metadata` must include the `title` of the catalog using the tag. + +```xml + Sample Security Catalog +``` + +To represent the date when the document was published we use the tag . +The date needs to include the timezone. The published date is not a mandotory field for the `OSCAL Catalog` + +```xml + 2020-02-02T11:01:04.736-04:00 +``` + +The `OSCAL Catalog Model` requires the file to contain in the `metadata` the date and time with the timezone of the last modification of the file. This information is represented using the tag + +```xml + 2020-10-02T11:01:04.736-04:00 +``` + +Another mandatory field for the `metadata` is the `version` of the file which must be included using the tag / + +```xml + 1.0 +``` +Eventhough we finished representing the information available in the header of the file, the `metadata` has one other field that is mandatory - the OSCAL version. +Current OSCAL version is 1.0.0 and the tag is used to represent it. + +```xml + 1.0.0 +``` +When necessary, revision history can be also documented. See additional information [here](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-model-map/) + + +The `metadate` is also designed to accomodate the representation of other information related to the content of the catalog and the entity (individual or organization) that created it in OSCAL. +For example, we can select and represent *keywords* using the property tag , for which we define the `name` of the property as being *keywords*. +The *keywords* will be a `string` comprised of a comma-separated list of significant words, in alphabetical order. + +The information will look as follows: +```xml + Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements +``` + +To do so, one can use the tags and each instance with a distinct `id`, and the tag with the field `role-id` that identifies the id of the pointed role and the tag that points to the `id` of the defined . +In this example the is an organization (NIST) for which the name is provided using the tag , an email address is listed using hte tag and the URL using the tag . +Below is all this information assambled in OSCAL. + +```xml + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + +``` +We managed so far to complete the `metadata` of the [Sample Security Catalog](./Catalog%20Sample.md). +Putting together all the `metadata` information, we get: + +```xml + + Sample Security Catalog + 2020-02-02T11:01:04.736-04:00 + 2020-10-02T11:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + +``` + +#### Formatting the Body of the Control Catalog in OSCAL + +Analyzing the body of the [Catalog Sample](./Catalog%20Sample.md), we observe that the catalog has two sections: 1 and 2, each section contains subsections 1.1 and 2.1, which have an `Objective` and group together controls that meet the same `Objective`. +``` +1 Organization of Information Security + 1.1 Internal Organization + Objective: [...] + 1.1.1 Information security roles and responsibilities + [...] + 1.1.2 Segregation of duties + [...] +2 Access Control + 2.1 Business Requirements of Access Control + Objective: [...] + 2.1.1 Access control policy + [...] + 2.1.2 Access to networks and network services + [...] +``` +The above structure will be represented using nested `groups` for Section 1 with nested Subsection 1.1 and for Section 2 with nested Subsection 2.1. +A `group` tag has an `id` and a `class`. Each `group` must contain a title identified by the tag and may have `parameters` tagged with . +A group may also contain `parts` tagged with the label . + +``` + + Organization of Information Security + + Internal Organization + 1.1 + [...] + + + + Access control + + Business requirements of access control + 2.1 + [...] + + +``` + + +For each `Control`, the docuemnt provide also the `Implementation guidance` and often some additional information titled `Other information` + + - Control [skip] + - Implementation guidance [skip] + - Other information [skip] + +``` #### Formatting a Back-matter From c316b96b43496a8b4a96b0783ccdd9b01664fb1a Mon Sep 17 00:00:00 2001 From: Michaela Iorga <13984545+iMichaela@users.noreply.github.com> Date: Wed, 18 Mar 2020 21:16:24 -0400 Subject: [PATCH 03/10] Updates to Catalog Tutorial (back-matter and final catalog). --- docs/tutorials/catalog/Catalog Sample.xml | 26 +- docs/tutorials/catalog/Catalog Tutorial.md | 363 +++++++++++++++++++-- 2 files changed, 357 insertions(+), 32 deletions(-) diff --git a/docs/tutorials/catalog/Catalog Sample.xml b/docs/tutorials/catalog/Catalog Sample.xml index d42ecf82c6..611d97b052 100755 --- a/docs/tutorials/catalog/Catalog Sample.xml +++ b/docs/tutorials/catalog/Catalog Sample.xml @@ -30,6 +30,7 @@ Organization of Information Security + 1 Internal Organization 1.1 @@ -42,12 +43,12 @@ 1.1.1 c01 - Control + Control

All information security responsibilities should be defined and allocated.

 - Implementation guidance + Implementation guidance

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 @@ -64,7 +65,7 @@ and should determine that any delegated tasks have been correctly performed.

 - +

Areas for which individuals are responsible should be stated. In particular the following should take place:

    @@ -83,7 +84,7 @@ - Other information + Other information

    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.

    @@ -99,13 +100,13 @@ 1.1.2 c02 - Control + Control

    Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets.

     - Implementation guidance + Implementation guidance

    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.

     @@ -118,7 +119,7 @@     - Other information + Other information

    Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization’s assets.

     @@ -127,6 +128,7 @@ Access control + 2 Business requirements of access control 2.1 @@ -139,11 +141,11 @@ 2.1.1 c03 - Control + Control

    An access control policy should be established, documented and reviewed based on business and information security requirements.

     - Implementation guidance + Implementation guidance

    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.

     @@ -160,7 +162,7 @@
  1. policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information;
  2. consistency between the access rights and information classification policies of systems and networks;
  3. relevant legislation and any contractual obligations regarding limitation of access to data or services;
    4. -
  4. management of access rights in a distributed and networked environment which recognizes all types of connections available;
    5. +
  5. management of access rights in a distributed and networked environment which recognizes all types of connections availabel;
  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. @@ -171,7 +173,7 @@     - Other information + Other information

    Care should be taken when specifying access control rules to consider:

      @@ -201,7 +203,7 @@ 2.1.2 c04 - Control + Control

      Users should only be provided with access to the network and network services that they have been specifically authorized to use.

       diff --git a/docs/tutorials/catalog/Catalog Tutorial.md b/docs/tutorials/catalog/Catalog Tutorial.md index 44d8631128..bef30d563b 100644 --- a/docs/tutorials/catalog/Catalog Tutorial.md +++ b/docs/tutorials/catalog/Catalog Tutorial.md @@ -17,9 +17,11 @@ The [OSCAL](https://www.nist.gov/oscal) website provides comprehensive informati An OSCAL catalog (in XML or JSON) uses the respective schemas that describe the XML tag sets or the JSON data objects. However, this tutorial is not focusing on the schemas themselves but rather on the formatting in OSCAL of the proprietary control catalog listed above. -For more detail information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/json-schema/), respectivly. +For more detail information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) +and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/json-schema/), respectively. -The root of the Control Catalog format is `catalog`. The tag also captures the document's *universally unique identifier* (`uuid`), a unique 128-bit number made of hexadecimal digits dispalyed as 32 characters with four hyphens in between. +The root of the Control Catalog format is `catalog`. +The tag also captures the document's *universally unique identifier* (`uuid`), a unique 128-bit number made of hexadecimal digits displayed as 32 characters with four hyphens in between. ```xml @@ -37,10 +39,11 @@ A `catalog` contains: Let's discuss each of these elements in the following sections and identify which ones can be used to represent our catalog. #### Catalog's Metadata + The `metadata` has identical structure for all OSCAL files. A separate tutorial focuses on the elements of the `metadata`. -Current tutorial will only ilustrate next the mandatory elements used to represent the information available in the [Sample Security Catalog](./Catalog%20Sample.md) +Current tutorial will only illustrate next the mandatory elements used to represent the information available in the [Sample Security Catalog](./Catalog%20Sample.md) ``` # Sample Security Catalog @@ -55,7 +58,7 @@ The `metadata` must include the `title` of the catalog using the ``` To represent the date when the document was published we use the tag . -The date needs to include the timezone. The published date is not a mandotory field for the `OSCAL Catalog` +The date needs to include the time zone. The published date is not a mandatory field for the `OSCAL Catalog` ```xml 2020-02-02T11:01:04.736-04:00 @@ -72,7 +75,7 @@ Another mandatory field for the `metadata` is the `version` of the file which mu ```xml 1.0 ``` -Eventhough we finished representing the information available in the header of the file, the `metadata` has one other field that is mandatory - the OSCAL version. +Even though we finished representing the information available in the header of the file, the `metadata` has one other field that is mandatory - the OSCAL version. Current OSCAL version is 1.0.0 and the tag is used to represent it. ```xml @@ -81,7 +84,7 @@ Current OSCAL version is 1.0.0 and the tag is us When necessary, revision history can be also documented. See additional information [here](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-model-map/) -The `metadate` is also designed to accomodate the representation of other information related to the content of the catalog and the entity (individual or organization) that created it in OSCAL. +The `metadata` is also designed to accommodate the representation of other information related to the content of the catalog and the entity (individual or organization) that created it in OSCAL. For example, we can select and represent *keywords* using the property tag , for which we define the `name` of the property as being *keywords*. The *keywords* will be a `string` comprised of a comma-separated list of significant words, in alphabetical order. @@ -91,8 +94,8 @@ The information will look as follows: ``` To do so, one can use the tags and each instance with a distinct `id`, and the tag with the field `role-id` that identifies the id of the pointed role and the tag that points to the `id` of the defined . -In this example the is an organization (NIST) for which the name is provided using the tag , an email address is listed using hte tag and the URL using the tag . -Below is all this information assambled in OSCAL. +In this example the is an organization (NIST) for which the name is provided using the tag , an email address is listed using the tag and the URL using the tag . +Below is all this information assembled in OSCAL. ```xml @@ -103,7 +106,7 @@ Below is all this information assambled in OSCAL. - National Institute ofStandards and Technology + National Institute of Standards and Technology oscal@nist.gov https://www.nist.gov/oscal @@ -134,7 +137,7 @@ Putting together all the `metadata` information, we get: - National Institute ofStandards and Technology + National Institute of Standards and Technology oscal@nist.gov https://www.nist.gov/oscal @@ -150,7 +153,8 @@ Putting together all the `metadata` information, we get: #### Formatting the Body of the Control Catalog in OSCAL -Analyzing the body of the [Catalog Sample](./Catalog%20Sample.md), we observe that the catalog has two sections: 1 and 2, each section contains subsections 1.1 and 2.1, which have an `Objective` and group together controls that meet the same `Objective`. +Analyzing the body of the [Catalog Sample](./Catalog%20Sample.md), we observe that the catalog has two sections: +1 and 2, each section contains subsections 1.1 and 2.1, which have an *Objective* and group together *Controls* that meet the same *Objective*. ``` 1 Organization of Information Security 1.1 Internal Organization @@ -167,37 +171,356 @@ Analyzing the body of the [Catalog Sample](./Catalog%20Sample.md), we observe th 2.1.2 Access to networks and network services [...] ``` -The above structure will be represented using nested `groups` for Section 1 with nested Subsection 1.1 and for Section 2 with nested Subsection 2.1. -A `group` tag has an `id` and a `class`. Each `group` must contain a title identified by the tag and may have `parameters` tagged with . -A group may also contain `parts` tagged with the label . + +The above formatting of the document will be represented using nested `groups` for Section 1 with the nested Subsection 1.1 and for Section 2 with the nested Subsection 2.1. +A `group` tag has an `id` and a `class`. + +Each `group` must contain a `title` identified by the tag and may have none or many of the following elements: + +``` + * `parameters` identified by the tags + * `properties` identified by the tags , and + * `parts` identified by the tags . +``` + +It is important to note here that the `id` of a `group` is expected to be a string. + +The Sections of the original document have numbers, and therefore, we define the `id` for each `group` to be +the number of the Section and the Subsection respectively, with a leading character such as *s* in front. + +We also represent the numerical value of the Section and of the Subsection as a `property` named *label*. + +The structure of the Section 1 and the Subsection 1.1: + +``` +1 Organization of Information Security + 1.1 Internal Organization + [...] +``` + +could be represented as follows: ``` Organization of Information Security + 1 Internal Organization 1.1 [...] +``` + +Let us put together the high-level information for both Sections' and their Subsections': + +``` + + Organization of Information Security + 1 + + Internal Organization + 1.1 + [...] + + Access control + 2 Business requirements of access control 2.1 [...] - -``` + +``` +To represent the information of each Subsection, we need to identify the appropriate OSCAL elements for the *Objective* and the `Controls`. +An *Objective* can be represented as a `part` named *item*. +This `part` will also have an unique-to-the-document string `id` which can be used to reference the *Objective*. -For each `Control`, the docuemnt provide also the `Implementation guidance` and often some additional information titled `Other information` +An original *Objective* statement like the one below: - - Control [skip] - - Implementation guidance [skip] - - Other information [skip] +``` +Objective: To establish a management framework [...] within the organization. +``` +is represented as follows: ``` + + Objective: +

      To establish a management framework [...] within the organization.

      +       +``` + +Integrating the *Objective* into the above structure of the *Sample Security Catalog*, we get: + +``` + + Organization of Information Security + 1 + + Internal Organization + 1.1 + + Objective: +

      To establish a management framework [...] within the organization.

      +       + [...] +       +       +``` + +Following the *Objective*, the *Sample Security Catalog* describes the related *Controls*, their *Implementation guidance* and often +some additional information titled *Other information*. + +The structure of the first control, *1.1.1 Information security roles* is represented below: + +``` + 1.1.1 Information security roles + Control + All information security [...]. + Implementation guidance + Allocation of information security [...] + Other information + Many organizations appoint an [...] +``` + +To represent a *Control* and its content, the OSCAL element `control` identified by the tag is used. +The element `control` must have a , and it may have none or many of the following elements: + +``` + * `parameter` identified by the tags , + * `property` identified by the tags , + * `annotation` identified by the tags , + * `link` identified by the tags , and + * `part` identified by the tags . +``` + +Using the OSCAL elements in the same manner as for the `group`, the first *Control* in the *Sample Security Catalog* can be +represented as below: + +``` + + Information security roles and responsibilities + 1.1.1 + c01 + + Control +

      All information security [...].

      +       + + Implementation guidance + +

      Allocation of information security [...]

      +       + [...] +       + + Other information +

      Many organizations appoint an [...]

      +       +       +``` + +A similar approach of expressing the data is used to reformat the rest of all the `Controls` (1.1.2, 2.1.1 and 2.2.1) + #### Formatting a Back-matter +Often documents have references, links to other documents, diagrams/images, citations, remarks. +OSCAL defines elements that can be used to represent such information. + +Back-matters are optional elements and therefore often the OSCAL Catalogs will not contain any. + +A back-matter element is identified by the tag . +This element may have `resources` which are identified with the tag . + +Each `resource` may have: + +``` + * `title` identified by the tags + * `description` identified by the tags + * `property` identified by the tags + * `document id` identified by the tags + * `citation` identified by the tags + * `link` identified by the tags + * `base64-binary-data` identified by the tags + * `remarks` identified by the tags +``` +Our catalog does not contain any back-matter, but additional information about the available +elements and their fields, can be found [here](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-model-map/) + +### The Final Catalog + +Assembling all the elements described above, we obtain the arching structure of the *Sample Security Catalog*: + +``` + + + + Sample Security Catalog + 2020-02-02T11:01:04.736-04:00 + 2020-10-02T11:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISM, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + Organization of Information Security + + Internal Organization + 1.1 + + Objective: +

      To establish a management framework to initiate and control the implementation and operation of information security within the organization.

      +       + + Information security roles and responsibilities + 1.1.1 + c01 + + Control +

      All information security responsibilities should be defined and + allocated.

      +       + + Implementation guidance + +

      Allocation of information security [...]

      +       + +

      Individuals with allocated information [...].

      +       + +

      Areas for which individuals are [...]

      + [...] +       +       + + Other information +

      Many organizations [...].

      + +       +       + + Segregation of duties + 1.1.2 + c02 + + Control +

      Conflicting duties [...]

      +       + + Implementation guidance + +

      Care should be taken [...].

      +       + +

      Small organizations may [...].

      +       +       + + Other information +

      Segregation of duties is [...].

      +       +       +       +       + + Access control + + Business requirements of access control + 2.1 + + Objective: +

      To limit access to information and information processing facilities.

      +       + + Access control policy + 2.1.1 + c03 + + Control +

      An access control policy should [...].

      +       + + Implementation guidance + +

      Asset owners should determine [...].

      +       + +

      Access controls are both logical and physical [...].

      +       + +

      Users and service providers should [...].

      +       + +

      The policy should take account of the following:

      + [...] +       +       + + Other information + +

      Care should be taken [...]

      + [...] +       + +

      Access control rules should [...].

      +       + +

      Role based access control is [...].

      +       + +

      Two of the frequent principles [...]:

      + [...] +       +       +       + + Access to networks and network services + 2.1.2 + c04 + + Control +

      Users should only be provided [...].

      +       + + Implementation guidance + +

      A policy should be [...]

      + [...] +       + +

      The policy on the use of network [...]

      +       +       +       +       +       + + +       +``` + From f1dea04449afd1f5f952211746393219b80b1871 Mon Sep 17 00:00:00 2001 From: Michaela Iorga <13984545+iMichaela@users.noreply.github.com> Date: Thu, 19 Mar 2020 01:57:04 -0400 Subject: [PATCH 04/10] Created Profile Sample --- docs/tutorials/profile/Profile Sample.md | 80 ++++++++++++++++++++ docs/tutorials/profile/Profile Sample.xml | 92 +++++++++++++++++++++++ 2 files changed, 172 insertions(+) create mode 100644 docs/tutorials/profile/Profile Sample.md create mode 100644 docs/tutorials/profile/Profile Sample.xml diff --git a/docs/tutorials/profile/Profile Sample.md b/docs/tutorials/profile/Profile Sample.md new file mode 100644 index 0000000000..5ca1245838 --- /dev/null +++ b/docs/tutorials/profile/Profile Sample.md @@ -0,0 +1,80 @@ + + +# Sample Security Profile A + Version 1.0 + Published: 03.10.2020 + Last Modified: 03.18.2020 + + +# Controls from the Sample Security Catalog + +The following controls are imported from the [Sample Security Catalog](https://github.com/iMichaela/OSCAL/blob/master/docs/tutorials/catalog/Catalog%20Tutorial.md) +version 1.0. When applicable, and additional requirements or implementation guidance are provided. + +## 1 Organization of Information Security + +### 1.1 Internal Organization + +#### 1.1.1 Information security roles and responsibilities + + +**Implementation guidance** + +**ADDED**: The organizations should identify critical information system assets supporting essential missions and business functions. + +**Other information** + +**ADDED**: The appointed owners of the assets should report {organization-defined frequency} the results of assets' security verification +to the information secuirty manager. + + +## 2 Access Control + +### 2.1 Business Requirements of Access Control + +**Objective:** To limit access to information and information processing facilities. + +#### 2.1.1 Access control policy + +**Implementation guidance** + +**ADDED**: Organizations should develop, document, and disseminate to {organization-defined personnel or roles}: +a) An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and +b) Procedures to facilitate the implementation of the access control policy and associated access controls; and + +**Other information** + +**MODIFIED**: Role-based or atribute-based access control are approaches used successfully by many organizations to link access rights +with business roles. + +#### 2.1.2 Access to networks and network services + +**Implementation guidance** + +**ADDED**: The users should be informed of the policy restrictions by displaying a {organization-define message or banner } +before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance + +# Controls from the NIST SP 800-53 + +The following controls are imported from the [NIST SP 800-53 rev4](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf) + +## Family: Access Control + +### AC-2 Account Management + +**ADDED**: AC-2.a {Assignment: 'at least annualy'} + +### AC-2(5) Account Management | Inactivity Logout + +**ADDEDD**: Supplemental Guidance: The organization-defined time-period of inactivity should be shorter +than the session termination or disconnect set by AC-12. + +### AC-2(12) Account Management | Account Monitoring/Atypical Usage + +**ADDED**: a) Supplemental Guidance: The control enhancement should be implemented for all priviliged accounts. + +**ADDED**: b) Supplemental Guidance: The control enhancement should be implemented for all priviliged accounts. + +### AC-12 Session Termination + +**ADDED**: AC-12 {Assignment: '20 min of innactivity'} \ No newline at end of file diff --git a/docs/tutorials/profile/Profile Sample.xml b/docs/tutorials/profile/Profile Sample.xml new file mode 100644 index 0000000000..5a66252eb0 --- /dev/null +++ b/docs/tutorials/profile/Profile Sample.xml @@ -0,0 +1,92 @@ + + + + Sample Security Catalog + 2020-03-18T11:01:04.736-04:00 + 2020-03-18T11:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISM, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + + + + + + + + + + + + + + + + + true + + + + + + at least annually + + + + + + + + + + + AC-2 (5) Additional Sample Profile Requirements and Guidance + + Supplemental Guidance: +

      The control enhancement should be implemented for all priviliged accountsThe organization-defined time-period of inactivity should be shorter + than the session termination or disconnect set by AC-12

      +       +       +       +       + + + + + AC-2 (12) Additional Sample Profile Requirements and Guidance + + (a) Supplemental Guidance: +

      The control enhancement should be implemented for all priviliged accounts.

      +       + + (b) Supplemental Guidance: +

      The control enhancement should be implemented for all priviliged accounts.

      +       +       +       +       +       + + From 941364bd178bd178e9b14cf2c3e8b06199abb20c Mon Sep 17 00:00:00 2001 From: Michaela Iorga <13984545+iMichaela@users.noreply.github.com> Date: Thu, 26 Mar 2020 02:08:08 -0400 Subject: [PATCH 05/10] minor changes in catalog tutorial and added new profile tutorial. --- docs/tutorials/profile/Profile Sample.md | 80 ---- docs/tutorials/profile/Profile Sample.xml | 92 ---- .../profile/Profile-SelectAll Sample.md | 34 ++ .../profile/Profile-SelectAll Sample.xml | 76 ++++ .../profile/Profile-SelectAll Tutorial.md | 422 ++++++++++++++++++ .../profile/Profile-SelectSpecific Sample.md | 21 + .../Profile-SelectSpecific Sample_method1.xml | 50 +++ .../Profile-SelectSpecific Sample_method2.xml | 50 +++ .../Profile-SelectSpecific Tutorial.md | 173 +++++++ 9 files changed, 826 insertions(+), 172 deletions(-) delete mode 100644 docs/tutorials/profile/Profile Sample.md delete mode 100644 docs/tutorials/profile/Profile Sample.xml create mode 100644 docs/tutorials/profile/Profile-SelectAll Sample.md create mode 100644 docs/tutorials/profile/Profile-SelectAll Sample.xml create mode 100644 docs/tutorials/profile/Profile-SelectAll Tutorial.md create mode 100644 docs/tutorials/profile/Profile-SelectSpecific Sample.md create mode 100644 docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml create mode 100644 docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml create mode 100644 docs/tutorials/profile/Profile-SelectSpecific Tutorial.md diff --git a/docs/tutorials/profile/Profile Sample.md b/docs/tutorials/profile/Profile Sample.md deleted file mode 100644 index 5ca1245838..0000000000 --- a/docs/tutorials/profile/Profile Sample.md +++ /dev/null @@ -1,80 +0,0 @@ - - -# Sample Security Profile A - Version 1.0 - Published: 03.10.2020 - Last Modified: 03.18.2020 - - -# Controls from the Sample Security Catalog - -The following controls are imported from the [Sample Security Catalog](https://github.com/iMichaela/OSCAL/blob/master/docs/tutorials/catalog/Catalog%20Tutorial.md) -version 1.0. When applicable, and additional requirements or implementation guidance are provided. - -## 1 Organization of Information Security - -### 1.1 Internal Organization - -#### 1.1.1 Information security roles and responsibilities - - -**Implementation guidance** - -**ADDED**: The organizations should identify critical information system assets supporting essential missions and business functions. - -**Other information** - -**ADDED**: The appointed owners of the assets should report {organization-defined frequency} the results of assets' security verification -to the information secuirty manager. - - -## 2 Access Control - -### 2.1 Business Requirements of Access Control - -**Objective:** To limit access to information and information processing facilities. - -#### 2.1.1 Access control policy - -**Implementation guidance** - -**ADDED**: Organizations should develop, document, and disseminate to {organization-defined personnel or roles}: -a) An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and -b) Procedures to facilitate the implementation of the access control policy and associated access controls; and - -**Other information** - -**MODIFIED**: Role-based or atribute-based access control are approaches used successfully by many organizations to link access rights -with business roles. - -#### 2.1.2 Access to networks and network services - -**Implementation guidance** - -**ADDED**: The users should be informed of the policy restrictions by displaying a {organization-define message or banner } -before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance - -# Controls from the NIST SP 800-53 - -The following controls are imported from the [NIST SP 800-53 rev4](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf) - -## Family: Access Control - -### AC-2 Account Management - -**ADDED**: AC-2.a {Assignment: 'at least annualy'} - -### AC-2(5) Account Management | Inactivity Logout - -**ADDEDD**: Supplemental Guidance: The organization-defined time-period of inactivity should be shorter -than the session termination or disconnect set by AC-12. - -### AC-2(12) Account Management | Account Monitoring/Atypical Usage - -**ADDED**: a) Supplemental Guidance: The control enhancement should be implemented for all priviliged accounts. - -**ADDED**: b) Supplemental Guidance: The control enhancement should be implemented for all priviliged accounts. - -### AC-12 Session Termination - -**ADDED**: AC-12 {Assignment: '20 min of innactivity'} \ No newline at end of file diff --git a/docs/tutorials/profile/Profile Sample.xml b/docs/tutorials/profile/Profile Sample.xml deleted file mode 100644 index 5a66252eb0..0000000000 --- a/docs/tutorials/profile/Profile Sample.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - Sample Security Catalog - 2020-03-18T11:01:04.736-04:00 - 2020-03-18T11:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISM, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - - - - - - - - - - - - - - - - - true - - - - - - at least annually - - - - - - - - - - - AC-2 (5) Additional Sample Profile Requirements and Guidance - - Supplemental Guidance: -

      The control enhancement should be implemented for all priviliged accountsThe organization-defined time-period of inactivity should be shorter - than the session termination or disconnect set by AC-12

      -       -       -       -       - - - - - AC-2 (12) Additional Sample Profile Requirements and Guidance - - (a) Supplemental Guidance: -

      The control enhancement should be implemented for all priviliged accounts.

      -       - - (b) Supplemental Guidance: -

      The control enhancement should be implemented for all priviliged accounts.

      -       -       -       -       -       - - diff --git a/docs/tutorials/profile/Profile-SelectAll Sample.md b/docs/tutorials/profile/Profile-SelectAll Sample.md new file mode 100644 index 0000000000..8c0cecce20 --- /dev/null +++ b/docs/tutorials/profile/Profile-SelectAll Sample.md @@ -0,0 +1,34 @@ +# Sample Security Profile + +## Case 1: Sellect All Controls + + Version 1.0 + Published: 03.24.2020 + Last Modified: 03.24.2020 + + +This profile imports all the security controls defined in the [Sample Security Catalog](../catalog/Catalog%20Sample.md), version 1.0, and *tailors* (modifies) control **1.1.1** to add additional *implementation guidance* and additional *information*. + +### List of Controls + +#### 1.1.1 Information security roles and responsibilities + +**Implementation guidance** + +**ADDED**: The organizations should identify critical information system assets supporting essential missions and business functions. + +**Other information** + +**ADDED**: The appointed owners of the assets should report {organization-defined frequency} the results of assets' security verification +to the information secuirty manager. + + +#### 1.1.2 Segregation of duties + + +#### 2.1.1 Access control policy + + +#### 2.1.2 Access to networks and network services + + diff --git a/docs/tutorials/profile/Profile-SelectAll Sample.xml b/docs/tutorials/profile/Profile-SelectAll Sample.xml new file mode 100644 index 0000000000..f0aa5607fe --- /dev/null +++ b/docs/tutorials/profile/Profile-SelectAll Sample.xml @@ -0,0 +1,76 @@ + + + + Sample Security Profile - Select All Controls + 2020-03-24T11:01:04.736-04:00 + 2020-03-24T11:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + + + + + true + + + + + + + + 1.1.1 Additional Sample Profile Requirements and Guidance + + Implementation Guidance: +

      The organizations should identify critical information system assets supporting essential missions and business functions.

      +       +       +       + + + 1.1.1 Additional Sample Profile Requirements and Guidance + + Other Information: +

      The appointed owners of the assets must report the results of assets' security verification + to the information security manager.

      +       +       +       +       + + + +       + + + Catalog Sample (Derived from ISO/IEC 27002) + + + +       + + + diff --git a/docs/tutorials/profile/Profile-SelectAll Tutorial.md b/docs/tutorials/profile/Profile-SelectAll Tutorial.md new file mode 100644 index 0000000000..4127486ecb --- /dev/null +++ b/docs/tutorials/profile/Profile-SelectAll Tutorial.md @@ -0,0 +1,422 @@ +# OSCAL Profile Tutorial + +## What is an OSCAL Profile + +The OSCAL Profile layer defines a [model](https://pages.nist.gov/OSCAL/documentation/schema/profile/) for selecting a specific set of security +control requirements from one or more control catalogs. The term *profile* in OSCAL +is also called a *baseline* in the NIST SP 800-53 catalog or in FedRAMP's documentation. +Additionally, the term *profile* in OSCAL covers the overlay concept defined in the +NIST SP 800-53 catalog allowing for further tailoring of controls, modification of the requirements, +customization, interpretation and parameter values assignment. + +An OSCAL Profiles can be based on one or more catalogs of controls, or on other OSCAL Profiles. + [OSCAL](https://www.nist.gov/oscal) website provides comprehensive information about the [OSCAL Profile Model](https://pages.nist.gov/OSCAL/documentation/schema/profile/) + +Current tutorial focuses solely on a proprietary profile that **selects all the controls** from a catalog of security controls. +The catalog of security controls used in this tutorial is the [Sample Security Catalog](../catalog/Catalog%20Tutorial.md), version 1.0, created for educational purpose. +The profile also *tailors* (modifies) control **1.1.1** to add additional *implementation guidance* and additional *information*. +This profile can be viewed [here](./Profile-SelectAll%20Sample.md). + +## Formatting the Profile into an OSCAL Profile + +The OSCAL Model supports representation of a *profile* in either XML or JSON. +This tutorial describes the formatting of such *profile* in XML. + +### Profile Catalog Model + +An `OSCAL Profile` (in XML or JSON) uses the respective schemas that describe the XML tag sets or the JSON data objects. +However, this tutorial is not focusing on the schemas themselves but rather on the formatting in OSCAL of the *profile* described above. +For more information on each *profile* schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/profile/xml-schema/) +and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/profile/json-schema/), respectively. + +The root of the Profile format is `profile`. +The tag also captures the document's *universally unique identifier* (`uuid`), a unique 128-bit number made of hexadecimal digits displayed as 32 characters with four hyphens in between. + +```xml + + +``` + +A `profile` contains: + +- `metadata` – it is mandatory to have one metadata +- `imports` – may have none, or as many as necessary +- `merge` – may have none, or as many as necessary +- `modify` - may have none, or as many as necessary +- `back-matter` – may have none, or as many as necessary + +Let's discuss each of these elements in the following sections and identify which ones can be used to represent our catalog. + +#### Profile's Metadata + +The `metadata` has identical structure for all OSCAL files. + +A separate tutorial focuses on the elements of the `metadata`. +Current tutorial will only illustrate next the mandatory elements used to represent the information available in the [Sample Security Catalog](./Catalog%20Sample.md) + +``` +# Sample Security Profile + +## Case 1: Sellect All Controls + + Version 1.0 + Published: 03.24.2020 + Last Modified: 03.24.2020 +``` +The `metadata` must include the `title` of the *profile* using the `` tag. + +```xml + Sample Security Profile - Select All Controls +``` + +To represent the date when the document was published we use the tag ``. +The date needs to include the time zone. The published date is not a mandatory field for the `OSCAL Profile` + +```xml + 2020-03-24T11:01:04.736-04:00 +``` + +The `OSCAL Profile Model` requires the file to contain in the `metadata` the date and time with the timezone of the last modification of the file. +This information is represented using the tag `` + +```xml + 2020-03-24T11:01:04.736-04:00 +``` + +Another mandatory field for the `metadata` is the `version` of the file which must be included using the tag `/`. + +```xml + 1.0 +``` +Even though we finished representing the information available in the header of the file, the `metadata` has one other field that is mandatory - the OSCAL version. +Current OSCAL version is 1.0.0 and the tag `` is used to represent it. + +```xml + 1.0.0 +``` +When necessary, revision history can be also documented. See additional information [here](https://pages.nist.gov/OSCAL/documentation/schema/profile/xml-model-map/) + + +The `metadata` is also designed to accommodate the representation of other information related to the content of the *profile* and the entity (individual or organization) that created it in OSCAL. +For example, we can select and represent *keywords* using the property tag ``, for which we define the `name` of the property as being *keywords*. +The *keywords* will be a `string` comprised of a comma-separated list of significant words, in alphabetical order. + +The information will look as follows: +```xml + Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements +``` + +To do so, one can use the tags `` and ``, each instance with a distinct `id`, and the tag `` with the field `role-id` that identifies the id of the pointed role and the tag `` that points to the `id` of the defined . +In this example the `` is an organization (NIST) for which the name is provided using the tag ``, an email address is listed using the tag `` and the URL using the tag ``. +Below is all this information assembled in OSCAL. + +```xml + + Document creator + + + Contact + + + + National Institute of Standards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + +``` +We managed so far to complete the `metadata` of the [OSCAL Profile-SelectAll Sample](./Profile-SelectAll%20Sample.md). + +Putting together all the `metadata` information, we get: + +```xml + + Sample Security Profile - Select All Controls + 2020-03-24T11:01:04.736-04:00 + 2020-03-24T11:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + +``` + +#### Formatting the Body of the OSCAL Profile + +We discussed earlier that this [OSCAL Profile Sample](./Profile-SelectAll%20Sample.md) selects all the controls from the catalog. +The `OSCAL Profile` model defines the `` element that designates the catalog, profile or resources from where the controls are selected. +The element has the following content: +- `href` - a required field that provides the URL of the referred resource +- `include` - used to specify the controls included, and can be used as many times as needed or not used at all +- `exclude` - used to specify de-select controls, and can be used as many times as needed or not used at all +Since an `include/all` (that is, all controls will be included by default) is assumed in the `OSCAL Profile` model when no `` +is given, we will use this default feature to generate our profile. +Also, because our `Catalog` does not have nested `controls`, we will not need to explicitly `import/all` +controls and explicitly set the `with-child-controls` flag. + +The selection of all controls from the catalog can be simply represented as follows: + +```xml + + +``` +In general, after selecting the controls, it is important to be able to merge them in resolution. +For this purpose, OSCAL has the `` element that can be used to `combine` the controls and structure them the + same way they are structured in the `Catalog`, by using the flag `as-is`, or provide a `custom` structure. + + In our case, we will structure the controls the same way they were structured in the `Catalog`. + + ```xml + + true + +``` + +As owners of the profile, we identified that the `Control` **1.1.1** with the `id=s1.1.1` requires modifications or tayloring. +To specify the changes we need to make to the control, we will use the `` element which allows us +to `` and `` statements of the control. Our controls do not have parameters. + +We will use the `` element and specify the `control-id` to indicate the control that is being modified. + +```xml + + [...] + +``` + +The element `` allows to: +- `remove` - by using the tag `` +- `add` - by using the tag `` + +In our case, we are not removing any statement form the control, but would like to add information at the end of the existing paragraph. +The first statement we want to add will be appended to the **Implementation guidance** of the `Control` with ID `control-id=s1.1.1` + +```xml + + [...] + +``` + +The second statement we want to add will be appended to the **Other information** section of the `Control` with ID `control-id=s1.1.1` + +```xml + + [...] + +``` +Putting together the formationg discussed so far for altering or tailoring a control, we obtain: + +```xml + + + [...] + + + [...] + + +``` + +The statement appended to the **Implementation guidance** reads: *The organizations should identify critical information system assets supporting essential missions and business functions.* +This statement will be introduced using the element `` which has been previously introduced in the Catalog tutorial. + +The element's description is available [here](https://pages.nist.gov/OSCAL/documentation/schema/profile/xml-schema/#part) + +Through this element, we will provide the required `id` and `name` for the statement, +a `` for the modification and the added statement itself itself as a nested `<part>`, as follows: + +```xml + <part id="s1.1.1_smp_gnd" name="item" ns="sample"> + <title>1.1.1 Additional Sample Profile Requirements and Guidance + + Implementation Guidance: +

      The organizations should identify critical information system assets supporting essential missions and business functions.

      +       +       +``` + +In a similar way is also represented the statement appended to the **Other Information** that +reads: *The appointed owners of the assets must report the results of assets' security verification to the information security manager.* + +```xml + + 1.1.1 Additional Sample Profile Requirements and Guidance + + Other Information: +

      The appointed owners of the assets must report the results of assets' security verification + to the information security manager.

      +       +       +``` +Putting gother the 2 added statements, the tailoring of the `Control` **1.1.1** looks like: + +```xml + + + + 1.1.1 Additional Sample Profile Requirements and Guidance + + Implementation Guidance: +

      The organizations should identify critical information system assets supporting essential missions and business functions.

      +       +       +       + + + 1.1.1 Additional Sample Profile Requirements and Guidance + + Other Information: +

      The appointed owners of the assets must report the results of assets' security verification + to the information security manager.

      +       +       +       +       +``` + +#### Formatting a Back-matter + +Often documents have references, links to other documents, diagrams/images, citations, remarks. +OSCAL defines elements that can be used to represent such information. + +Back-matters are optional elements and therefore often the OSCAL Catalogs will not contain any. + +A back-matter element is identified by the tag . +This element may have `resources` which are identified with the tag . + +Each `resource` may have: + +``` + * `title` identified by the tags + * `description` identified by the tags + * `property` identified by the tags + * `document id` identified by the tags + * `citation` identified by the tags + * `link` identified by the tags + * `base64-binary-data` identified by the tags + * `remarks` identified by the tags +``` +Additional information about the available +elements and their fields, can be found [here](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-model-map/) + +In our case, the `Profile` does not have specific information for the back-matter, but we can observe that the information +of the `Catalog` can be included in the back-matter as follows: + +```xml + + + Catalog Sample (Derived from ISO/IEC 27002) + + + +``` +With the `Catalog` defined here, the catalog id can be used as `uri` in the `` elemet. + +```xml + + +``` + +### The Final Profile + +Assembling all the elements described above, we obtain the arching structure of the *Profile SelectAll Sample*: + +```xml + + + + Sample Security Profile - Select All Controls + 2020-03-24T11:01:04.736-04:00 + 2020-03-24T11:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + + + true + + + + + + + + 1.1.1 Additional Sample Profile Requirements and Guidance + + Implementation Guidance: +

      The organizations should identify critical information system assets supporting essential missions and business functions.

      +       +       +       + + + 1.1.1 Additional Sample Profile Requirements and Guidance + + Other Information: +

      The appointed owners of the assets must report the results of assets' security verification + to the information security manager.

      +       +       +       +       + + + +       + + + Catalog Sample (Derived from ISO/IEC 27002) + + + +       +``` + + diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample.md b/docs/tutorials/profile/Profile-SelectSpecific Sample.md new file mode 100644 index 0000000000..3d162c51c9 --- /dev/null +++ b/docs/tutorials/profile/Profile-SelectSpecific Sample.md @@ -0,0 +1,21 @@ +# Sample Security Profile + +## Case 2: Select Specific Controls + + Version 1.0 + Published: 03.24.2020 + Last Modified: 03.24.2020 + + +This profile imports two of the security controls defined in the [Profile SelectAll Sample](./Profile-SelectAll%20Sample.md), version 1.0. + +### List of Controls + +#### 1.1.1 Information security roles and responsibilities + +#### 2.1.1 Access control policy + + + + + diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml b/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml new file mode 100644 index 0000000000..cfb69056c7 --- /dev/null +++ b/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml @@ -0,0 +1,50 @@ + + + + Sample Security Profile - Select Specific Controls - Method 1 + 2020-03-24T12:01:04.736-04:00 + 2020-03-24T12:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + + + + + + + + true + + + + Profile SelectAll Sample (Derived from ISO/IEC 27002) + + + + + + + diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml b/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml new file mode 100644 index 0000000000..e08bd11382 --- /dev/null +++ b/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml @@ -0,0 +1,50 @@ + + + + Sample Security Profile - Select Specific Controls - Method 2 + 2020-03-24T12:30:04.736-04:00 + 2020-03-24T12:30:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + + + + + + + + true + + + + Profile SelectAll Sample (Derived from ISO/IEC 27002) + + + + + + + diff --git a/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md b/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md new file mode 100644 index 0000000000..9c2caee658 --- /dev/null +++ b/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md @@ -0,0 +1,173 @@ +# OSCAL Profile Tutorial - Part2 + +## Generating a Profile By Explicitly Selecting Controls + +**Prerequisite:** [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) + +We introduced in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) the +`OSCAL Profile` and highlighed that "OSCAL Profiles can be based on one or more +catalogs of controls, or on other OSCAL Profiles." + +In this tutorial we will discuss the formating in OSCAL of the a *profile* that contains a subset of +controls existing in the [Profile SelectAll Sample](./Profile-SelectAll%20Sample.md). + +## Formatting the Profile into an OSCAL Profile + +The OSCAL Model supports representation of a *profile* in either XML or JSON. +This tutorial describes the formatting of such *profile* in XML. + +### Profile Catalog Model + +For the sake of brevity, the formating of the `metadata`, will not discuss again in this tutorial. +The redear is referred to the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md), section ** Profile's Metadata**. + +We will illustrate in this tutorial 2 distinct approached of generating this new [Profile-SelectSpecific%20Sample.md](./Profile-SelectAll%20Sample.md): + +- by including all the controls using the same approach described in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) and then excluding explicitly the controls that are not needed. +- by explicitly including only the desired controls. + +#### Method 1 + +In the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) we described the element ``, and +used the default `include/all` assumption of the element when no specific `` is specified. + +In this method of generating the `OSCAL Profile` we will use the same approach of importing all +controls (modifications include ) from the [Profile-SelectAll%20Sample.md](./Profile-SelectAll%20Sample.md), and +exclude the non-desire controls indicating them specifically. + +```xml + + + + + + + +``` +The rest of the [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) is generated identical to the +[OSCAL Profile SelectAll Sample](./Profile-SelectAll%20Sample.xml). + +It is important to note that the modifications done to the `Control` **1.1.1** will be +available in the current `Profile` too, if no other changes are deemed necessary.. + +The overall OSCAL Profile with this method will become: + +```xml + + + Sample Security Profile - Select Specific Controls - Method 1 + 2020-03-24T12:01:04.736-04:00 + 2020-03-24T12:01:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + + + + + + + + true + + + + Profile SelectAll Sample (Derived from ISO/IEC 27002) + + + + +``` + +#### Method 2 + +The same [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) can be obtained in OSCAL +by explicitly including the desired controls from the [Profile SelectAll Sample](./Profile-SelectAll%20Sample.xml). + +We need to reiterate that the `import/all` default assumption is no longer applicable if the `` element is invoked. +Therefore, we will have to explicitly list all controls that are needed. + +```xml + + + + + + + +``` +Putting together the other parts of the `OSCAL Profile` (`metadata`, `merge`, `back-matter`) +as described in the [Profile-SelectAll Tutorial](./Profile-SelectAl%20Tutorial.md), the +the [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) can be represented in OSCAL as follows: + +```xml + + + + Sample Security Profile - Select Specific Controls - Method 2 + 2020-03-24T12:30:04.736-04:00 + 2020-03-24T12:30:04.736-04:00 + 1.0 + 1.0.0 + Assurance, computer security, FISMA, security controls, security requirements + + Document creator + + + Contact + + + + National Institute ofStandards and Technology + oscal@nist.gov + https://www.nist.gov/oscal + + + + NIST + + + NIST + + + + + + + + + + + true + + + + Profile SelectAll Sample (Derived from ISO/IEC 27002) + + + + +``` \ No newline at end of file From 58b79ca1e46c05f7041f641cce459da70e3d5ec7 Mon Sep 17 00:00:00 2001 From: Michaela Iorga <13984545+iMichaela@users.noreply.github.com> Date: Thu, 26 Mar 2020 02:13:22 -0400 Subject: [PATCH 06/10] minor updates to catalog sample and tutorial. --- docs/tutorials/catalog/Catalog Sample.md | 6 ++++-- docs/tutorials/catalog/Catalog Sample.xml | 10 ++++++---- docs/tutorials/catalog/Catalog Tutorial.md | 20 ++++++++++---------- 3 files changed, 20 insertions(+), 16 deletions(-) diff --git a/docs/tutorials/catalog/Catalog Sample.md b/docs/tutorials/catalog/Catalog Sample.md index 17d2e603fb..64b2c4310f 100644 --- a/docs/tutorials/catalog/Catalog Sample.md +++ b/docs/tutorials/catalog/Catalog Sample.md @@ -32,8 +32,10 @@ g) coordination and oversight of information security aspects of supplier relati **Other information** -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. +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. #### 1.1.2 Segregation of duties diff --git a/docs/tutorials/catalog/Catalog Sample.xml b/docs/tutorials/catalog/Catalog Sample.xml index 611d97b052..a5c2bd6415 100755 --- a/docs/tutorials/catalog/Catalog Sample.xml +++ b/docs/tutorials/catalog/Catalog Sample.xml @@ -1,13 +1,13 @@ + id="uuid-956c32af-8a15-4732-a4d9-f976a1149c4b"> Sample Security Catalog 2020-02-02T11:01:04.736-04:00 - 2020-10-02T11:01:04.736-04:00 + 2020-02-10T11:01:04.736-04:00 1.0 1.0.0 - Assurance, computer security, FISM, security controls, security requirements + Assurance, computer security, FISMA, security controls, security requirements Document creator @@ -51,7 +51,9 @@ Implementation guidance

      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 + 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 diff --git a/docs/tutorials/catalog/Catalog Tutorial.md b/docs/tutorials/catalog/Catalog Tutorial.md index bef30d563b..ff8f0c921e 100644 --- a/docs/tutorials/catalog/Catalog Tutorial.md +++ b/docs/tutorials/catalog/Catalog Tutorial.md @@ -17,7 +17,7 @@ The [OSCAL](https://www.nist.gov/oscal) website provides comprehensive informati An OSCAL catalog (in XML or JSON) uses the respective schemas that describe the XML tag sets or the JSON data objects. However, this tutorial is not focusing on the schemas themselves but rather on the formatting in OSCAL of the proprietary control catalog listed above. -For more detail information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) +For more information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/json-schema/), respectively. The root of the Control Catalog format is `catalog`. @@ -85,7 +85,7 @@ When necessary, revision history can be also documented. See additional informat The `metadata` is also designed to accommodate the representation of other information related to the content of the catalog and the entity (individual or organization) that created it in OSCAL. -For example, we can select and represent *keywords* using the property tag , for which we define the `name` of the property as being *keywords*. +For example, we can select and represent *keywords* using the property tag ``, for which we define the `name` of the property as being *keywords*. The *keywords* will be a `string` comprised of a comma-separated list of significant words, in alphabetical order. The information will look as follows: @@ -93,8 +93,8 @@ The information will look as follows: Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements ``` -To do so, one can use the tags and each instance with a distinct `id`, and the tag with the field `role-id` that identifies the id of the pointed role and the tag that points to the `id` of the defined . -In this example the is an organization (NIST) for which the name is provided using the tag , an email address is listed using the tag and the URL using the tag . +To do so, one can use the tags ` and `` each instance with a distinct `id`, and the tag `` with the field `role-id` that identifies the id of the pointed role and the tag `` that points to the `id` of the defined ``. +In this example the `` is an organization (NIST) for which the name is provided using the tag ``, an email address is listed using the tag `` and the URL using the tag ``. Below is all this information assembled in OSCAL. ```xml @@ -173,9 +173,9 @@ Analyzing the body of the [Catalog Sample](./Catalog%20Sample.md), we observe th ``` The above formatting of the document will be represented using nested `groups` for Section 1 with the nested Subsection 1.1 and for Section 2 with the nested Subsection 2.1. -A `group` tag has an `id` and a `class`. +A `group` tag `` has an `id` and a `class`. -Each `group` must contain a `title` identified by the tag and may have none or many of the following elements: +Each `group` must contain a `title` identified by the tag `` and may have none or many of the following elements: ``` * `parameters` identified by the tags @@ -286,8 +286,8 @@ The structure of the first control, *1.1.1 Information security roles* is repres Many organizations appoint an [...] ``` -To represent a *Control* and its content, the OSCAL element `control` identified by the tag is used. -The element `control` must have a , and it may have none or many of the following elements: +To represent a *Control* and its content, the OSCAL element `control` identified by the tag `` is used. +The element `control` must have a ``, and it may have none or many of the following elements: ``` * `parameter` identified by the tags , @@ -332,8 +332,8 @@ OSCAL defines elements that can be used to represent such information. Back-matters are optional elements and therefore often the OSCAL Catalogs will not contain any. -A back-matter element is identified by the tag . -This element may have `resources` which are identified with the tag . +A back-matter element is identified by the tag ``. +This element may have `resources` which are identified with the tag ``. Each `resource` may have: From 31cffb43cf140101bac5fc312d14030afba0cd69 Mon Sep 17 00:00:00 2001 From: Michaela Iorga <13984545+iMichaela@users.noreply.github.com> Date: Fri, 27 Mar 2020 21:47:32 -0400 Subject: [PATCH 07/10] Updated profile tutorial part 2 to select controls form a catalog not profile. --- .../profile/Profile-SelectSpecific Sample.md | 2 +- .../Profile-SelectSpecific Sample_method1.xml | 8 ++-- .../Profile-SelectSpecific Sample_method2.xml | 8 ++-- .../Profile-SelectSpecific Tutorial.md | 46 +++++++++---------- 4 files changed, 31 insertions(+), 33 deletions(-) diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample.md b/docs/tutorials/profile/Profile-SelectSpecific Sample.md index 3d162c51c9..9b642ae8a7 100644 --- a/docs/tutorials/profile/Profile-SelectSpecific Sample.md +++ b/docs/tutorials/profile/Profile-SelectSpecific Sample.md @@ -7,7 +7,7 @@ Last Modified: 03.24.2020 -This profile imports two of the security controls defined in the [Profile SelectAll Sample](./Profile-SelectAll%20Sample.md), version 1.0. +This profile imports two of the security controls defined in the [Catalog Sample](../catalog/Catalog%20Sample.md), version 1.0. ### List of Controls diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml b/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml index cfb69056c7..8aa8ac1032 100644 --- a/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml +++ b/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml @@ -28,7 +28,7 @@ NIST - + @@ -39,9 +39,9 @@ true - - Profile SelectAll Sample (Derived from ISO/IEC 27002) - + + Catalog Sample (Derived from ISO/IEC 27002) + diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml b/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml index e08bd11382..20eebf79c0 100644 --- a/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml +++ b/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml @@ -28,7 +28,7 @@ NIST - + @@ -39,9 +39,9 @@ true - - Profile SelectAll Sample (Derived from ISO/IEC 27002) - + + Catalog Sample (Derived from ISO/IEC 27002) + diff --git a/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md b/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md index 9c2caee658..0794160f80 100644 --- a/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md +++ b/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md @@ -4,27 +4,24 @@ **Prerequisite:** [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) -We introduced in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) the -`OSCAL Profile` and highlighed that "OSCAL Profiles can be based on one or more -catalogs of controls, or on other OSCAL Profiles." +We introduced the `OSCAL Profile` in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md), and the reader +is referred to the [part 1 tutorial](./Profile-SelectAll%20Tutorial.md) for the overlapping information, such as the `metadata` +and the `back-matter`. -In this tutorial we will discuss the formating in OSCAL of the a *profile* that contains a subset of -controls existing in the [Profile SelectAll Sample](./Profile-SelectAll%20Sample.md). +In this tutorial we will only discuss two approaches of formatting in OSCAL a *profile* that contains a subset of +controls existing in the [Catalog Sample](../catalog/Catalog%20Sample.md), focusing exclusively on the selection of the controls. ## Formatting the Profile into an OSCAL Profile -The OSCAL Model supports representation of a *profile* in either XML or JSON. -This tutorial describes the formatting of such *profile* in XML. +Even though the `OSCAL Profile model` supports representation of a *profile* in either XML or JSON, +this tutorial focuses only on the XML representation of the *profile*. ### Profile Catalog Model -For the sake of brevity, the formating of the `metadata`, will not discuss again in this tutorial. -The redear is referred to the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md), section ** Profile's Metadata**. +The 2 distinct approaches of generating this new [Profile-SelectSpecific%20Sample.md](./Profile-SelectAll%20Sample.md) are focusing on: -We will illustrate in this tutorial 2 distinct approached of generating this new [Profile-SelectSpecific%20Sample.md](./Profile-SelectAll%20Sample.md): - -- by including all the controls using the same approach described in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) and then excluding explicitly the controls that are not needed. -- by explicitly including only the desired controls. +1. including all the controls using the same approach described in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) and then excluding explicitly the controls that are not needed. +1. explicitly including only the desired controls. #### Method 1 @@ -32,11 +29,11 @@ In the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) we descri used the default `include/all` assumption of the element when no specific `` is specified. In this method of generating the `OSCAL Profile` we will use the same approach of importing all -controls (modifications include ) from the [Profile-SelectAll%20Sample.md](./Profile-SelectAll%20Sample.md), and -exclude the non-desire controls indicating them specifically. +controls from the [Catalog Sample](../catalog/Catalog%20Sample.md), and specifically +exclude the non-desired controls. ```xml - + @@ -44,11 +41,12 @@ exclude the non-desire controls indicating them specifically. ``` + The rest of the [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) is generated identical to the [OSCAL Profile SelectAll Sample](./Profile-SelectAll%20Sample.xml). -It is important to note that the modifications done to the `Control` **1.1.1** will be -available in the current `Profile` too, if no other changes are deemed necessary.. +It is important to note that the modifications done to the `Control` **1.1.1** are not applied +in the current `Profile`. The overall OSCAL Profile with this method will become: @@ -82,7 +80,7 @@ The overall OSCAL Profile with this method will become: NIST - + @@ -110,7 +108,7 @@ We need to reiterate that the `import/all` default assumption is no longer appli Therefore, we will have to explicitly list all controls that are needed. ```xml - + @@ -153,7 +151,7 @@ the [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) can be NIST - + @@ -164,9 +162,9 @@ the [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) can be true - - Profile SelectAll Sample (Derived from ISO/IEC 27002) - + + Catalog Sample (Derived from ISO/IEC 27002) + From 8dbcf18539bcbcf14526281831ff6a57ddbc8d43 Mon Sep 17 00:00:00 2001 From: Michaela Iorga Date: Wed, 20 Oct 2021 23:07:41 -0400 Subject: [PATCH 08/10] Tools and Lunch with Des pages updates --- docs/content/contribute/dev-lunch/_index.md | 8 ++++---- docs/content/tools/_index.md | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/content/contribute/dev-lunch/_index.md b/docs/content/contribute/dev-lunch/_index.md index 62008623e3..a31ac0aa5b 100644 --- a/docs/content/contribute/dev-lunch/_index.md +++ b/docs/content/contribute/dev-lunch/_index.md @@ -12,16 +12,16 @@ weight: 10 {{% usa-intro %}}To increase communication with the OSCAL community, the NIST OSCAL team is hosting a one-hour teleconference to discuss OSCAL development.{{% /usa-intro %}} -Note: (1/10/2020) The Bluejeans info below has changed. +Note: (10/20/2021) The Bluejeans info below has changed. {{% usa-tag %}}Day and Time{{% /usa-tag %}} Every other Thursday at noon EST/EDT -{{% usa-tag %}}Meeting Link{{% /usa-tag %}} https://bluejeans.com/187858571/0183 ([ICS file](lunch-with-the-devs.ics)) +{{% usa-tag %}}Meeting Link{{% /usa-tag %}} https://bluejeans.com/4483/4483 ([ICS file](lunch-with-the-devs.ics)) {{% usa-tag %}}Meeting Details{{% /usa-tag %}} -Meeting ID: 187 858 571
      -Participant Passcode: 0183 +Meeting ID: 304 794 155
      +Participant Passcode: 4483 {{% usa-tag %}}Phone Dial-in{{% /usa-tag %}} diff --git a/docs/content/tools/_index.md b/docs/content/tools/_index.md index 6c41d02649..72d96527f5 100644 --- a/docs/content/tools/_index.md +++ b/docs/content/tools/_index.md @@ -36,4 +36,5 @@ See the [NIST Software Disclaimer](https://www.nist.gov/disclaimer) for more inf | [OSCAL REST API](https://github.com/EasyDynamics/oscal-rest) | Easy Dynamics | An initial OpenAPI definition of an OSCAL REST API that describes how systems might manipulate catalogs, profiles, components, and SSPs. | open source | | [XSLT Tooling](https://github.com/usnistgov/oscal-tools/tree/master/xslt) | NIST OSCAL Project | A variety of Extensible Stylesheet Language (XSL) Transformations (XSLT), Cascading Style Sheets (CSS), and related utilities for authoring, converting, and publishing OSCAL content in various forms. | open source | | [XML Jelly Sandwich](https://github.com/wendellpiez/XMLjellysandwich) | Wendell Piez (NIST) | Interactive XSLT in the browser includes [OSCAL demonstrations](https://wendellpiez.github.io/XMLjellysandwich/oscal/). | open source | -| [Xacta 360](https://www.telos.com/offerings/xacta-360-continuous-compliance-assessment/) | Telos | Xacta 360 is a cyber risk management and compliance analytics platform that enables users to create and submit FedRAMP system security plans (SSPs) in OSCAL format. Future OSCAL capabilities are forthcoming as the standard evolves. | [license](https://cdn.telos.com/wp-content/uploads/2021/06/22150746/Xacta-360-EULA-US.pdf) | \ No newline at end of file +| [Xacta 360](https://www.telos.com/offerings/xacta-360-continuous-compliance-assessment/) | Telos | Xacta 360 is a cyber risk management and compliance analytics platform that enables users to create and submit FedRAMP system security plans (SSPs) in OSCAL format. Future OSCAL capabilities are forthcoming as the standard evolves. | [license](https://cdn.telos.com/wp-content/uploads/2021/06/22150746/Xacta-360-EULA-US.pdf) | +| [Atlasity: Continuous Compliance Automation](https://atlasity.io/partnership/) | C2 Labs | Atlasity (release 2.0) runs in any environment and supports the development of OSCAL v1.0 content for Catalogs, Profiles, System Security Plans and Components. Additional detail can be found in this blog post: [Atlasity Delivers Free Tools to Create OSCAL Content](https://www.c2labs.com/post/atlasity-delivers-free-tools-to-create-oscal-content). | community edition | \ No newline at end of file From c0f6da061f251450de6ca09698c65a43b515a109 Mon Sep 17 00:00:00 2001 From: Michaela Iorga Date: Wed, 20 Oct 2021 23:40:39 -0400 Subject: [PATCH 09/10] Updates to Tools and Lunch with Devs pages --- docs/content/contribute/dev-lunch/_index.md | 2 +- docs/content/tools/_index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/content/contribute/dev-lunch/_index.md b/docs/content/contribute/dev-lunch/_index.md index a31ac0aa5b..cbdbddd55a 100644 --- a/docs/content/contribute/dev-lunch/_index.md +++ b/docs/content/contribute/dev-lunch/_index.md @@ -16,7 +16,7 @@ Note: (10/20/2021) The Bluejeans info below has changed. {{% usa-tag %}}Day and Time{{% /usa-tag %}} Every other Thursday at noon EST/EDT -{{% usa-tag %}}Meeting Link{{% /usa-tag %}} https://bluejeans.com/4483/4483 ([ICS file](lunch-with-the-devs.ics)) +{{% usa-tag %}}Meeting Link{{% /usa-tag %}} https://bluejeans.com/304 794 155/4483 ([ICS file](lunch-with-the-devs.ics)) {{% usa-tag %}}Meeting Details{{% /usa-tag %}} diff --git a/docs/content/tools/_index.md b/docs/content/tools/_index.md index 72d96527f5..1b3028c269 100644 --- a/docs/content/tools/_index.md +++ b/docs/content/tools/_index.md @@ -37,4 +37,4 @@ See the [NIST Software Disclaimer](https://www.nist.gov/disclaimer) for more inf | [XSLT Tooling](https://github.com/usnistgov/oscal-tools/tree/master/xslt) | NIST OSCAL Project | A variety of Extensible Stylesheet Language (XSL) Transformations (XSLT), Cascading Style Sheets (CSS), and related utilities for authoring, converting, and publishing OSCAL content in various forms. | open source | | [XML Jelly Sandwich](https://github.com/wendellpiez/XMLjellysandwich) | Wendell Piez (NIST) | Interactive XSLT in the browser includes [OSCAL demonstrations](https://wendellpiez.github.io/XMLjellysandwich/oscal/). | open source | | [Xacta 360](https://www.telos.com/offerings/xacta-360-continuous-compliance-assessment/) | Telos | Xacta 360 is a cyber risk management and compliance analytics platform that enables users to create and submit FedRAMP system security plans (SSPs) in OSCAL format. Future OSCAL capabilities are forthcoming as the standard evolves. | [license](https://cdn.telos.com/wp-content/uploads/2021/06/22150746/Xacta-360-EULA-US.pdf) | -| [Atlasity: Continuous Compliance Automation](https://atlasity.io/partnership/) | C2 Labs | Atlasity (release 2.0) runs in any environment and supports the development of OSCAL v1.0 content for Catalogs, Profiles, System Security Plans and Components. Additional detail can be found in this blog post: [Atlasity Delivers Free Tools to Create OSCAL Content](https://www.c2labs.com/post/atlasity-delivers-free-tools-to-create-oscal-content). | community edition | \ No newline at end of file +| [Atlasity: Continuous Compliance Automation](https://atlasity.io/partnership/) | C2 Labs | Atlasity CE (release 2.0) runs in any environment and supports the development of OSCAL v1.0 content for Catalogs, Profiles, System Security Plans and Components. Additional detail can be found in this blog post: [Atlasity Delivers Free Tools to Create OSCAL Content](https://www.c2labs.com/post/atlasity-delivers-free-tools-to-create-oscal-content). | community edition | \ No newline at end of file From 9ff4d282b04b82772016baeb57d3d99b32238290 Mon Sep 17 00:00:00 2001 From: Michaela Iorga Date: Thu, 21 Oct 2021 01:04:29 -0400 Subject: [PATCH 10/10] delete obsolete tutorials --- docs/tutorials/catalog/Catalog Sample.md | 124 ----- docs/tutorials/catalog/Catalog Sample.xml | 235 -------- docs/tutorials/catalog/Catalog Tutorial.md | 526 ------------------ .../profile/Profile-SelectAll Sample.md | 34 -- .../profile/Profile-SelectAll Sample.xml | 76 --- .../profile/Profile-SelectAll Tutorial.md | 422 -------------- .../profile/Profile-SelectSpecific Sample.md | 21 - .../Profile-SelectSpecific Sample_method1.xml | 50 -- .../Profile-SelectSpecific Sample_method2.xml | 50 -- .../Profile-SelectSpecific Tutorial.md | 171 ------ 10 files changed, 1709 deletions(-) delete mode 100644 docs/tutorials/catalog/Catalog Sample.md delete mode 100755 docs/tutorials/catalog/Catalog Sample.xml delete mode 100644 docs/tutorials/catalog/Catalog Tutorial.md delete mode 100644 docs/tutorials/profile/Profile-SelectAll Sample.md delete mode 100644 docs/tutorials/profile/Profile-SelectAll Sample.xml delete mode 100644 docs/tutorials/profile/Profile-SelectAll Tutorial.md delete mode 100644 docs/tutorials/profile/Profile-SelectSpecific Sample.md delete mode 100644 docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml delete mode 100644 docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml delete mode 100644 docs/tutorials/profile/Profile-SelectSpecific Tutorial.md diff --git a/docs/tutorials/catalog/Catalog Sample.md b/docs/tutorials/catalog/Catalog Sample.md deleted file mode 100644 index 64b2c4310f..0000000000 --- a/docs/tutorials/catalog/Catalog Sample.md +++ /dev/null @@ -1,124 +0,0 @@ - - -# Sample Security Catalog - Version 1.0 - Published: 02.02.2020 - Last Modified: 02.10.2020 - -## 1 Organization of Information Security - -### 1.1 Internal Organization - -**Objective:** To establish a management framework to initiate and control the implementation and -operation of information security within the organization. - -#### 1.1.1 Information security roles and responsibilities - -**Control** - -All information security responsibilities should be defined and allocated. - -**Implementation guidance** - -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. -Areas for which individuals are responsible should be stated. In particular the following should take place: -a) the assets and information security processes should be identified and defined; -b) the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented; -d) authorization levels should be defined and documented; -e) 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; -g) coordination and oversight of information security aspects of supplier relationships should be identified and documented. - -**Other information** - -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. - -#### 1.1.2 Segregation of duties - -**Control** - -Conflicting duties and areas of responsibility should be segregated to reduce opportunities for -unauthorized or unintentional modification or misuse of the organization�s assets. - -**Implementation guidance** - -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. -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. - -**Other information** - -Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization�s assets. - -## 2 Access Control - -### 2.1 Business Requirements of Access Control - -**Objective:** To limit access to information and information processing facilities. - -#### 2.1.1 Access control policy - -**Control** - -An access control policy should be established, documented and reviewed based on business and -information security requirements. - -**Implementation guidance** - -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. -Access controls are both logical and physical and these should be considered together. -Users and service providers should be given a clear statement of the business requirements to be met by access controls. -The policy should take account of the following: -a) security requirements of business applications; -b) policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information; -d) consistency between the access rights and information classification policies of systems and networks; -e) relevant legislation and any contractual obligations regarding limitation of access to data or services; -f) management of access rights in a distributed and networked environment which recognizes all - types of connections available; -g) segregation of access control roles, e.g. access request, access authorization, access administration; -h) requirements for formal authorization of access requests; -i) requirements for periodic review of access rights; -j) removal of access rights; -k) archiving of records of all significant events concerning the use and management of user identities and secret authentication information; -l) roles with privileged access. - -**Other information** - -Care should be taken when specifying access control rules to consider: -a) 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"; -b) changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user; -c) changes in user permissions that are initiated automatically by the information system and those initiated by an administrator; -d) rules which require specific approval before enactment and those which do not. -Access control rules should be supported by formal procedures and defined -responsibilities. -Role based access control is an approach used successfully by many organizations to link access rights -with business roles. -Two of the frequent principles directing the access control policy are: -a) 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); -b) 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. - -#### 2.1.2 Access to networks and network services - -**Control** - -Users should only be provided with access to the network and network services that they have been specifically authorized to use. - -**Implementation guidance** - -A policy should be formulated concerning the use of networks and network services. This policy -should cover: -a) the networks and network services which are allowed to be accessed; -b) authorization procedures for determining who is allowed to access which networks and networked services; -c) management controls and procedures to protect access to network connections and network services; -d) the means used to access networks and network services (e.g. use of VPN or wireless network); -e) user authentication requirements for accessing various network services; -f) monitoring of the use of network services. -The policy on the use of network services should be consistent with the organization's access control policy. - -**Other information** - -Unauthorized and insecure connections to network services can affect the whole organization. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the organization's information security management and control. diff --git a/docs/tutorials/catalog/Catalog Sample.xml b/docs/tutorials/catalog/Catalog Sample.xml deleted file mode 100755 index a5c2bd6415..0000000000 --- a/docs/tutorials/catalog/Catalog Sample.xml +++ /dev/null @@ -1,235 +0,0 @@ - - - - Sample Security Catalog - 2020-02-02T11:01:04.736-04:00 - 2020-02-10T11:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - Organization of Information Security - 1 - - Internal Organization - 1.1 - - Objective: -

      To establish a management framework to initiate and control the implementation and operation of information security within the organization.

      -       - - Information security roles and responsibilities - 1.1.1 - c01 - - Control -

      All information security responsibilities should be defined and - allocated.

      -       - - Implementation guidance - -

      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.

      -       - -

      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. -
      2. the entity responsible for each asset or information security - process should be assigned and the details of this responsibility - should be documented;
        3. -
      3. authorization levels should be defined and documented;
        4. -
      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. -
      5. coordination and oversight of information security aspects of - supplier relationships should be identified and documented.
        6. -
      -       -       - - Other information -

      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.

      - -       -       - - Segregation of duties - 1.1.2 - c02 - - Control -

      Conflicting duties and areas of responsibility should be segregated to - reduce opportunities for unauthorized or unintentional modification or - misuse of the organization’s assets.

      -       - - Implementation guidance - -

      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.

      -       - -

      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.

      -       -       - - Other information -

      Segregation of duties is a method for reducing the risk of accidental - or deliberate misuse of an organization’s assets.

      -       -       -       - - - Access control - 2 - - Business requirements of access control - 2.1 - - Objective: -

      To limit access to information and information processing facilities.

      -       - - Access control policy - 2.1.1 - c03 - - Control -

      An access control policy should be established, documented and reviewed based on business and information security requirements.

      -       - - Implementation guidance - -

      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.

      -       - -

      Access controls are both logical and physical and these should be considered together.

      -       - -

      Users and service providers should be given a clear statement of the business requirements to be met by access controls.

      -       - -

      The policy should take account of the following:

      -
        -
      1. security requirements of business applications;
        2. -
      2. policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information;
        3. -
      3. consistency between the access rights and information classification policies of systems and networks;
        4. -
      4. relevant legislation and any contractual obligations regarding limitation of access to data or services;
        5. -
      5. management of access rights in a distributed and networked environment which recognizes all types of connections availabel;
        6. -
      6. segregation of access control roles, e.g. access request, access authorization, access administration;
        7. -
      7. requirements for formal authorization of access requests;
        8. -
      8. requirements for periodic review of access rights;
        9. -
      9. removal of access rights;
        10. -
      10. archiving of records of all significant events concerning the use and management of user identities and secret authentication information;,
        11. -
      11. roles with privileged access.
        12. -
      -       -       - - Other information - -

      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. -
      2. changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user;
        3. -
      3. changes in user permissions that are initiated automatically by the information system and those initiated by an administrator;
        4. -
      4. rules which require specific approval before enactment and those which do not.
        5. -
      -       - -

      Access control rules should be supported by formal procedures and defined responsibilities.

      -       - -

      Role based access control is an approach used successfully by many organizations to link access rights with business roles.

      -       - -

      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. -
      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.
        3. -
      -       -       -       - - Access to networks and network services - 2.1.2 - c04 - - Control -

      Users should only be provided with access to the network and network services that they have been specifically authorized to use.

      -       - - Implementation guidance - -

      A policy should be formulated concerning the use of networks and network services. This policy should cover:

      -
        -
      1. the networks and network services which are allowed to be accessed;
        2. -
      2. authorization procedures for determining who is allowed to access which networks and networked services;
        3. -
      3. management controls and procedures to protect access to network connections and network services;
        4. -
      4. the means used to access networks and network services (e.g. use of VPN or wireless network);
        5. -
      5. user authentication requirements for accessing various network services;
        6. -
      6. monitoring of the use of network service
        7. -
      -       - -

      The policy on the use of network services should be consistent with the organization’s access control policy

      -       -       -       -       -       - - - - - diff --git a/docs/tutorials/catalog/Catalog Tutorial.md b/docs/tutorials/catalog/Catalog Tutorial.md deleted file mode 100644 index ff8f0c921e..0000000000 --- a/docs/tutorials/catalog/Catalog Tutorial.md +++ /dev/null @@ -1,526 +0,0 @@ -# OSCAL Catalog Tutorial - -## What is an OSCAL Catalog -## Example of a Proprietary Catalog - -An [OSCAL](https://www.nist.gov/oscal) Control Catalog is a machine-readable representation of a *catalog of security controls* which is a collection of *security controls* and related *control enhancements*, along with contextualizing documentation and metadata. - -For the purpose of this tutorial, a proprietary catalog is created. The file is available for download [here](./Catalog%20Sample.md) - -## Formatting the Control Catalog into an OSCAL Catalog - -The OSCAL Catalog Model supports representation of a *catalog of security controls* in either XML or JSON. -This tutorial describes the formatting of such catalog in XML. -The [OSCAL](https://www.nist.gov/oscal) website provides comprehensive information about the [OSCAL Catalog Model](https://pages.nist.gov/OSCAL/documentation/schema/catalog/) - -### Control Catalog Model - -An OSCAL catalog (in XML or JSON) uses the respective schemas that describe the XML tag sets or the JSON data objects. -However, this tutorial is not focusing on the schemas themselves but rather on the formatting in OSCAL of the proprietary control catalog listed above. -For more information on each schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-schema/) -and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/catalog/json-schema/), respectively. - -The root of the Control Catalog format is `catalog`. -The tag also captures the document's *universally unique identifier* (`uuid`), a unique 128-bit number made of hexadecimal digits displayed as 32 characters with four hyphens in between. - -```xml - - -``` - -A `catalog` contains: - -- `metadata` – it is mandatory to have one metadata -- `groups` – may have none, or as many as necessary, and they can be nested -- `controls` – may have none, or as many as necessary, and they can be nested -- `back-matter` – may have none, or as many as necessary - -Let's discuss each of these elements in the following sections and identify which ones can be used to represent our catalog. - -#### Catalog's Metadata - -The `metadata` has identical structure for all OSCAL files. - -A separate tutorial focuses on the elements of the `metadata`. -Current tutorial will only illustrate next the mandatory elements used to represent the information available in the [Sample Security Catalog](./Catalog%20Sample.md) - -``` -# Sample Security Catalog - Version 1.0 - Published: 02.02.2020 - Last Modified: 02.10.2020 -``` -The `metadata` must include the `title` of the catalog using the tag. - -```xml - Sample Security Catalog -``` - -To represent the date when the document was published we use the tag . -The date needs to include the time zone. The published date is not a mandatory field for the `OSCAL Catalog` - -```xml - 2020-02-02T11:01:04.736-04:00 -``` - -The `OSCAL Catalog Model` requires the file to contain in the `metadata` the date and time with the timezone of the last modification of the file. This information is represented using the tag - -```xml - 2020-10-02T11:01:04.736-04:00 -``` - -Another mandatory field for the `metadata` is the `version` of the file which must be included using the tag / - -```xml - 1.0 -``` -Even though we finished representing the information available in the header of the file, the `metadata` has one other field that is mandatory - the OSCAL version. -Current OSCAL version is 1.0.0 and the tag is used to represent it. - -```xml - 1.0.0 -``` -When necessary, revision history can be also documented. See additional information [here](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-model-map/) - - -The `metadata` is also designed to accommodate the representation of other information related to the content of the catalog and the entity (individual or organization) that created it in OSCAL. -For example, we can select and represent *keywords* using the property tag ``, for which we define the `name` of the property as being *keywords*. -The *keywords* will be a `string` comprised of a comma-separated list of significant words, in alphabetical order. - -The information will look as follows: -```xml - Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements -``` - -To do so, one can use the tags ` and `` each instance with a distinct `id`, and the tag `` with the field `role-id` that identifies the id of the pointed role and the tag `` that points to the `id` of the defined ``. -In this example the `` is an organization (NIST) for which the name is provided using the tag ``, an email address is listed using the tag `` and the URL using the tag ``. -Below is all this information assembled in OSCAL. - -```xml - - Document creator - - - Contact - - - - National Institute of Standards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - -``` -We managed so far to complete the `metadata` of the [Sample Security Catalog](./Catalog%20Sample.md). -Putting together all the `metadata` information, we get: - -```xml - - Sample Security Catalog - 2020-02-02T11:01:04.736-04:00 - 2020-10-02T11:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements - - Document creator - - - Contact - - - - National Institute of Standards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - -``` - -#### Formatting the Body of the Control Catalog in OSCAL - -Analyzing the body of the [Catalog Sample](./Catalog%20Sample.md), we observe that the catalog has two sections: -1 and 2, each section contains subsections 1.1 and 2.1, which have an *Objective* and group together *Controls* that meet the same *Objective*. -``` -1 Organization of Information Security - 1.1 Internal Organization - Objective: [...] - 1.1.1 Information security roles and responsibilities - [...] - 1.1.2 Segregation of duties - [...] -2 Access Control - 2.1 Business Requirements of Access Control - Objective: [...] - 2.1.1 Access control policy - [...] - 2.1.2 Access to networks and network services - [...] -``` - -The above formatting of the document will be represented using nested `groups` for Section 1 with the nested Subsection 1.1 and for Section 2 with the nested Subsection 2.1. -A `group` tag `` has an `id` and a `class`. - -Each `group` must contain a `title` identified by the tag `` and may have none or many of the following elements: - -``` - * `parameters` identified by the tags - * `properties` identified by the tags , and - * `parts` identified by the tags . -``` - -It is important to note here that the `id` of a `group` is expected to be a string. - -The Sections of the original document have numbers, and therefore, we define the `id` for each `group` to be -the number of the Section and the Subsection respectively, with a leading character such as *s* in front. - -We also represent the numerical value of the Section and of the Subsection as a `property` named *label*. - -The structure of the Section 1 and the Subsection 1.1: - -``` -1 Organization of Information Security - 1.1 Internal Organization - [...] -``` - -could be represented as follows: - -``` - - Organization of Information Security - 1 - - Internal Organization - 1.1 - [...] - - -``` - -Let us put together the high-level information for both Sections' and their Subsections': - -``` - - Organization of Information Security - 1 - - Internal Organization - 1.1 - [...] - - - - Access control - 2 - - Business requirements of access control - 2.1 - [...] - - -``` - -To represent the information of each Subsection, we need to identify the appropriate OSCAL elements for the *Objective* and the `Controls`. -An *Objective* can be represented as a `part` named *item*. -This `part` will also have an unique-to-the-document string `id` which can be used to reference the *Objective*. - -An original *Objective* statement like the one below: - -``` -Objective: To establish a management framework [...] within the organization. -``` -is represented as follows: - -``` - - Objective: -

      To establish a management framework [...] within the organization.

      -       -``` - -Integrating the *Objective* into the above structure of the *Sample Security Catalog*, we get: - -``` - - Organization of Information Security - 1 - - Internal Organization - 1.1 - - Objective: -

      To establish a management framework [...] within the organization.

      -       - [...] -       -       -``` - -Following the *Objective*, the *Sample Security Catalog* describes the related *Controls*, their *Implementation guidance* and often -some additional information titled *Other information*. - -The structure of the first control, *1.1.1 Information security roles* is represented below: - -``` - 1.1.1 Information security roles - Control - All information security [...]. - Implementation guidance - Allocation of information security [...] - Other information - Many organizations appoint an [...] -``` - -To represent a *Control* and its content, the OSCAL element `control` identified by the tag `` is used. -The element `control` must have a ``, and it may have none or many of the following elements: - -``` - * `parameter` identified by the tags , - * `property` identified by the tags , - * `annotation` identified by the tags , - * `link` identified by the tags , and - * `part` identified by the tags . -``` - -Using the OSCAL elements in the same manner as for the `group`, the first *Control* in the *Sample Security Catalog* can be -represented as below: - -``` - - Information security roles and responsibilities - 1.1.1 - c01 - - Control -

      All information security [...].

      -       - - Implementation guidance - -

      Allocation of information security [...]

      -       - [...] -       - - Other information -

      Many organizations appoint an [...]

      -       -       -``` - -A similar approach of expressing the data is used to reformat the rest of all the `Controls` (1.1.2, 2.1.1 and 2.2.1) - -#### Formatting a Back-matter - -Often documents have references, links to other documents, diagrams/images, citations, remarks. -OSCAL defines elements that can be used to represent such information. - -Back-matters are optional elements and therefore often the OSCAL Catalogs will not contain any. - -A back-matter element is identified by the tag ``. -This element may have `resources` which are identified with the tag ``. - -Each `resource` may have: - -``` - * `title` identified by the tags - * `description` identified by the tags - * `property` identified by the tags - * `document id` identified by the tags - * `citation` identified by the tags - * `link` identified by the tags - * `base64-binary-data` identified by the tags - * `remarks` identified by the tags -``` -Our catalog does not contain any back-matter, but additional information about the available -elements and their fields, can be found [here](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-model-map/) - -### The Final Catalog - -Assembling all the elements described above, we obtain the arching structure of the *Sample Security Catalog*: - -``` - - - - Sample Security Catalog - 2020-02-02T11:01:04.736-04:00 - 2020-10-02T11:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISM, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - Organization of Information Security - - Internal Organization - 1.1 - - Objective: -

      To establish a management framework to initiate and control the implementation and operation of information security within the organization.

      -       - - Information security roles and responsibilities - 1.1.1 - c01 - - Control -

      All information security responsibilities should be defined and - allocated.

      -       - - Implementation guidance - -

      Allocation of information security [...]

      -       - -

      Individuals with allocated information [...].

      -       - -

      Areas for which individuals are [...]

      - [...] -       -       - - Other information -

      Many organizations [...].

      - -       -       - - Segregation of duties - 1.1.2 - c02 - - Control -

      Conflicting duties [...]

      -       - - Implementation guidance - -

      Care should be taken [...].

      -       - -

      Small organizations may [...].

      -       -       - - Other information -

      Segregation of duties is [...].

      -       -       -       -       - - Access control - - Business requirements of access control - 2.1 - - Objective: -

      To limit access to information and information processing facilities.

      -       - - Access control policy - 2.1.1 - c03 - - Control -

      An access control policy should [...].

      -       - - Implementation guidance - -

      Asset owners should determine [...].

      -       - -

      Access controls are both logical and physical [...].

      -       - -

      Users and service providers should [...].

      -       - -

      The policy should take account of the following:

      - [...] -       -       - - Other information - -

      Care should be taken [...]

      - [...] -       - -

      Access control rules should [...].

      -       - -

      Role based access control is [...].

      -       - -

      Two of the frequent principles [...]:

      - [...] -       -       -       - - Access to networks and network services - 2.1.2 - c04 - - Control -

      Users should only be provided [...].

      -       - - Implementation guidance - -

      A policy should be [...]

      - [...] -       - -

      The policy on the use of network [...]

      -       -       -       -       -       - - -       -``` - - diff --git a/docs/tutorials/profile/Profile-SelectAll Sample.md b/docs/tutorials/profile/Profile-SelectAll Sample.md deleted file mode 100644 index 8c0cecce20..0000000000 --- a/docs/tutorials/profile/Profile-SelectAll Sample.md +++ /dev/null @@ -1,34 +0,0 @@ -# Sample Security Profile - -## Case 1: Sellect All Controls - - Version 1.0 - Published: 03.24.2020 - Last Modified: 03.24.2020 - - -This profile imports all the security controls defined in the [Sample Security Catalog](../catalog/Catalog%20Sample.md), version 1.0, and *tailors* (modifies) control **1.1.1** to add additional *implementation guidance* and additional *information*. - -### List of Controls - -#### 1.1.1 Information security roles and responsibilities - -**Implementation guidance** - -**ADDED**: The organizations should identify critical information system assets supporting essential missions and business functions. - -**Other information** - -**ADDED**: The appointed owners of the assets should report {organization-defined frequency} the results of assets' security verification -to the information secuirty manager. - - -#### 1.1.2 Segregation of duties - - -#### 2.1.1 Access control policy - - -#### 2.1.2 Access to networks and network services - - diff --git a/docs/tutorials/profile/Profile-SelectAll Sample.xml b/docs/tutorials/profile/Profile-SelectAll Sample.xml deleted file mode 100644 index f0aa5607fe..0000000000 --- a/docs/tutorials/profile/Profile-SelectAll Sample.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - Sample Security Profile - Select All Controls - 2020-03-24T11:01:04.736-04:00 - 2020-03-24T11:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - - - - - true - - - - - - - - 1.1.1 Additional Sample Profile Requirements and Guidance - - Implementation Guidance: -

      The organizations should identify critical information system assets supporting essential missions and business functions.

      -       -       -       - - - 1.1.1 Additional Sample Profile Requirements and Guidance - - Other Information: -

      The appointed owners of the assets must report the results of assets' security verification - to the information security manager.

      -       -       -       -       - - - -       - - - Catalog Sample (Derived from ISO/IEC 27002) - - - -       - - - diff --git a/docs/tutorials/profile/Profile-SelectAll Tutorial.md b/docs/tutorials/profile/Profile-SelectAll Tutorial.md deleted file mode 100644 index 4127486ecb..0000000000 --- a/docs/tutorials/profile/Profile-SelectAll Tutorial.md +++ /dev/null @@ -1,422 +0,0 @@ -# OSCAL Profile Tutorial - -## What is an OSCAL Profile - -The OSCAL Profile layer defines a [model](https://pages.nist.gov/OSCAL/documentation/schema/profile/) for selecting a specific set of security -control requirements from one or more control catalogs. The term *profile* in OSCAL -is also called a *baseline* in the NIST SP 800-53 catalog or in FedRAMP's documentation. -Additionally, the term *profile* in OSCAL covers the overlay concept defined in the -NIST SP 800-53 catalog allowing for further tailoring of controls, modification of the requirements, -customization, interpretation and parameter values assignment. - -An OSCAL Profiles can be based on one or more catalogs of controls, or on other OSCAL Profiles. - [OSCAL](https://www.nist.gov/oscal) website provides comprehensive information about the [OSCAL Profile Model](https://pages.nist.gov/OSCAL/documentation/schema/profile/) - -Current tutorial focuses solely on a proprietary profile that **selects all the controls** from a catalog of security controls. -The catalog of security controls used in this tutorial is the [Sample Security Catalog](../catalog/Catalog%20Tutorial.md), version 1.0, created for educational purpose. -The profile also *tailors* (modifies) control **1.1.1** to add additional *implementation guidance* and additional *information*. -This profile can be viewed [here](./Profile-SelectAll%20Sample.md). - -## Formatting the Profile into an OSCAL Profile - -The OSCAL Model supports representation of a *profile* in either XML or JSON. -This tutorial describes the formatting of such *profile* in XML. - -### Profile Catalog Model - -An `OSCAL Profile` (in XML or JSON) uses the respective schemas that describe the XML tag sets or the JSON data objects. -However, this tutorial is not focusing on the schemas themselves but rather on the formatting in OSCAL of the *profile* described above. -For more information on each *profile* schemas, the reader is referred to [XML Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/profile/xml-schema/) -and [JSON Schema Reference](https://pages.nist.gov/OSCAL/documentation/schema/profile/json-schema/), respectively. - -The root of the Profile format is `profile`. -The tag also captures the document's *universally unique identifier* (`uuid`), a unique 128-bit number made of hexadecimal digits displayed as 32 characters with four hyphens in between. - -```xml - - -``` - -A `profile` contains: - -- `metadata` – it is mandatory to have one metadata -- `imports` – may have none, or as many as necessary -- `merge` – may have none, or as many as necessary -- `modify` - may have none, or as many as necessary -- `back-matter` – may have none, or as many as necessary - -Let's discuss each of these elements in the following sections and identify which ones can be used to represent our catalog. - -#### Profile's Metadata - -The `metadata` has identical structure for all OSCAL files. - -A separate tutorial focuses on the elements of the `metadata`. -Current tutorial will only illustrate next the mandatory elements used to represent the information available in the [Sample Security Catalog](./Catalog%20Sample.md) - -``` -# Sample Security Profile - -## Case 1: Sellect All Controls - - Version 1.0 - Published: 03.24.2020 - Last Modified: 03.24.2020 -``` -The `metadata` must include the `title` of the *profile* using the `` tag. - -```xml - Sample Security Profile - Select All Controls -``` - -To represent the date when the document was published we use the tag ``. -The date needs to include the time zone. The published date is not a mandatory field for the `OSCAL Profile` - -```xml - 2020-03-24T11:01:04.736-04:00 -``` - -The `OSCAL Profile Model` requires the file to contain in the `metadata` the date and time with the timezone of the last modification of the file. -This information is represented using the tag `` - -```xml - 2020-03-24T11:01:04.736-04:00 -``` - -Another mandatory field for the `metadata` is the `version` of the file which must be included using the tag `/`. - -```xml - 1.0 -``` -Even though we finished representing the information available in the header of the file, the `metadata` has one other field that is mandatory - the OSCAL version. -Current OSCAL version is 1.0.0 and the tag `` is used to represent it. - -```xml - 1.0.0 -``` -When necessary, revision history can be also documented. See additional information [here](https://pages.nist.gov/OSCAL/documentation/schema/profile/xml-model-map/) - - -The `metadata` is also designed to accommodate the representation of other information related to the content of the *profile* and the entity (individual or organization) that created it in OSCAL. -For example, we can select and represent *keywords* using the property tag ``, for which we define the `name` of the property as being *keywords*. -The *keywords* will be a `string` comprised of a comma-separated list of significant words, in alphabetical order. - -The information will look as follows: -```xml - Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements -``` - -To do so, one can use the tags `` and ``, each instance with a distinct `id`, and the tag `` with the field `role-id` that identifies the id of the pointed role and the tag `` that points to the `id` of the defined . -In this example the `` is an organization (NIST) for which the name is provided using the tag ``, an email address is listed using the tag `` and the URL using the tag ``. -Below is all this information assembled in OSCAL. - -```xml - - Document creator - - - Contact - - - - National Institute of Standards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - -``` -We managed so far to complete the `metadata` of the [OSCAL Profile-SelectAll Sample](./Profile-SelectAll%20Sample.md). - -Putting together all the `metadata` information, we get: - -```xml - - Sample Security Profile - Select All Controls - 2020-03-24T11:01:04.736-04:00 - 2020-03-24T11:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - -``` - -#### Formatting the Body of the OSCAL Profile - -We discussed earlier that this [OSCAL Profile Sample](./Profile-SelectAll%20Sample.md) selects all the controls from the catalog. -The `OSCAL Profile` model defines the `` element that designates the catalog, profile or resources from where the controls are selected. -The element has the following content: -- `href` - a required field that provides the URL of the referred resource -- `include` - used to specify the controls included, and can be used as many times as needed or not used at all -- `exclude` - used to specify de-select controls, and can be used as many times as needed or not used at all -Since an `include/all` (that is, all controls will be included by default) is assumed in the `OSCAL Profile` model when no `` -is given, we will use this default feature to generate our profile. -Also, because our `Catalog` does not have nested `controls`, we will not need to explicitly `import/all` -controls and explicitly set the `with-child-controls` flag. - -The selection of all controls from the catalog can be simply represented as follows: - -```xml - - -``` -In general, after selecting the controls, it is important to be able to merge them in resolution. -For this purpose, OSCAL has the `` element that can be used to `combine` the controls and structure them the - same way they are structured in the `Catalog`, by using the flag `as-is`, or provide a `custom` structure. - - In our case, we will structure the controls the same way they were structured in the `Catalog`. - - ```xml - - true - -``` - -As owners of the profile, we identified that the `Control` **1.1.1** with the `id=s1.1.1` requires modifications or tayloring. -To specify the changes we need to make to the control, we will use the `` element which allows us -to `` and `` statements of the control. Our controls do not have parameters. - -We will use the `` element and specify the `control-id` to indicate the control that is being modified. - -```xml - - [...] - -``` - -The element `` allows to: -- `remove` - by using the tag `` -- `add` - by using the tag `` - -In our case, we are not removing any statement form the control, but would like to add information at the end of the existing paragraph. -The first statement we want to add will be appended to the **Implementation guidance** of the `Control` with ID `control-id=s1.1.1` - -```xml - - [...] - -``` - -The second statement we want to add will be appended to the **Other information** section of the `Control` with ID `control-id=s1.1.1` - -```xml - - [...] - -``` -Putting together the formationg discussed so far for altering or tailoring a control, we obtain: - -```xml - - - [...] - - - [...] - - -``` - -The statement appended to the **Implementation guidance** reads: *The organizations should identify critical information system assets supporting essential missions and business functions.* -This statement will be introduced using the element `` which has been previously introduced in the Catalog tutorial. - -The element's description is available [here](https://pages.nist.gov/OSCAL/documentation/schema/profile/xml-schema/#part) - -Through this element, we will provide the required `id` and `name` for the statement, -a `` for the modification and the added statement itself itself as a nested `<part>`, as follows: - -```xml - <part id="s1.1.1_smp_gnd" name="item" ns="sample"> - <title>1.1.1 Additional Sample Profile Requirements and Guidance - - Implementation Guidance: -

      The organizations should identify critical information system assets supporting essential missions and business functions.

      -       -       -``` - -In a similar way is also represented the statement appended to the **Other Information** that -reads: *The appointed owners of the assets must report the results of assets' security verification to the information security manager.* - -```xml - - 1.1.1 Additional Sample Profile Requirements and Guidance - - Other Information: -

      The appointed owners of the assets must report the results of assets' security verification - to the information security manager.

      -       -       -``` -Putting gother the 2 added statements, the tailoring of the `Control` **1.1.1** looks like: - -```xml - - - - 1.1.1 Additional Sample Profile Requirements and Guidance - - Implementation Guidance: -

      The organizations should identify critical information system assets supporting essential missions and business functions.

      -       -       -       - - - 1.1.1 Additional Sample Profile Requirements and Guidance - - Other Information: -

      The appointed owners of the assets must report the results of assets' security verification - to the information security manager.

      -       -       -       -       -``` - -#### Formatting a Back-matter - -Often documents have references, links to other documents, diagrams/images, citations, remarks. -OSCAL defines elements that can be used to represent such information. - -Back-matters are optional elements and therefore often the OSCAL Catalogs will not contain any. - -A back-matter element is identified by the tag . -This element may have `resources` which are identified with the tag . - -Each `resource` may have: - -``` - * `title` identified by the tags - * `description` identified by the tags - * `property` identified by the tags - * `document id` identified by the tags - * `citation` identified by the tags - * `link` identified by the tags - * `base64-binary-data` identified by the tags - * `remarks` identified by the tags -``` -Additional information about the available -elements and their fields, can be found [here](https://pages.nist.gov/OSCAL/documentation/schema/catalog/xml-model-map/) - -In our case, the `Profile` does not have specific information for the back-matter, but we can observe that the information -of the `Catalog` can be included in the back-matter as follows: - -```xml - - - Catalog Sample (Derived from ISO/IEC 27002) - - - -``` -With the `Catalog` defined here, the catalog id can be used as `uri` in the `` elemet. - -```xml - - -``` - -### The Final Profile - -Assembling all the elements described above, we obtain the arching structure of the *Profile SelectAll Sample*: - -```xml - - - - Sample Security Profile - Select All Controls - 2020-03-24T11:01:04.736-04:00 - 2020-03-24T11:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - - - true - - - - - - - - 1.1.1 Additional Sample Profile Requirements and Guidance - - Implementation Guidance: -

      The organizations should identify critical information system assets supporting essential missions and business functions.

      -       -       -       - - - 1.1.1 Additional Sample Profile Requirements and Guidance - - Other Information: -

      The appointed owners of the assets must report the results of assets' security verification - to the information security manager.

      -       -       -       -       - - - -       - - - Catalog Sample (Derived from ISO/IEC 27002) - - - -       -``` - - diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample.md b/docs/tutorials/profile/Profile-SelectSpecific Sample.md deleted file mode 100644 index 9b642ae8a7..0000000000 --- a/docs/tutorials/profile/Profile-SelectSpecific Sample.md +++ /dev/null @@ -1,21 +0,0 @@ -# Sample Security Profile - -## Case 2: Select Specific Controls - - Version 1.0 - Published: 03.24.2020 - Last Modified: 03.24.2020 - - -This profile imports two of the security controls defined in the [Catalog Sample](../catalog/Catalog%20Sample.md), version 1.0. - -### List of Controls - -#### 1.1.1 Information security roles and responsibilities - -#### 2.1.1 Access control policy - - - - - diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml b/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml deleted file mode 100644 index 8aa8ac1032..0000000000 --- a/docs/tutorials/profile/Profile-SelectSpecific Sample_method1.xml +++ /dev/null @@ -1,50 +0,0 @@ - - - - Sample Security Profile - Select Specific Controls - Method 1 - 2020-03-24T12:01:04.736-04:00 - 2020-03-24T12:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - - - - - - - - true - - - - Catalog Sample (Derived from ISO/IEC 27002) - - - - - - - diff --git a/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml b/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml deleted file mode 100644 index 20eebf79c0..0000000000 --- a/docs/tutorials/profile/Profile-SelectSpecific Sample_method2.xml +++ /dev/null @@ -1,50 +0,0 @@ - - - - Sample Security Profile - Select Specific Controls - Method 2 - 2020-03-24T12:30:04.736-04:00 - 2020-03-24T12:30:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - - - - - - - - true - - - - Catalog Sample (Derived from ISO/IEC 27002) - - - - - - - diff --git a/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md b/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md deleted file mode 100644 index 0794160f80..0000000000 --- a/docs/tutorials/profile/Profile-SelectSpecific Tutorial.md +++ /dev/null @@ -1,171 +0,0 @@ -# OSCAL Profile Tutorial - Part2 - -## Generating a Profile By Explicitly Selecting Controls - -**Prerequisite:** [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) - -We introduced the `OSCAL Profile` in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md), and the reader -is referred to the [part 1 tutorial](./Profile-SelectAll%20Tutorial.md) for the overlapping information, such as the `metadata` -and the `back-matter`. - -In this tutorial we will only discuss two approaches of formatting in OSCAL a *profile* that contains a subset of -controls existing in the [Catalog Sample](../catalog/Catalog%20Sample.md), focusing exclusively on the selection of the controls. - -## Formatting the Profile into an OSCAL Profile - -Even though the `OSCAL Profile model` supports representation of a *profile* in either XML or JSON, -this tutorial focuses only on the XML representation of the *profile*. - -### Profile Catalog Model - -The 2 distinct approaches of generating this new [Profile-SelectSpecific%20Sample.md](./Profile-SelectAll%20Sample.md) are focusing on: - -1. including all the controls using the same approach described in the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) and then excluding explicitly the controls that are not needed. -1. explicitly including only the desired controls. - -#### Method 1 - -In the [Profile-SelectAll Tutorial](./Profile-SelectAll%20Tutorial.md) we described the element ``, and -used the default `include/all` assumption of the element when no specific `` is specified. - -In this method of generating the `OSCAL Profile` we will use the same approach of importing all -controls from the [Catalog Sample](../catalog/Catalog%20Sample.md), and specifically -exclude the non-desired controls. - -```xml - - - - - - - -``` - -The rest of the [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) is generated identical to the -[OSCAL Profile SelectAll Sample](./Profile-SelectAll%20Sample.xml). - -It is important to note that the modifications done to the `Control` **1.1.1** are not applied -in the current `Profile`. - -The overall OSCAL Profile with this method will become: - -```xml - - - Sample Security Profile - Select Specific Controls - Method 1 - 2020-03-24T12:01:04.736-04:00 - 2020-03-24T12:01:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - - - - - - - - true - - - - Profile SelectAll Sample (Derived from ISO/IEC 27002) - - - - -``` - -#### Method 2 - -The same [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) can be obtained in OSCAL -by explicitly including the desired controls from the [Profile SelectAll Sample](./Profile-SelectAll%20Sample.xml). - -We need to reiterate that the `import/all` default assumption is no longer applicable if the `` element is invoked. -Therefore, we will have to explicitly list all controls that are needed. - -```xml - - - - - - - -``` -Putting together the other parts of the `OSCAL Profile` (`metadata`, `merge`, `back-matter`) -as described in the [Profile-SelectAll Tutorial](./Profile-SelectAl%20Tutorial.md), the -the [Profile SelectSpecific Sample](./Profile-SelectSpecific%20Sample.md) can be represented in OSCAL as follows: - -```xml - - - - Sample Security Profile - Select Specific Controls - Method 2 - 2020-03-24T12:30:04.736-04:00 - 2020-03-24T12:30:04.736-04:00 - 1.0 - 1.0.0 - Assurance, computer security, FISMA, security controls, security requirements - - Document creator - - - Contact - - - - National Institute ofStandards and Technology - oscal@nist.gov - https://www.nist.gov/oscal - - - - NIST - - - NIST - - - - - - - - - - - true - - - - Catalog Sample (Derived from ISO/IEC 27002) - - - - -``` \ No newline at end of file