Subject: Re: [sacm] Draft updated charter for SACM

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Sep 2017 23:18:33 +0000

Hi Karen,
 
I can see YANG filter expressions addressing work described in the charter proposal.  To accomplish collection asynchronously in step 3 for switches and routers, is it worth explicitly referencing the set of YANG Push work in the NETCONF WG?  
 
As YANG push includes control plane messaging, discovery, and operations mechanisms, this might be a reasonable match for the collection and messaging work items where SACM wants to track the postures of Network Elements. 
  
Thanks,
Eric

On 9/12/17, 9:47 AM, "sacm on behalf of Karen O'Donoghue" <[email-masked] on behalf of [email-masked]> wrote:

    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. 
    
    _______________________________________________
    sacm mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sacm

---

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

Eric,

+1. Referencing the YANG Push work in the NETCONF WG seems like a reasonable thing to do. Do you have some text in mind?

Thanks,
Dave

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
> Sent: Thursday, September 14, 2017 7:19 PM
> To: Karen O'donoghue <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sacm] Draft updated charter for SACM
> 
> Hi Karen,
> 
> I can see YANG filter expressions addressing work described in the charter
> proposal.  To accomplish collection asynchronously in step 3 for switches and
> routers, is it worth explicitly referencing the set of YANG Push work in the
> NETCONF WG?
> 
> As YANG push includes control plane messaging, discovery, and operations
> mechanisms, this might be a reasonable match for the collection and
> messaging work items where SACM wants to track the postures of Network
> Elements.
> 
> Thanks,
> Eric
> 
> 
> On 9/12/17, 9:47 AM, "sacm on behalf of Karen O'Donoghue" <sacm-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     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:
> 
>     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: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 22 Sep 2017 18:35:09 +0000

Hi David,

My proposed  changes would be:

Collection: The WG will define a way to provide three types of imperative guidance to the correct SACM collectors: 1) Which target endpoints to collect from, 2) what to collect from these target endpoints and 3) how quickly after an attribute change information must be collected. When classified, a set of instructions, such as vulnerability description data or YANG expressions, can be brokered to the appropriate collectors. Detecting and classifying beforehand might require orchestrating functions that go beyond the set of capabilities some SACM collectors can provide.

...

Messaging: The WG will define a control plane function to enable 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.

Eric

> From: Waltermire, David A., September 19, 2017 10:52 AM

> +1. Referencing the YANG Push work in the NETCONF WG seems like a

> reasonable thing to do. Do you have some text in mind?

> > From: sacm [mailto:[email-masked]] On Behalf Of Eric Voit

> > (evoit)

> > To: Karen O'donoghue <[email-masked]<mailto:[email-masked]>>

> > Cc: [email-masked]<mailto:[email-masked]>

> > I can see YANG filter expressions addressing work described in the

> > charter proposal.  To accomplish collection asynchronously in step 3

> > for switches and routers, is it worth explicitly referencing the set

> > of YANG Push work in the NETCONF WG?

> > As YANG push includes control plane messaging, discovery, and

> > operations mechanisms, this might be a reasonable match for the

> > collection and messaging work items where SACM wants to track the

> > postures of Network Elements.

> > [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

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

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

> > 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:

> >     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:

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

> > orchestrating functions that go beyond the set of capabilities a

> > collector can provide, and will inform the requirements and characteristics for

> "C.

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

> >     [email-masked]<mailto:[email-masked]>

> > [email-masked]<mailto:[email-masked]>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Sat, 23 Sep 2017 00:26:47 +0000

Support, the update text makes sense to me

发件人: sacm [mailto:[email-masked]] 代表 Eric Voit (evoit)
发送时间: 2017年9月23日 2:35
收件人: Waltermire, David A. (Fed); Karen O'donoghue
抄送: [email-masked]
主题: Re: [sacm] Draft updated charter for SACM

Hi David,

...

Eric

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 26 Sep 2017 13:02:51 +0200

Hello Eric,

thank you for the improvement!

+1

Viele Grü0e,

Henk

On 09/22/2017 08:35 PM, Eric Voit (evoit) wrote:
> Collection: The WG will define a way to provide three types of 
> endpoints to collect from, 2) what to collect from these target 
> endpoints and 3) how quickly after an attribute change information must 
> be collected. When classified, a set of instructions, such as 
> vulnerability description data or YANGexpressions, can be brokered to 
> the appropriate collectors. Detecting and classifying beforehand might 
> require orchestrating functions that go beyond the set of capabilities 
> some SACM collectors can provide.
> 
> ...
> 
> Messaging: The WG will define a control plane function to enable 
> discovery and orchestration between devices that can provide the 
> 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.
> 
> Eric
> 
>  > > To: Karen O'donoghue <[email-masked] <mailto:[email-masked]>>
> 
>  > > Cc: [email-masked] <mailto:[email-masked]>
> 
>  > > [email-masked] <mailto:[email-masked]> on behalf of 
> [email-masked] <mailto:[email-masked]>> wrote:
> 
>  > >
> 
>  > >     Folks,
> 
>  > >
> 
>  > > [email-masked] <mailto:[email-masked]>
> 
>  > > [email-masked] <mailto:[email-masked]>
>