WG Review: Security Automation and Continuous Monitoring (sacm)

The IESG <iesg-secretary@ietf.org> Fri, 28 June 2013 16:31 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2AB2B21F9AE1; Fri, 28 Jun 2013 09:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.491
X-Spam-Status: No, score=-101.491 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vkFTYv--iC7X; Fri, 28 Jun 2013 09:31:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E5121F9ADC; Fri, 28 Jun 2013 09:31:27 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Review: Security Automation and Continuous Monitoring (sacm)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130628163127.12364.87316.idtracker@ietfa.amsl.com>
Date: Fri, 28 Jun 2013 09:31:27 -0700
Cc: sacm WG <sacm@ietf.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jun 2013 16:31:29 -0000

A new IETF working group has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08.

Security Automation and Continuous Monitoring (sacm)
Current Status: Proposed WG

  Dan Romascanu <dromasca@avaya.com>
  Kathleen Moriarty <Kathleen.Moriarty@emc.com>

Assigned Area Director:
  Sean Turner <turners@ieca.com>

Mailing list
  Address: sacm@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/sacm
  Archive: http://www.ietf.org/mail-archive/web/sacm/


Securing information and the systems that store, process, and transmit
that information is a challenging task for organizations of all sizes,
and many security practitioners spend much of their time on manual
processes. Standardized protocols to collect, verify, and update system
security configurations would allow this process to be automated, which
would free security practitioners to focus on high priority tasks and
should improve their ability to prioritize risk based on timely
information about threats and vulnerabilities.  Because this is a broad
area of work, this working group will first address enterprise use cases
pertaining to the assessment of endpoint posture (using the definitions
of Endpoint and Posture from RFC 5209).

The working group will, whenever reasonable and possible, reuse existing
protocols, mechanisms, information and data models. Of particular
interest to this working group are existing industry standards,
preferably IETF standards, that could support automation of asset,
change, configuration, and vulnerability management.

The working group will define:

1. A set of standards to enable assessment of endpoint posture. This area
of focus provides for necessary language and data format specifications.

  An example of such an endpoint posture assessment could include,
  but is not limited to, the following general steps:

  1. Identify endpoints

  2. Determine specific endpoint elements to assess

  3. Collect actual value of elements

  4. Compare actual element values to expected element values

  5. Report results

  This approach to endpoint posture collection enables multiple policies
  to be evaluated based on a single data collection activity. Policies
  will be evaluated by comparing available endpoint posture data 
  according to rules expressed in the policy. Typically, these rules 
  will compare the actual value against an expected value or range for 
  specific posture elements. In some cases, the posture element may 
  pertain to software installation state, in which case the actual and 
  expected values may be "installed" or "not installed." Evaluation of 
  multiple posture elements may be combined using Boolean logic.

2. A set of standards for interacting with repositories of content
related to assessment of endpoint posture.

  Repository protocols are needed to store, update, and retrieve
  configuration checks and other types of content required for posture
  assessment (see step 2 above). A content repository is expected to
  house specific versions of checklists (i.e. benchmarks), may be
  required to satisfy different use cases (i.e. asset inventory,
  configuration settings, or vulnerabilities). In addition, content 
  repositories are expected to store up-to-date dictionary of specific 
  enumerations, such as those used for configuration element 
  identifiers, asset classifications, vulnerability identifiers, and so 

This working group will produce the following deliverables:

- A document or documents describing the SACM Architecture. This will
include protocol requirements and their associated use cases as well as a
description of how SACM protocols fit together into a system. This may be
a single standards-track document, or may be split up as the WG sees fit.
- A standards-track document specifying the informational model for
endpoints data posture.
- A standards-track document specifying a protocol and data format for
retrieving configuration and policy information for driving data
collection and analysis
- A standards-track document specifying a protocol and data format for
collecting actual endpoint posture

The working group will create an Internet-Draft documenting the existing
work in the IETF and in other organizations that might be used as-is or
as a starting point for developing solutions to the SACM requirements. 
The working group may decide to make of this document an Informational
RFC, but this is not a mandatory deliverable.

The working group will work in close coordination with other WGs in the
IETF (including, but not limited to MILE and NEA) in order to create
solutions that do not overlap and can be used or re-used to meet the
goals of more than one working group.

The working group will communicate with non-IETF organizations working on
related specifications and will encourage industry participation in the
development of the WG's documents.  Other organizations involved in the
sacm space include ISO/IEC and TCG, as well as government agencies such
as NIST.

SACM-related efforts are largely aligned, and may overlap, with other
IETF (and non-IETF) standardization efforts. There are common "problems"
found in SACM, that may be addressed by the work done in SNMP, IPFIX,
NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular
interest to SACM is understanding and respecting the distinctions between
itself and NEA and MILE.

One way the NEA protocols can be used is as the transport for data
collected on the endpoint to an external service or data repository for
further analysis and action. NEA may also serve the purpose of carrying
data-collection instructions.

The MILE data formats provide a format to describe incident,
threat-related incident, and indicator information. SACM data formats
provide ways to understand what endpoints are in your environment,
whether they meet policy requirements, and their current configuration
state. The data exchanged in MILE, supplementing the SACM data, creates
enhanced situational awareness, thus enabling increased understanding of
current threats and mitigations. The combined SACM and MILE data sets
become a powerful tool to automate security with descriptions of
endpoints, known vulnerabilities to those endpoints, and their
configurations along with an understanding of layered defenses.
Transports from MILE may be used by SACM.

This charter will expire in Month Year (36 months from approval). If the
charter is not updated before that time, the WG will be closed and any
remaining documents revert back to individual Internet-Drafts.

  Oct 2013 - Initial submission of SACM Architecture Internet-Draft
  Nov 2013 - Initial submission of SACM Information Model Internet-Draft
  Jan 2014 - Initial submission of protocol and data format for
retrieving configuration and policy information for driving data
collection and analysis Internet-Draft
  Jan 2014 - Initial submission of protocol and data format for
collecting endpoint posture Internet-Draft
  May 2014 - Submit SACM Architecture Internet-Draft to the IESG for
consideration as Informational RFC
  Sep 2014 - Submit protocol and data format for retrieving configuration
and policy information for driving data collection and analysis
Internet-Draft to the IESG for consideration as Proposed Standard
  Sep 2014 - Submit protocol and data format for collecting endpoint
posture Internet-Draft to the IESG for consideration as Proposed Standard