IETF-96 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Security Automation and Continuous Monitoring (sacm) (WG)

Minutes   |   Jabber Logs  |   Mailing List Archives

Additional information is available at tools.ietf.org/wg/sacm

Chair(s):

Security Area Area Director(s):

Assigned Area Director



Status Update (provided 2016-04-07)

SACM met on Wednesday to discuss it’s recently adopted vulnerability assessment draft [1], a couple of individual submissions (software identification [2] and endpoint compliance profile [3]), and the SACM information model [4][5].

SACM will meet again on Friday to discuss it’s terminology draft [6], and the work done this week on solidifying the structure of our information model.

Our requirements draft [7] has made it through WGLC and we intend to prepare this for shepherding through the IESG.

During the Wednesday meeting there was consensus, which will be verified on the list, to adopt the software identification I-D [2] as a WG draft.

The endpoint compliance profile draft will be updated at least once more to make some clarifications before the WG is willing to consider adoption.


[1] https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/
[2] https://datatracker.ietf.org/doc/draft-birkholz-sacm-coswid/
[3] https://datatracker.ietf.org/doc/draft-haynes-sacm-ecp/
[4] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/
[5] https://tools.ietf.org/html/draft-cam-winget-sacm-information-model-00
[6] https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/
[7] https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/

Recordings:

Meeting Slides:

Blue Sheets:

Internet-Drafts:

Request for Comments:

Charter (as of 2016-08-05):

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

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 January 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts.