Subject: [sacm] Draft updated charter for SACM

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 12 Sep 2017 16:47:34 +0000

Folks,

Below is a draft update to our charter based on discussion at the last IETF and some subsequent private discussions. Comments welcome. Please remember that we plan to call out specific drafts using the milestone process and not include them in the base charter. 

Regards,
Karen

***************

SACM Charter Proposal
2017-09-12

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 and models aiding collection and evaluation of endpoint attributes enable automation, thus freeing practitioners to focus on high priority tasks.  

At its core, posture assessment consists of five basic steps, which the working group desires to fulfill in an innovative, automated manner capable of avoiding ad hoc or scheduled assessments:

1. Describe target endpoints
2. Determine specific endpoint elements to assess
3. Collect and make available specified elements' actual values
4. Compare actual element values to expected 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 imperative guidance to collectors over varying collection mechanisms: 

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

When classified, 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). Detecting and classifying desired attributes beforehand may require orchestrating functions that go beyond the set of capabilities a collector can provide, and 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 discovery and orchestration between devices that can provide the requisite information sought by posture collectors, posture evaluators, data repositories, and other SACM architectural components. 

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). The working group will, whenever reasonable and possible, reuse existing work. 

Specific work items will include the following:

- Collection: The WG will define a way to provide two types of imperative guidance to the correct SACM collectors: 1) Which target endpoints to collect from and 2) what to collect from these target endpoints. When classified, a set of instructions, such as vulnerability description data or YANG filter expressions, can be brokered to the appropriate collectors. Detecting and classifying beforehand might require orchestrating functions that go beyond the set of capabilities a SACM collector can provide. 

- Evaluation: The working group will 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.

- Messaging: The WG will 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. As an example, a document that describes an instance of such a control plane and transfer protocol for data, is through the use of XMPP and extensions as needed to demonstrate XMPP’s applicability to SACM.

Additionally, the working group will describe: 1) 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, and 2) a SACM Information Model.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 13 Sep 2017 01:35:18 +0000

Hi Karen,
Please see my comments inline:

B.R.
Frank

-----邮件原件-----
发件人: sacm [mailto:[email-masked]] 代表 Karen O'Donoghue
发送时间: 2017年9月13日 0:48
收件人: [email-masked]
主题: [sacm] Draft updated charter for SACM

Folks,

Regards,
Karen

***************

SACM Charter Proposal
2017-09-12

1. Describe target endpoints
2. Determine specific endpoint elements to assess 3. Collect and make available specified elements' actual values 4. Compare actual element values to expected element values 5. Make results available
[Frank]: What is the goal of describing target endpoints? Is it for determining specific endpoint elements to assess, or as the metadata information in the endpoint's security posture, or both? Do we need a standard model to describe any kind of endpoints, or we already have? 

1) Which target endpoints to collect from, and
2) What to collect from these target endpoints. 
[Frank]: should we consider the guidance of how to collect? I just assume that our protocol should consider the related issues like: collection method (pull/push, pub/sub, event/schedule driven, etc), some possible in-process actions (broker, filtering, combination, correlation, etc), security mechanisms during the whole collection process.

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.
[Frank]: Does evaluation rules need to communicate between SACM components? I am curious the reason why we need to standardize them? Can someone clarify what does it mean here for "any posture collection mechanism"?

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). The working group will, whenever reasonable and possible, reuse existing work. 
[Frank]: For clarification, are we starting to consider the security posture assessment for the network infrastructure devices, the other type of endpoint in this new charter?

_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Mon, 18 Sep 2017 18:08:05 +0000

All,

After discussion with a few other SACM document authors this version of the new charter proposal was put together. The changes throughout are minimal; the primary change is several additions to the work items section that covers other work currently being done in the WG.

Does anyone have any thoughts/comments/concerns on this proposed draft update? 

Thanks,
Stephen Banghart

------------------------------------------------------------------------------------------

SACM Charter Proposal
2017-09-12

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 and models aiding collection and evaluation of endpoint attributes enable automation, thus freeing practitioners to focus on high priority tasks .  

When classified , 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). Detecting and classifying desired attributes beforehand may require orchestrating functions that go beyond the set of capabilities a collector can provide, and 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.

-  The WG will define a way to provide two types of imperative guidance to the correct SACM collectors: 1) Which target endpoints to collect from and 2) what to collect from these target endpoints. When classified, a set of instructions, such as vulnerability description data or YANG filter expressions, can be brokered to the appropriate collectors. Detecting and classifying beforehand might require orchestrating functions that go beyond the set of capabilities a SACM collector can provide. 

-  The WG will 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.

- The WG will 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. As an example, a document that describes an instance of such a control plane and transfer protocol for data, is through the use of XMPP and extensions as needed to demonstrate XMPP’s applicability to SACM. 

- A method of expressing software metadata is needed that is suitable for use by constrained devices. The WG will create a standards track document that defines a CBOR-based format that represents software metadata to include software identification, file hashes, and other descriptive information. This format will be derived from the ISO/IEC 19770-2 Software Identification (SWID) tag standard.

- To support collection of posture information from traditional computing devices (e.g., servers, laptops, etc.), the WG will create standards track documents describing mechanisms for the collection and delivery of information about installed software on an endpoint by extending IETF NEA.

- To provide for the integration of multiple standards to support posture information collection, the WG will 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. 

-The WG will define standards track documents describing extensions to the Resource-Oriented Lightweight Information Exchange (ROLIE) that provide IANA registrations and requirements to support the sharing of software, configuration information, and other forms of imperative guidance.

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Karen
> O'Donoghue
> Sent: Tuesday, September 12, 2017 12:48 PM
> To: [email-masked]
> Subject: [sacm] Draft updated charter for SACM
> 
> Folks,
> 
> Below is a draft update to our charter based on discussion at the last IETF and
> some subsequent private discussions. Comments welcome. Please
> remember that we plan to call out specific drafts using the milestone process
> and not include them in the base charter.
> 
> Regards,
> Karen
> 
> ***************
> 
> SACM Charter Proposal
> 2017-09-12
> 
> 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 and models aiding collection and evaluation of
> endpoint attributes enable automation, thus freeing practitioners to focus on
> high priority tasks.
> 
> At its core, posture assessment consists of five basic steps, which the
> working group desires to fulfill in an innovative, automated manner capable
> of avoiding ad hoc or scheduled assessments:
> 
> 2. Determine specific endpoint elements to assess 3. Collect and make
> available specified elements' actual values 4. Compare actual element values
> to expected element values 5. Make results available
> 
> A. Collection. The WG will define a standardized way to provide two types of
> imperative guidance to collectors over varying collection mechanisms:
> 
> When classified, 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).
> Detecting and classifying desired attributes beforehand may require
> orchestrating functions that go beyond the set of capabilities a collector can
> provide, and 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 discovery and orchestration between
> devices that can provide the requisite information sought by posture
> collectors, posture evaluators, data repositories, and other SACM
> architectural components.
> 
> 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). The working group will,
> whenever reasonable and possible, reuse existing work.
> 
> - Collection: The WG will define a way to provide two types of imperative
> guidance to the correct SACM collectors: 1) Which target endpoints to collect
> from and 2) what to collect from these target endpoints. When classified, a
> set of instructions, such as vulnerability description data or YANG filter
> expressions, can be brokered to the appropriate collectors. Detecting and
> classifying beforehand might require orchestrating functions that go beyond
> the set of capabilities a SACM collector can provide.
> 
> - Evaluation: The working group will 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.
> 
> - Messaging: The WG will 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. As an
> example, a document that describes an instance of such a control plane and
> transfer protocol for data, is through the use of XMPP and extensions as
> needed to demonstrate XMPP’s applicability to SACM.
> 
> Additionally, the working group will describe: 1) 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, and 2) a SACM
> Information Model.
>

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 19 Sep 2017 13:59:29 +0000

Thanks Stephen, Eric, and Xialiang for the comments thus far. In talking with Stephen offline for clarification, the main change below is the addition of the four work items just before the one on the architecture and information model. Additional comments and any feedback on the already provided comments from all three would be really helpful. We would like to wrap this up in advance of our virtual interim next week. Speak now or forever hold your peace… 

Karen

> On Sep 18, 2017, at 2:08 PM, Banghart, Stephen A. (Fed) <[email-masked]> wrote:
> 
> All,
>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 19 Sep 2017 14:58:05 +0000

Frank,

My comments are inline below.

Regards,
Dave

> From: sacm [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
> Sent: Tuesday, September 12, 2017 9:35 PM
> To: Karen O'donoghue <[email-masked]>
> Cc: [email-masked]
> Subject: [sacm] 答复: Draft updated charter for SACM
> 
> Hi Karen,
> [Frank]: What is the goal of describing target endpoints? Is it for determining
> specific endpoint elements to assess, or as the metadata information in the
> endpoint's security posture, or both? Do we need a standard model to
> describe any kind of endpoints, or we already have?

[daw: Yes. It is to determine which endpoints to assess and which endpoint(s) a given set of results pertain to.]

> [Frank]: should we consider the guidance of how to collect? I just assume
> that our protocol should consider the related issues like: collection method
> (pull/push, pub/sub, event/schedule driven, etc), some possible in-process
> actions (broker, filtering, combination, correlation, etc), security mechanisms
> during the whole collection process.

[daw: Do you have specific text to add/change in mind?]

> [Frank]: Does evaluation rules need to communicate between SACM
> components? I am curious the reason why we need to standardize them?
> Can someone clarify what does it mean here for "any posture collection
> mechanism"?
> 
> [Frank]: For clarification, are we starting to consider the security posture
> assessment for the network infrastructure devices, the other type of
> endpoint in this new charter?

[daw: As before, we are agnostic to the type of networked device. This means that network infrastructure devices are endpoints, and are considered part of SACM, in the same way that any other device that is connected to a network is.]