WG Action: Rechartered Security Automation and Continuous Monitoring (sacm)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The Security Automation and Continuous Monitoring (sacm) WG in the Security
Area of the IETF has been rechartered. For additional information, please
contact the Area Directors or the WG Chairs.

Security Automation and Continuous Monitoring (sacm)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Christopher Inacio <inacio@cert.org>
  Adam Montville <adam.w.montville@gmail.com>
  Karen O'Donoghue <odonoghue@isoc.org>

Assigned Area Director:
  Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

Security Area Directors:
  Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
  Eric Rescorla <ekr@rtfm.com>

Mailing list:
  Address: sacm@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/sacm
  Archive: https://mailarchive.ietf.org/arch/browse/sacm/

Group page: https://datatracker.ietf.org/group/sacm/

Charter: https://datatracker.ietf.org/doc/charter-ietf-sacm/

Securing information and the systems that store, process, and transmit that
information is a challenging task for enterprises of all sizes, and many
security practitioners spend much of their time on manual processes.
Standardized protocols and models aiding collection and evaluation of
endpoint elements enable automation, thus freeing practitioners to focus on
high priority tasks.  Due to the breadth of this work, the working group will
address enterprise use cases pertaining to the assessment of endpoint posture
(using the definitions of Endpoint and Posture from RFC 5209). In alignment
with RFC 5209, a network device is an endpoint.

Posture assessment entails the following five steps which the working will
create solutions to automate:

1. Identify and characterize target endpoints
2. Determine specific endpoint elements to assess
3. Collect and make available specified elements' actual values
4. Compare actual element values to policy compliant element values
5. Make results available

This working group will focus on collection, evaluation, and orchestration
and communication, as described herein.

A. Collection. The WG will define a standardized way to provide two types of
guidance to collectors over varying collection mechanisms:

1) Which target endpoints to collect from, and
2) What elements to collect from these target endpoints.

A set of instructions (such as vulnerability description data, YANG filter
expressions, Windows Management Instrumentation classes, etc.) can be
brokered to the appropriate collectors using the control plane functions
defined by "C. Orchestration and Communication" (below). Element collection
from different sources may require orchestrating functions that go beyond the
set of capabilities a collector can provide.  This will inform the
requirements and characteristics for "C. Orchestration and Communication".
The working group recognizes that manual configuration of targets and
corresponding collection profiles will not scale and does not seem to be a
viable option.

B. Evaluation. The working group will standardize a criteria language
enabling evaluation of actual endpoint posture information against desired
endpoint posture information to produce a standardized result. This
extensible language will support complex Boolean statements, comparison
operators, logical flow statements, and functions for string manipulation.
Additionally, the working group will seek to discover an approach that allows
data from any posture collection mechanism to be generically evaluated.

C. Orchestration and Communication. The working group will define a set of
control plane functions to enable the orchestration between element
collectors. These element collectors can then provide the requisite elements
sought by posture collectors, posture evaluators, and data repositories.

Specific work items may include the following:

- Define a way to provide three types of guidance to the correct SACM
collectors: 1) Which target endpoints to collect from and 2) what to collect
from these target endpoints, and 3) how quickly after an attribute change
information must be collected. When applied, a set of instructions, such as
vulnerability description data or YANG expressions, can be brokered to the
appropriate collectors.

- Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to
collect and deliver information about firmware, operating systems, and
software installed on an endpoint.

- Describe a criteria language capable of being evaluated against endpoint
posture information to produce a standardized result. The language will
support complex Boolean statements, comparison operators, and functions for
string manipulation; and will be extensible enough to be applicable to the
full range of collected posture attributes. Additionally, this document will
describe an approach that allows data from any posture collection mechanism
to be evaluated.

- Define a control plane function to enable the discovery and orchestration
between devices that can provide the requisite information sought by posture
collectors, posture evaluators or both. For example, XMPP capable
host/endpoint interactions may be defined through XMPP control plane and data
transfer protocol extensions.  Likewise, the asynchronous push of selected
attributes on switches and routers may be framed using YANG Push for periodic
and on-change triggers.

- Define a method of expressing software metadata that is suitable for use by
constrained devices including a CBOR-based format derived from the ISO/IEC
19770-2 Software Identification (SWID) tag standard.

- Define best practices for the collection of posture information from
endpoints and its delivery to a collector, from which it can be distributed
using the SACM messaging standards.

- Extend existing standards for information exchange to support the sharing
of software, configuration information, and other forms of guidance including
extensions to the Resource-Oriented Lightweight Information Exchange (ROLIE).

- Describe a SACM Information Model and a SACM Architecture including
protocol requirements and their associated use cases as well as a description
of how SACM protocols fit together into a system.

Milestones:

  Dec 2017 - Submit SWIMA to IESG

  Jan 2018 - WGLC ROLIE software descriptor

  Jan 2018 - WGLC ROLIE configuration checklist information type

  Jan 2018 - WGLC CoSWID

  Jan 2018 - WGLC Endpoint Compliance Profile

  Jan 2018 - Initial Draft on SACM Architecture

  Mar 2018 - Submit ROLIE software descriptor to IESG

  Mar 2018 - Submit ROLIE configuration checklist information type to IESG

  Mar 2018 - Submit CoSWID to IESG

  May 2018 - Initial Draft on ECP over transfer mechanism

  May 2018 - Initial Draft on YANG-push over transfer mechanism





[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux