Skip to content

Latest commit

 

History

History
229 lines (182 loc) · 9.46 KB

draft-mandm-sacm-rolie-checklistdescriptor.mkd

File metadata and controls

229 lines (182 loc) · 9.46 KB
Raw

coding: utf-8

title: Definition of the ROLIE configuration checklist Extension abbrev: rolie-cc-ext docname: draft-mandm-sacm-rolie-configuration-checklist-00 category: info

stand_alone: yes pi: [toc, sortrefs, symrefs, comments]

author:

ins: B. Munyan
name: Bill Munyan
org: Center for Internet Security
street: 31 Tech Valley Drive
city: East Greenbush, NY
code: 12061
country: USA
email: [email protected]
  • ins: A. Montville name: Adam Montville org: Center for Internet Security street: 31 Tech Valley Drive city: East Greenbush, NY code: 12061 country: USA email: [email protected]

informative: NIST_800-53: target: http://deusty.blogspot.com/2007/09/stunt-out-of-band-channels.html title: NIST 800-53 author: name: Robbie Hanson ins: R. Hanson date: 2007-09-17

CIS_Critical_Controls: target: https://www.cisecurity.org/critical-controls/ title: CIS Critical Security Controls date: 2016-08-31

PCI_DSS: target: https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss title: PCI Data Security Standard date: 2016-04

--- abstract

This document extends the Resource-Oriented Lightweight Information Exchange (ROLIE) core by defining a new information-type to ROLIE's atom:category pertaining to security configuration checklists. Additional supporting requirements are also defined which describe the use of specific formats and link relations pertaining to the new information-type.

--- middle

{: #introduction}

Introduction

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. 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. These 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.

{: #terminology}

Terminology

Configuration Checklist A configuration checklist is an organized collection of rules about a particular kind of system or platform.

Configuration Item : Generally synonymous with endpoint attribute.

Configuration Recommendation A configuration recommendation is an expression of the desired posture of one or more configuration items. A configuration recommendation generally includes the description of the recommendation, a rationale statement, and the expected state of collected posture information.

TODO: Others?? : TBD

TODO: There needs to be a "normative" reference to the SCAP 1.2/3 specifications and schema definitions

{: #new-information-types}

New information-types

This document defines a new "information-type" value of "configuration-checklist".

{: #checklist-information-type}

The "configuration-checklist" information-type

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 "Data Stream":
  • A "Benchmark"
  • A "Profile"
  • A "Value"
  • A "Rule" or "Group" of Rules
    • Description
    • Rationale
    • Remediation Instructions
    • Information, described in the dialect of a supported "check system", indicating the method(s) used to audit the checklist configuration item.
  • Applicable Platform Information
  • Information regarding a set of patches to be evaluated
  • Any supported "tailoring" information, providing a method for evaluating entities to refine the recommendations in the data stream without modifying the published data stream content. (WKM NOTE: Does "tailoring" need to be here? Why would any tailoring be included in a published feed? Unless the organization is re-publishing the content with their tailoring included.)

{: usage-in-atom-publishing-protocol}

Usage of Configuration Checklist Information in the Atom Publishing Protocol

These requirements apply when a ROLIE repository contains any Collections, who's href points to an atom:feed who's atom:category element contains a scheme attribute of "urn:ietf:params:rolie:category:information-type" and a term attribute of the new "configuration-checklist" information-type.

<atom:category 
  scheme="urn:ietf:params:rolie:category:information-type" 
  term="configuration-checklist">...</atom:category>

{: #atom-entry-extension-point}

Requirements for the 'atom:entry' Element

The following sections describe the various requirements for the atom:entry element, and it's child elements, when publishing configuration checklist information to a ROLIE repository.

The 'atom:content' Element

Information about the proposed serialization types for configuration checklists

  • PDF
  • Text
  • Word
  • Excel
  • XML via DSC
  • JSON?

{: #format-extension-point}

The 'rolie:format' Element

A configuration checklist may be published by an organization using numerous formats, such as PDF, Word or Excel documents, and automation content using XML or JSON data models.

This document does not specify any additional requirements for use of the rolie:format element.

{: #rolie-properties}

Configuration checklist metadata included in the 'rolie:property' Element

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.

The following list describes various 'rolie:property' constructs.

  • author (0..n)
    • An unbounded number of rolie:property elements with a name attribute of "author" may be included to indicate those individuals noted as the authors of the configuration checklist.
  • contributor (0..n)
    • An unbounded number of rolie:property elements with a name attribute of "contributor" may be included to indicate those individuals noted as recognized contributors to the configuration checklist and/or the recommendations contained within.
  • checklist version: The value of the "checklist version" property indicates the version number of the configuration checklist, such as 3.1.1
  • title: The value of the "title" property indicates the document title of the configuration checklist, such as "CIS Benchmark for Microsoft Windows Server 2012 R2"
  • publication date
  • overview
  • Product category (0..n), such as
    • Antivirus Software
    • Application Server
    • Auditing
    • Authentication
    • Automation/Productivity Application Suite
    • Client and Server Encryption
    • Configuration Management Software
    • Database Management System
    • Desktop Application
    • Desktop Client
    • DHCP Server
    • Directory Service
    • DNS Server
    • Email Server
    • Encryption Software
    • Enterprise Application
    • File Encryption
    • Firewall
    • Firmware
    • Handheld Device
    • Identity Management
    • Intrusion Detection System
    • KVM
    • Mail Server
    • Malware
    • Mobile Solution
    • Monitoring
    • Multi-Functional Peripheral
    • Network Router
    • Network Switch
    • Office Suite
    • Operating System
    • Peripheral Device
    • Security Server
    • Server
    • Virtual Machine
    • Virtualization Software
    • Web Browser
    • Web Server
    • Wireless Email
    • Wireless Network

{: #atom-link-registrations}

atom:link Registrations

TODO: Can there be multiple of these links? For example, I really want more than one target-platform and more than one profile.

|Name|Description|Conformance| |ancestor|Links to a configuration checklist supersceded by that described in this entry|MAY| |target-platform|Links to a software descriptor resource defining the software subject to this configuration checklist entry|SHOULD| |version|Links to a text resource indicating the version of the configuration checklist|MUST|

{: #iana-considerations}

IANA Considerations

Per this document, 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.

New IANA table for "ROLIE Entry Format"

  • scap-1.2
  • PDF
  • xccdf-1.2-collection
  • oval
  • cvrf
  • cve (should we reuse the enumref?); Look at the "enumref" and see if we can copy/paste configuration checklist-specific information in a similar manner? Can we then include that enum reference in the ROLIE extension document or should we create a new "enumref" document separately?
  • vulnerability

name: : configuration-checklist

index: : TBD

reference: : TBD

Security Considerations

TBD

Privacy Considerations

TBD

--- back