| Network Working Group | S. Banghart |
| Internet-Draft | NIST |
| Intended status: Informational | B. Munyan |
| Expires: January 14, 2021 | A. Montville |
| Center for Internet Security | |
| G. Alford | |
| Red Hat, Inc. | |
| July 13, 2020 |
Definition of the ROLIE configuration checklist Extension
draft-mandm-sacm-rolie-configuration-checklist-02
This document extends the Resource-Oriented Lightweight Information Exchange (ROLIE) core to add the information type categories and related requirements needed to support security configuration checklist use cases. Additional categories, properties, and requirements based on content type enables a higher level of interoperability between ROLIE implementations, and richer metadata for ROLIE consumers. Additionally, this document discusses requirements and usage of other ROLIE elements in order to best syndicate security configuration checklists.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Default configurations for endpoints (operating systems, applications, etc.) are normally geared towards ease-of-use or ease-of-deployment, not security. As such, many enterprises operate according to guidance provided to them by a control framework ([CIS_Critical_Controls], [PCI_DSS], [NIST_800-53] etc.), which often prescribe that an enterprise define a standard, security-minded configuration for each technology they operate. Such standard configurations are often referred to as configuration checklists. This document defines an extension to the Resource-Oriented Lightweight Information Exchange (ROLIE) protocol [I-D.ietf-mile-rolie] to support the publication of configuration checklist information. Configuration checklists contain a set of configuration recommendations for a given endpoint. A configuration recommendation prescribes expected values pertaining to one or more discrete endpoint attributes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
The previous key words are used in this document to define the requirements for implementations of this specification. As a result, the key words in this document are not used for recommendations or requirements for the use of ROLIE.
As an extension of [RFC8322], this document refers to many terms defined in that document. In particular, the use of "Entry" and "Feed" are aligned with the definitions presented in section TODO of ROLIE.
Several places in this document refer to the "information-type" of a Resource (Entry or Feed). This refers to the "term" attribute of an "atom:category" element whose scheme is "urn:ietf:params:rolie:category:information-type". For an Entry, this value can be inherited from it's containing Feed as per [RFC8322].
Other terminology used in this document is defined below:
TODO: There needs to be a "normative" reference to the SCAP 1.2/3 specifications and schema definitions
This document registers a new information type for use in ROLIE repositories. The "configuration-checklist" information type represents a body of information describing a set of configuration recommendations. A configuration recommendation is, minimally, a single configuration item paired with a recommended value or range of values. Depending on the source, a configuration recommendation may carry with it additional information (i.e. description, references, rationale, etc.). Provided below is a non-exhaustive list of information that may be considered as components of a configuration checklist.
A breadth of metadata may be included with a configuration checklist as identifying information. A publishing organization may wish to recognize or attribute checklist authors or contributors, or maintain a revision/version history over time. Other metadata that may be included could indicate the various categories of products to which the checklist applies, such as Operating System, Network Device, or Application Server.
This document registers several new rolie:property elements to express this metadata in a more efficient and automatable form.
Today, checklists are distributed in a myriad of different formats, using a variety of organization schemes. This standard attempts to be as flexible as possible in its approach, in order to be usable by as many checklist distributors as possible.
Using the NIST National Checklist Program as a foundation, checklists consist of a primary set of content and a list of supporting content. These pieces of content come in a number of machine readable and human readable formats, and it is out of scope of this standard to describe guidance for all them. Instead, a best effort should be made to use the available properties, elements, and attributes to describe the content. Moreover, the content is often a compressed file that consists of a package of other content. Likewise, describing this nested structure is out of scope for this standard. Each organization should use a description scheme that best matches their use and business cases, and this description scheme should be documented as thoroughly as possible for all users.
When existing identifiers, titles, authors, and dates are provided in machine-readable forms inside a ROLIE Entry, automated processes can find and acquire checklist content with more ease than the current state-of-the-art methodology. Fully solving the checklist automation problem will require a more significant effort touching on all parts of the checklist ecosystem.
| Name | Description |
|---|---|
| ancestor | Links to a configuration checklist supersceded by that described in this entry |
| target-platform | Links to a software descriptor resource defining the software subject to this configuration checklist entry |
| supporting | Links to a supporting document for the main content. The "title" attribute SHOULD be used to provide a human readable title for this document. Where possible, the "type" attribute MAY be used to describe the type of the supporting document. If the type is a simple IANA Media Type, the media type text should be used, otherwise, a short human readable description should be used. |
IANA has added an entry to the "ROLIE Security Resource Information Type Sub-Registry" registry located at <https://www.iana.org/assignments/rolie/category/information-type> .
The entry is as follows:
IANA has added an entry to the "ROLIE URN Parameters" registry located in <https://www.iana.org/assignments/rolie/>.
The entry is as follows:
Use of this extension requires understanding and managing the security considerations of the core ROLIE specification. Beyond that, there must be considerations made for the common use cases and data types that would be shared with this extension in particular.
Checklist information, while typically shared publicly, can have potential security impact if compromised. In these cases, the utmost care should be taken to secure the REST endpoint. Ensure that only authenticated users are allowed request access to any part of the ROLIE repository. Authentication schemes such as OAUTH or basic HTTP Auth provides a significant barrier to compromise. When providing checklist information as a paid service, security is valuable as a means to protect valuable data from being stolen or taken for free. In these cases, the above strategies still apply, but providers may want to make the Feed visible to non-authenticated users, with meaningful error messages sent to users that have not yet paid for the service.
Typical RESTful security measures applied commonly on the web would be effective to secure this ROLIE extension. As a flexible and relatively simple RESTful service, ROLIE server implementations have great flexibility and freedom in securing their repository.
This extension poses no additional privacy considerations above and beyond those stated in the core ROLIE specification.
| [I-D.ietf-mile-rolie] | Field, J., Banghart, S. and D. Waltermire, "Resource-Oriented Lightweight Information Exchange", Internet-Draft draft-ietf-mile-rolie-07, May 2017. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8322] | Field, J., Banghart, S. and D. Waltermire, "Resource-Oriented Lightweight Information Exchange (ROLIE)", RFC 8322, DOI 10.17487/RFC8322, February 2018. |
| [CIS_Critical_Controls] | "CIS Critical Security Controls", August 2016. |
| [NIST_800-53] | Hanson, R., "NIST 800-53", September 2007. |
| [PCI_DSS] | "PCI Data Security Standard", April 2016. |
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="https://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0" xml:lang="en-US">
<id>c8db0a93-4dcb-426e-997f-ba43c100b863</id>
<title>NIST National Checklist for Red Hat Virtualization Host 4.x</title>
<published>2020-06-29T18:13:51.0Z</published>
<updated>2020-06-29T18:13:51.0Z</updated>
<category scheme="urn:ietf:params:rolie:category:information-type" term="checklist"/>
<summary>SCAP content for evaluation of Red Hat Virtualization Host 4.x systems. The Red Hat content embeds multiple pre-established compliance profiles.</summary>
<rolie:format ns="scap13namespace"/>
<content type="application/zip" src="https://nvd.nist.gov/ncp/checklist/908/download/5615"/>
<link rel="supporting" title="OpenControl-formatted NIST 800-53 responses for Red Hat Virtualization Host 4.x" href="https://github.com/ComplianceAsCode/redhat/tree/master/virtualization-host" type="Machine-Readable Format"/>
<link rel="supporting" title="[DRAFT] DISA STIG for Red Hat Virtualization Host (RHVH)" href="https://galaxy.ansible.com/RedHatOfficial/rhv4_rhvh_stig" type="Ansible Playbook"/>
<link rel="supporting" title="VPP - Protection Profile for Virtualization v. 1.0 for Red Hat Virtualization Hypervisor (RHVH)" href="https://galaxy.ansible.com/RedHatOfficial/rhv4_rhvh_vpp" type="Ansible Playbook"/>
<rolie:property name="urn:ietf:params:rolie:property:content-id" value="908"/>
<rolie:property name="urn:ietf:params:rolie:property:checklist:checklist-version" value="content v0.1.48"/>
<rolie:property name="urn:ietf:params:rolie:property:content-published-date" value="2020-01-14T00:00:00+00:00"/>
<rolie:property name="urn:ietf:params:rolie:property:content-updated-date" value="2019-06-14T00:00:00+00:00"/>
<rolie:property name="urn:ietf:params:rolie:property:checklist:product-category" value="Virtual Machine"/>
</entry>
This section provides some brief examples of a Checklist Information Type ROLIE Entry.