Subject: [sacm] Updated Candidate Charter Text

From: "Adam W. Montville" <[email-masked]>
Date: Sun, 2 Jun 2013 08:57:29 -0700

All:

I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments submitted in a variety of threads (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put the following together.  

I would love to see a dramatic increase in SACM participation throughout this month - especially relating to the charter, which should be our primary focus at this point, and then limited to the first several milestones.

My concern is that SACM momentum is trailing off at a point when it needs to be maintaining, if not increasing, from that level we saw at IETF 86.

The following is the modified charter text:

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 processes to collect, verify, and update security system configurations would allow easier automation of the processes. Automating these routine tasks would free security practitioners to focus on high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. This working group will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security, freeing them to focus on more advanced tasks. The initial focus of this work is to 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.

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

Assessment of endpoint posture assessment entails the following general steps:

1. Relevant endpoints are identified and classified based on the targets of the policy/policies to be evaluated

2. For each endpoint, determine what elements of posture information to collect based on the policy/policies to be evaluated

3. For each element of the endpoint posture data, identify the mechanism for data collection and what content is needed, if any, to support data collection

4. Retrieve any content needed for data collection.  Configuration checks pertaining to a particular posture element may be used to support data collection.

5. Harvest the actual values pertaining to posture elements identified in step 3 from the endpoint.

6. Report collected endpoint posture as identified in step 2.  This will likely be done on an individual basis for each identified endpoint, requiring aggregation of data collected from multiple endpoints as needed based on the identified policy.

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.

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. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring).  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 achieve the following deliverables:

- An Informational document on Use Cases
- An Informational document on Requirements
- An Informational document on SACM Architecture
- 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 overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can 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 (for example for the repository access protocol) and can be used or re-used to meet the goals of more than one working group. 

In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships.

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 thier configurations along with an understanding of layered defenses.  Then, injecting known threat information with mitigation options assists the organization in turning detailed security decisions into business-relevant decisions.  The MILE protocols, RID and ROLIE, enable the exchange of structured data and are designed to carry any structured format.  While RID may be used in multiple sharing models and provides multiple communication flows (report, query, etc.) with the ability to enable peer-to-peer object level security, ROLIE provides a RESTful repository transport option with only the need for a browser on the client end, removing deployment barriers.

After the work items in the current charter have been submitted to and approved by the IESG, the WG will recharter or close.
 
Goals and Milestones

Sep. 2013 - Initial submission of an Internet-Draft on Use Cases 

Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking into consideration RFC5706 and RFC3535

Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture 

Nov. 2013 - Initial submission of an Internet-Draft on overview of related standards work 

Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis

Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for collecting actual endpoint posture 

Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for consideration as Informational RFC 

Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements for consideration as Informational RFC 

Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Architecture for consideration as Informational RFC 

Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis for consideration as standards-track RFC 

Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data format for collecting actual endpoint posture for consideration as standards-track RFC

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 3 Jun 2013 12:44:25 +0000

Hi, 

Thanks to Adam for this revision. 

Can we have a show of hands about this version of the charter text: 

- does it clarify in a satisfactory manner the questions asked on the list and especially the ones asked by our AD? 
- does it reflect the consensus of the mail list on the scope of the first phase of the proposed WG? 
- is it good enough to be submitted to the IESG for discussions on the formation of the WG?

All answers welcome. Any answer different than 'yes' should be accompanied by concrete comments on issues that still need clarification, and items we still need to work for consensus. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam W. Montville
> Sent: Sunday, June 02, 2013 6:57 PM
> To: [email-masked]
> Subject: [sacm] Updated Candidate Charter Text
> Importance: High
> 
> All:
> 
> I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-
> sacm/) and comments submitted in a variety of threads
> (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put
> the following together.
> 
> I would love to see a dramatic increase in SACM participation throughout
> this month - especially relating to the charter, which should be our
> primary focus at this point, and then limited to the first several
> milestones.
> 
> My concern is that SACM momentum is trailing off at a point when it
> needs to be maintaining, if not increasing, from that level we saw at
> IETF 86.
> 
> 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 processes to collect, verify, and update
> security system configurations would allow easier automation of the
> processes. Automating these routine tasks would free security
> practitioners to focus on high priority tasks, and should improve
> operators' ability to prioritize risk based on timely information about
> threats and vulnerabilities. This working group will define security
> automation protocols and data format standards in support of information
> security processes and practices. These standards will help security
> practitioners to be more effective by automating routine tasks related
> to client and server security, freeing them to focus on more advanced
> tasks. The initial focus of this work is to address enterprise use cases
> pertaining to the asses  sment 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.
> 
> 1. A set of standards to enable assessment of endpoint posture. This
> area of focus provides for necessary language and data format
> specifications.
> 
> 2. A set of standards for interacting with repositories of content
> related to assessment of endpoint posture.
> 
> 2. For each endpoint, determine what elements of posture information to
> collect based on the policy/policies to be evaluated
> 
> 3. For each element of the endpoint posture data, identify the mechanism
> for data collection and what content is needed, if any, to support data
> collection
> 
> 4. Retrieve any content needed for data collection.  Configuration
> checks pertaining to a particular posture element may be used to support
> data collection.
> 
> 6. Report collected endpoint posture as identified in step 2.  This will
> likely be done on an individual basis for each identified endpoint,
> requiring aggregation of data collected from multiple endpoints as
> needed based on the identified policy.
> 
> 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.
> 
> 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. a NEA-specific use vs. a generally
> applicable assessment used during continuous monitoring).  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.
> 
> - A standards-track document specifying a protocol and data format for
> retrieving configuration and policy information for driving data
> collection and analysis
> The working group will create an overview of related standards work
> Internet-Draft which will document existing work in the IETF or in other
> SDOs which can 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 (for example for the repository access
> protocol) and can be used or re-used to meet the goals of more than one
> working group.
> 
> In accordance with existing IETF processes, the group will communicate
> with and invite participation from other relevant standards bodies and
> regulatory organizations, and if necessary reuse existing liaison
> relationships or request the establishment of new liaison relationships.
> 
> 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 thier configurations along with
> an understanding of layered defenses.  Then, injecting known threat
> information with mitigation options assists the organization in turning
> detailed security decisions into business-relevant decisions.  The MILE
> protocols, RID and ROLIE, enable the exchange of structured data and are
> designed to carry any structured format.  While RID may be used  in
> multiple sharing models and provides multiple communication flows
> (report, query, etc.) with the ability to enable peer-to-peer object
> level security, ROLIE provides a RESTful repository transport option
> with only the need for a browser on the client end, removing deployment
> barriers.
> 
> After the work items in the current charter have been submitted to and
> approved by the IESG, the WG will recharter or close.
> 
> Goals and Milestones
> 
> Oct. 2013 - Initial submission of an Internet-Draft on Requirements
> taking into consideration RFC5706 and RFC3535
> 
> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and
> data format for retrieving configuration and policy information for
> driving data collection and analysis
> 
> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and
> data format for collecting actual endpoint posture
> 
> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM
> Architecture for consideration as Informational RFC
> 
> Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol
> and data format for retrieving configuration and policy information for
> driving data collection and analysis for consideration as standards-
> track RFC
> 
> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and
> data format for collecting actual endpoint posture for consideration as
> standards-track RFC
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 3 Jun 2013 13:00:34 +0000

Hi Mike, 

Thanks for your response and support. 

Concerning the email participation - this community needs to confirm now to the IESG that 1. It stays committed to do the SACM work, as discussed in the two BOF sessions 2. It acknowledges consensus on the scope as expressed in the charter text. 

This is the reason for doing this call for feedback now. 

Regards,

Dan

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Monday, June 03, 2013 3:57 PM
> To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Subject: RE: [sacm] Updated Candidate Charter Text
> 
> Dan,
> 
> I think it read very well.
> 
> As for email participation, sometimes the runners are lined up
> at the start line and just waiting for the starting gun to go off.
> So, lack of movement does not mean lack of interest.
> 
> Mike
> 
> 
> Romascanu, Dan (Dan)
> Sent: Monday, June 03, 2013 8:44 AM
> To: Adam W. Montville; [email-masked]
> Subject: Re: [sacm] Updated Candidate Charter Text
> 
> Hi,
> 
> - does it clarify in a satisfactory manner the questions asked on the
> list
> and especially the ones asked by our AD?
> - does it reflect the consensus of the mail list on the scope of the
> first
> phase of the proposed WG?
> All answers welcome. Any answer different than 'yes' should be
> accompanied
> by concrete comments on issues that still need clarification, and items
> we
> still need to work for consensus.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Adam W. Montville
> > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and
> > put the following together.
> >
> > I would love to see a dramatic increase in SACM participation
> > throughout this month - especially relating to the charter, which
> > should be our primary focus at this point, and then limited to the
> > first several milestones.
> >
> > operators' ability to prioritize risk based on timely information
> > about threats and vulnerabilities. This working group will define
> > security automation protocols and data format standards in support of
> > information security processes and practices. These standards will
> > help security practitioners to be more effective by automating routine
> > tasks related to client and server security, freeing them to focus on
> > more advanced tasks. The initial focus of this work is to address
> > enterprise use cases pertaining to the asses  sment 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.
> >
> > Assessment of endpoint posture assessment entails the following
> > general
> > steps:
> >
> > 1. Relevant endpoints are identified and classified based on the
> > targets of the policy/policies to be evaluated
> >
> > 2. For each endpoint, determine what elements of posture information
> > to collect based on the policy/policies to be evaluated
> >
> > 3. For each element of the endpoint posture data, identify the
> > mechanism for data collection and what content is needed, if any, to
> > support data collection
> >
> > checks pertaining to a particular posture element may be used to
> > support data collection.
> >
> > 6. Report collected endpoint posture as identified in step 2.  This
> > will likely be done on an individual basis for each identified
> > endpoint, requiring aggregation of data collected from multiple
> > endpoints as needed based on the identified policy.
> >
> > 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.
> >
> > house specific versions of checklists (i.e. benchmarks), may be
> > required to satisfy different use cases (i.e. a NEA-specific use vs. a
> > generally applicable assessment used during continuous monitoring).
> > 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.
> >
> > collecting actual endpoint posture
> >
> > Internet-Draft which will document existing work in the IETF or in
> > other SDOs which can 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 (for example for the repository
> > access
> > protocol) and can be used or re-used to meet the goals of more than
> > one working group.
> >
> > 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.
> >
> > 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 thier configurations along with an understanding of layered
> > defenses.  Then, injecting known threat information with mitigation
> > options assists the organization in turning detailed security
> > decisions into business-relevant decisions.  The MILE protocols, RID
> > and ROLIE, enable the exchange of structured data and are designed to
> > carry any structured format.  While RID may be used  in multiple
> > sharing models and provides multiple communication flows (report,
> > query, etc.) with the ability to enable peer-to-peer object level
> > security, ROLIE provides a RESTful repository transport option with
> > only the need for a browser on the client end, removing deployment
> barriers.
> >
> > Apr. 2014 - Submission to the IESG of the Internet-Draft on
> > Requirements for consideration as Informational RFC
> >
> > Oct. 2014 - Submission to the IESG of the Internet-Draft for a
> > protocol and data format for retrieving configuration and policy
> > information for driving data collection and analysis for consideration
> > as standards- track RFC
> >
> > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol
> > and data format for collecting actual endpoint posture for
> > consideration as standards-track RFC
> >

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 3 Jun 2013 13:03:09 +0000

Yes, I believe this text addresses the questions asked
and is ready for submission to the IESG.

I did notice what I believe are two typos:

* In this sentence, I think "may be" should be "which
  may be":

> A content repository is expected to house specific versions
> of checklists (i.e. benchmarks), may be required to satisfy
> different use cases (i.e. a NEA-specific use vs. a generally
> applicable assessment used during continuous monitoring).

* In this sentence, I think the word "an" should appear

> vulnerability identifiers, and so on.

With those two fixes (or without them, even!),
I think this charter is ready to go.

I apologize for being quiet recently. As Mike said,
things seemed to be going so smoothly here. I didn't
realize that a nudge of support was needed.

I am happy to confirm that I'm still committed to
doing the SACM work, as agreed in the BOF sessions.
And I agree with this charter and scope.

Thanks,

Steve

> list and especially the ones asked by our AD?
> first phase of the proposed WG?
> accompanied by concrete comments on issues that still need
> clarification, and items we still need to work for consensus.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> 
> Of
> throughout
> about
> existing
> to
> mechanism
> support
> > 5. Harvest the actual values pertaining to posture elements
> identified
> > in step 3 from the endpoint.
> >
> will
> according
> required
> other
> the
> one
> for
> provide
> protocol
> and

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 3 Jun 2013 13:06:01 +0000

Actually if we are talking typos I found one more: 

s/ asses  sment/ assessment/

Regards,

Dan

> From: Stephen Hanna [mailto:[email-masked]]
> Sent: Monday, June 03, 2013 4:03 PM
> To: Romascanu, Dan (Dan); Adam W. Montville; [email-masked]
> Yes, I believe this text addresses the questions asked and is ready for
> submission to the IESG.
> 
> > A content repository is expected to house specific versions of
> > checklists (i.e. benchmarks), may be required to satisfy different use
> > cases (i.e. a NEA-specific use vs. a generally applicable assessment
> > used during continuous monitoring).
> 
> With those two fixes (or without them, even!), I think this charter is
> ready to go.
> 
> I apologize for being quiet recently. As Mike said, things seemed to be
> going so smoothly here. I didn't realize that a nudge of support was
> needed.
> 
> I am happy to confirm that I'm still committed to doing the SACM work,
> as agreed in the BOF sessions.
> > Of Romascanu, Dan (Dan)
> > > I've taken the charter
> > > (http://datatracker.ietf.org/doc/charter-ietf-
> > > needs to be maintaining, if not increasing, from that level we saw
> > > at IETF 86.
> > >
> > > to client and server security, freeing them to focus on more
> > > advanced tasks. The initial focus of this work is to address
> > > enterprise use
> > cases
> > > to rules expressed in the policy. Typically, these rules will
> > > compare the actual value against an expected value or range for
> > > specific
> > posture
> > > identifiers, asset classifications, vulnerability identifiers, and
> > > so on.
> > >
> > > SACM-related efforts are largely aligned, and may overlap, with
> > > other IETF (and non-IETF) standardization efforts.  There are common
> > > 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
> > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use
> > > Cases for consideration as Informational RFC
> > >

---

From: <[email-masked]>
Date: Mon, 3 Jun 2013 17:58:30 +0000

Yes I too agree that this does seem to answer the questions and I like Steve's comments as well.

I to am committed to the effort now and going forward.

Thanks.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 3, 2013 8:03 AM
To: "Romascanu, Dan (Dan)" <[email-masked]<mailto:[email-masked]>>, "Adam W. Montville" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Updated Candidate Charter Text

Thanks,

Steve

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Romascanu, Dan (Dan)
Sent: Monday, June 03, 2013 8:44 AM
To: Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Updated Candidate Charter Text
Hi,
Thanks to Adam for this revision.
Can we have a show of hands about this version of the charter text:
- does it clarify in a satisfactory manner the questions asked on the
list and especially the ones asked by our AD?
- does it reflect the consensus of the mail list on the scope of the
first phase of the proposed WG?
- is it good enough to be submitted to the IESG for discussions on the
formation of the WG?
All answers welcome. Any answer different than 'yes' should be
accompanied by concrete comments on issues that still need
clarification, and items we still need to work for consensus.
Thanks and Regards,
Dan
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of
> To: [email-masked]<mailto:[email-masked]>
put
throughout
about
existing
general
> 1. Relevant endpoints are identified and classified based on the
targets
> of the policy/policies to be evaluated
>
to
mechanism
support
identified
will
according
required
other
the
one
for
provide
> Apr. 2014 - Submission to the IESG of the Internet-Draft on
Requirements
> for consideration as Informational RFC
>
protocol
and
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

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

---

From: Blake Frantz <[email-masked]>
Date: Mon, 3 Jun 2013 11:49:26 -0700

I remain committed to SACM and support the updated charter and scope.

On Mon, Jun 3, 2013 at 10:58 AM, <[email-masked]> wrote:

>  *Kent Landfield*
> *McAfee | An Intel Company*
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com
>
>   From: Stephen Hanna <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>, "Adam W. Montville" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of
> Romascanu, Dan (Dan)
> > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf
> Of
> > Adam W. Montville

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 03 Jun 2013 16:57:17 -0400

Adam, thanks for taking the time to put this together and get things 
rolling again.

I do have some specific quibbles in this I'd like to fuss over, but 
don't have the time right at the moment -- hopefully by tomorrow, though.

--gun

On 6/2/2013 11:57 AM, Adam W. Montville wrote:
> 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 processes to collect, verify, and update security system configurations would allow easier automation of the processes. Automating these routine tasks would free security practitioners to focus on high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. This working group will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security, freeing them to focus on more advanced tasks. The initial focus of this work is to address enterprise use cases pertaining to the ass
 es
>   sment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209).
>
> 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 thier configurations along with an understanding of layered defenses.  Then, injecting known threat information with mitigation options assists the organization in turning detailed security decisions into business-relevant decisions.  The MILE protocols, RID and ROLIE, enable the exchange of structured data and are designed to carry any structured format.  While RID may be use
 d
>   in multiple sharing models and provides multiple communication flows (report, query, etc.) with the ability to enable peer-to-peer object level security, ROLIE provides a RESTful repository transport option with only the need for a browser on the client end, removing deployment barriers.
>

---

From: Adam Montville <[email-masked]>
Date: Mon, 3 Jun 2013 21:09:06 +0000

We can fuss over quibbles any time!  Just glad to rekindle the discussions and keep them moving in a productive direction.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Gunnar Engelbach [[email-masked]]
Sent: Monday, June 03, 2013 2:04 PM
To: Adam W. Montville
Cc: [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

--gun

 es
 d

...

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 3 Jun 2013 18:49:04 -0400

+1 on Steve's comments.
+1 on reaffirming my commitment to this work and going forward. ;-)

Some minor concerns with the current draft:

"A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring)"

The dimension of using content to satisfy different use cases is important, but the examples are not what I would expect. "NEA-specific use" I would interpret as intending to mean network access control. The NEA specifications are not prescriptive in this regard.  They can be used for general data collection, continuous monitoring, and for network access control decisions. I recommend either striking the (i.e.) examples, or using (e.g., software inventory, configuration settings, vulnerabilities) or something similar to illustrate different assessment use cases.

"in order to create solutions that do not overlap (for example for the repository access protocol)"

While the non-parenthetical text is a valid concern that should be addressed in the charter, the example text here assumes a potential solution. It is a reference to MILE's ROLIE which is a profile of the ATOM publishing protocol. The charter should not assume any specific solution.

Any decision to reuse ROLIE, to develop a different profile of ATOM publishing, or to pursue a different approach altogether is a decision we need to work out down the road once we have a better handle on the use cases, requirements, and architectural considerations. An example concern we may consider at that time is that ROLIE requires the use of IODEF as mandatory-to-implement (MTI). While this MTI may be good for incident data exchange related implementations, we are not ready at this time to consider if this MTI is a good thing or a barrier to adoption for endpoint assessment or continuous monitoring implementations.

IMHO the example should be removed from the charter, since the text outside the parenthetical addresses the general concern anyway. The MILE text later in the charter lays out the use of ROLIE as a consideration which is the better way to address it.

Sincerely,
Dave

> Stephen Hanna
> Sent: Monday, June 03, 2013 9:03 AM
> With those two fixes (or without them, even!), I think this charter is ready to
> go.
>
> I apologize for being quiet recently. As Mike said, things seemed to be going
> so smoothly here. I didn't realize that a nudge of support was needed.
>
> I am happy to confirm that I'm still committed to doing the SACM work, as
> agreed in the BOF sessions.

---

From: Sean Turner <[email-masked]>
Date: Tue, 04 Jun 2013 09:11:51 -0400

Adam,

Thanks for driving this forward.  This looks a lot better to me. 
Hopefully Gunnar can get his comments in soon and we we can see where we 
stand then.

spt

 es
 d

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 04 Jun 2013 13:19:39 -0400

My primary quibbles are below, but I'd like to start by highlighting 
something Stephen Whitlock said:  "...deviations from standard 
configurations (whether by accident or intent) would result in a 
notification..."

Going back to Dave Waltermire's proposed architecture, it included 
change notification originating from endpoints which helps feed 
Stephen's ideal, and I don't see an allowance for that in this revision.

Real time compliance/vulnerability notification originating from 
endpoint events is a desirable security goal that I think falls within 
the scope of this WG.

There is also a significant lag between the formation of a new WG and 
the delivery of usable products.

So, while top-down assessments, seems to be plenty for this WG to gnaw 
on at the moment, I'd like to also keep bottom-up in mind so that any 
work done now doesn't preclude that as a follow-on.  And, preferably, 
makes it possible to quickly add that next.

There also seems to be a chicken-and-egg type of thing of selection of 
policy versus selection of assets as the starting point.  I think both 
are valid so I tried, clumsily, to address that in my revision of the 
assessment steps, to follow.

---------------------------+++++++++++++---------------------------

The components, protocols, and content documents defined by this working 
group can be used in multiple ways such as top-down assessment of policy 
compliance, notification of compliance posture change initiated by a 
change made on an endpoint, determination of affected assets based on 
reportage of a new vulnerability, ad-hoc queries of specific asset 
settings, etc.

The initial focus of this working group is the performance of top-down 
policy assessments using the following steps:

A policy-driven assessment:

A) The content repository is queried for the content documents that 
codify the policy/policies of interest.

B) Assets are selected that match the criteria of the selected 
policy/policies.  The method of selection can include enumeration from 
known asset inventories, direct query of known assets, network 
discovery, etc.  Selection of assets may be further refined by other 
criteria such as ownership, location, role, time of day, etc.

(Note:  I used the term "asset" instead of "endpoint" because it 
includes software assets, allowing for assessments of, for example, web 
servers, virtual machine instance settings, a virtualized database 
instance running on a cluster, etc)

Alternatively, and asset-driven assessment:

A) Assets are selected based on a set of criteria (ownership, location, 
role, time of day, etc.).

B) For each asset, determine and retrieve the applicable policy/policies 
from the content repository.

For each asset:

1) Determine what elements of posture information to collect based on 
the policy/policies to be evaluated.

2) For each element of the asset posture data, identify the mechanism 
for data collection and what content is needed, if any, to support data 
collection.

(Note:  I assume this means if the collection is via direct endpoint 
query, CMDB retrieval, etc.  That means a layer of meta data is needed 
that we haven't really talked about:  authentication information, DB 
host/port, connection type, etc.  Since this is an explicit step in the 
process, should that data also be part of the standard?)

3) Harvest the actual values pertaining to posture elements identified 
in step 3 from the targeted asset(s).

4) Report collected asset posture.  This will likely be done on an 
individual basis for each identified asset , requiring aggregation of 
data collected from multiple asset as needed based on the identified policy.

 es
 d

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 5 Jun 2013 10:05:55 -0400

Great catch on change notification! The challenge with polling on a periodic basis is that the sample rate needs to be twice the rate of change. Using periodic data collection, there is a potential risk of missing a critical security-related change event that might indicate an attack is underway. If polling is performed outside the attack window, it is possible that the attack won't be noticed.

Policy driven assessment, as you have written below, can be used to address this type of detection using most of the same bits and bytes.  To support event-driven notification, the endpoint assessment software will need to be told what events to collect and pass on. Most of what is described in steps 1-4 of the draft charter still apply in setting up the event-driven collection environment. What is different is how steps 5 and 6 work. For step 5, the values are not harvested per se; they are generated based on change notifications. For step 6, incremental changes are reported on a continuous basis, until the endpoint is instructed not to collect those events anymore.

This is a desirable capability for end-user organizations and I believe it should be reflected in the charter.

Sincerely,
Dave

> Gunnar Engelbach
> Sent: Tuesday, June 04, 2013 1:20 PM
> To: Adam W. Montville
> Cc: [email-masked]
> My primary quibbles are below, but I'd like to start by highlighting something
> Stephen Whitlock said:  "...deviations from standard configurations (whether
> by accident or intent) would result in a notification..."
>
> Going back to Dave Waltermire's proposed architecture, it included change
> notification originating from endpoints which helps feed Stephen's ideal, and
> I don't see an allowance for that in this revision.
>
> Real time compliance/vulnerability notification originating from endpoint
> events is a desirable security goal that I think falls within the scope of this
> WG.
>
> There is also a significant lag between the formation of a new WG and the
> delivery of usable products.
>
> So, while top-down assessments, seems to be plenty for this WG to gnaw on
> at the moment, I'd like to also keep bottom-up in mind so that any work
> done now doesn't preclude that as a follow-on.  And, preferably, makes it
> possible to quickly add that next.
>
>
> There also seems to be a chicken-and-egg type of thing of selection of policy
> versus selection of assets as the starting point.  I think both are valid so I
> tried, clumsily, to address that in my revision of the assessment steps, to
> follow.
>
> compliance, notification of compliance posture change initiated by a change
> made on an endpoint, determination of affected assets based on reportage
> of a new vulnerability, ad-hoc queries of specific asset settings, etc.
>
> The initial focus of this working group is the performance of top-down policy
> assessments using the following steps:
>
>
> > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-sacm/)
> and comments submitted in a variety of threads (http://www.ietf.org/mail-
> archive/web/sacm/current/threads.html) and put the following together.
> >
> this month - especially relating to the charter, which should be our primary
> focus at this point, and then limited to the first several milestones.
> >
> > My concern is that SACM momentum is trailing off at a point when it needs
> to be maintaining, if not increasing, from that level we saw at IETF 86.
> >
> > 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 processes to collect, verify, and update security system
> configurations would allow easier automation of the processes. Automating
> these routine tasks would free security practitioners to focus on high priority
> tasks, and should improve operators' ability to prioritize risk based on timely
> information about threats and vulnerabilities. This working group will define
> information security processes and practices. These standards will help
> security practitioners to be more effective by automating routine tasks
> related to client and server security, freeing them to focus on more
> advanced tasks. The initial focus of this work is to address enterprise use
> cases pertaining to the ass
>  es
> 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.
> >
> > 1. A set of standards to enable assessment of endpoint posture. This area
> of focus provides for necessary language and data format specifications.
> >
> > 4. Retrieve any content needed for data collection.  Configuration checks
> pertaining to a particular posture element may be used to support data
> collection.
> >
> > 6. Report collected endpoint posture as identified in step 2.  This will likely
> be done on an individual basis for each identified endpoint, requiring
> aggregation of data collected from multiple endpoints as needed based on
> the identified policy.
> >
> > 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.
> >
> 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. a NEA-specific use vs. a generally applicable
> assessment used during continuous monitoring).  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.
> >
> retrieving configuration and policy information for driving data collection and
> analysis
> Internet-Draft which will document existing work in the IETF or in other SDOs
> which can 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.
> >
> IETF (including, but not limited to MILE and NEA) in order to create solutions
> that do not overlap (for example for the repository access protocol) and can
> be used or re-used to meet the goals of more than one working group.
> >
> regulatory organizations, and if necessary reuse existing liaison relationships
> or request the establishment of new liaison relationships.
> >
> > 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.
> >
> 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
> vulnerabilities to those endpoints, and thier configurations along with an
> understanding of layered defenses.  Then, injecting known threat
> designed to carry any structured format.  While RID may be use
>  d
> >   in multiple sharing models and provides multiple communication flows
> (report, query, etc.) with the ability to enable peer-to-peer object level
> security, ROLIE provides a RESTful repository transport option with only the
> need for a browser on the client end, removing deployment barriers.
> >
> > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data
> format for retrieving configuration and policy information for driving data
> collection and analysis
> >
> > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data
> format for collecting actual endpoint posture
> >
> > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol and
> data format for retrieving configuration and policy information for driving
> data collection and analysis for consideration as standards-track RFC
> >
> > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data
> format for collecting actual endpoint posture for consideration as standards-
> track RFC
> >

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 5 Jun 2013 10:29:53 -0400

Are you suggesting that the steps should be made less prescriptive? Do you have any wording in mind to avoid this concern?

Dave

> Sent: Wednesday, June 05, 2013 10:25 AM
> To: Waltermire, David A.; [email-masked];
> [email-masked]
> Cc: [email-masked]
> And if we later discover that the procedure needs to change again, do we
> have to go through a re-charter?
> I believe this should be characterized as an example, not prescriptive.
>
> Mike
>
> Waltermire, David A.
> Sent: Wednesday, June 05, 2013 10:06 AM
> To: Gunnar Engelbach; Adam W. Montville
> Cc: [email-masked]
> Great catch on change notification! The challenge with polling on a periodic
> basis is that the sample rate needs to be twice the rate of change. Using
> periodic data collection, there is a potential risk of missing a critical
> security-related change event that might indicate an attack is underway. If
> polling is performed outside the attack window, it is possible that the
> attack won't be noticed.
>
> Policy driven assessment, as you have written below, can be used to address
> this type of detection using most of the same bits and bytes.  To support
> event-driven notification, the endpoint assessment software will need to be
> told what events to collect and pass on. Most of what is described in steps
> 1-4 of the draft charter still apply in setting up the event-driven
> collection environment. What is different is how steps 5 and 6 work. For
> step 5, the values are not harvested per se; they are generated based on
> change notifications. For step 6, incremental changes are reported on a
> continuous basis, until the endpoint is instructed not to collect those
> events anymore.
>
> > Of Gunnar Engelbach
> > The components, protocols, and content documents defined by this
> > working group can be used in multiple ways such as top-down assessment
> > of policy compliance, notification of compliance posture change
> > initiated by a change made on an endpoint, determination of affected
> > assets based on reportage of a new vulnerability, ad-hoc queries of
> specific asset settings, etc.
> >
> > includes software assets, allowing for assessments of, for example,
> > web servers, virtual machine instance settings, a virtualized database
> > A) Assets are selected based on a set of criteria (ownership,
> > location, role, time of day, etc.).
> >
> > B) For each asset, determine and retrieve the applicable
> > policy/policies from the content repository.
> >
> >
> > For each asset:
> >
> > for data collection and what content is needed, if any, to support
> > data collection.
> >
> > host/port, connection type, etc.  Since this is an explicit step in
> > the process, should that data also be part of the standard?)
> >
> >
> > > (http://datatracker.ietf.org/doc/charter-ietf-sacm/)
> > > needs
> > information is a challenging task for organizations of all sizes, and
> > many security practitioners spend much of their time on manual processes.
> > configurations would allow easier automation of the processes.
> > Automating these routine tasks would free security practitioners to
> > focus on high priority tasks, and should improve operators' ability to
> > prioritize risk based on timely information about threats and
> > vulnerabilities. This working group will define security automation
> > protocols and data format standards in support of information security
> > processes and practices. These standards will help security
> > tasks. The initial focus of this work is to address enterprise use
> > cases pertaining to the ass  es
> > >   sment of endpoint posture (using the definitions of Endpoint and
> > > Posture
> > from RFC 5209).
> > >
> > > area
> > for data collection and what content is needed, if any, to support
> > data collection
> > >
> > > checks
> > > identified in
> > step 3 from the endpoint.
> > >
> > > will likely
> > aggregation of data collected from multiple endpoints as needed based
> > on the identified policy.
> > >
> > 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
> > installation state, in which case the actual and expected values may
> > be "installed" or "not installed." Evaluation of multiple posture elements
> > configuration element identifiers, asset classifications, vulnerability
> identifiers, and so on.
> > >
> > decide to make of this document an Informational RFC, but this is not a
> mandatory deliverable.
> > >
> > > other IETF
> > NETCONF, SYSLOG, NEA, MILE, and potentially others.  Of particular
> > interest to SACM is understanding and respecting the distinctions
> > between itself and NEA and MILE.
> > >
> > carrying data- collection instructions.
> > >
> > incident, and indicator information.  SACM data formats provide ways
> > to understand what endpoints are in your environment, whether they
> > 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 thier
> > configurations along with an understanding of layered defenses.  Then,
> > injecting known threat information with mitigation options assists the
> > organization in turning detailed security decisions into
> > business-relevant decisions.  The MILE protocols, RID and ROLIE,
> > enable the exchange of structured data and are designed to carry any
> > structured format.  While RID may be use  d
> > > Nov. 2013 - Initial submission of an Internet-Draft on overview of
> > > related
> > standards work
> > >
> > format for retrieving configuration and policy information for driving
> > data collection and analysis
> > >
> > > protocol and
> > driving data collection and analysis for consideration as
> > standards-track RFC
> > >
> > > and data
> > format for collecting actual endpoint posture for consideration as
> > standards- track RFC
> > >

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 05 Jun 2013 12:23:17 -0400

Picking through the discussions and architecture documents I put 
together a list of what looks like the actual standards to be produced 
by this working group.  I have broken this list out to be explicit, so 
each outline item doesn't necessarily represent a separate deliverable.

Items in section 2) and 4) a) have not been discussed and it may be 
determined that they do not need to be shared and therefore 
vendor-proprietary solutions are expected.

1) Content repository contents
   a) Policy Types:
     i) Configuration Compliance
     ii) Known Vulnerabilities
     iii) Malware Detection
     iv) Interactive Questionnaire
     v) ...
   b) Applicability of content item
   c) Data items necessary to determine posture
   d) Guidance for collection of data items
   e) Optional content
     i) Policy assistance content (Original guidance documentation, 
policy in prose/spreadsheet format, driving regulation, instructional 
videos, etc.).
     ii) Local policy deviations
     iii) Remediation

2) Controller content
   a) Collection metadata (source, source type, authentication, etc)
   b) Content repository metadata (location, authentication, scope, etc)

3) Data storage content
   a) Asset Inventory
   b) Collected data items
   c) Assessment derivatives

4) Data transfers
   a) Content repository query/response
   b) Asset query/response
   c) Data collection request
   d) Collected data publication
   e) Collection metadata request/response
   f) Assessment request/response
   g) Assessment derivatives request/response (single/multiple assets)

---

From: Rainer Enders <[email-masked]>
Date: Wed, 5 Jun 2013 21:53:51 +0200

I feel this workgroup will address a very relevant problem. A question for
clarification that has been on my mind for a while. I assume sacm will not
address the issue of lying endpoints or the verification of endpoint
identity and/or state? Can someone confirm that this is out of scope?
Thank you.

On 6/4/13 6:11 AM, "Sean Turner" <[email-masked]> wrote:

>>(http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments
>>submitted in a variety of threads
>>throughout this month - especially relating to the charter, which should
>>be our primary focus at this point, and then limited to the first
>>several milestones.
>>
>>pertaining to the ass
>>Posture from RFC 5209).
>>will likely be done on an individual basis for each identified endpoint,
>>identifiers, asset classifications, vulnerability identifiers, and so on.
>>
>> The MILE data formats provide a format to describe incident,
>>threat-related incident, and indicator information.  SACM data formats
>>state.  The data exchanged in MILE, supplementing the SACM data, creates
>>enhanced situational awareness, thus enabling increased understanding of
>>business-relevant decisions.  The MILE protocols, RID and ROLIE, enable
>>the exchange of structured data and are designed to carry any structured
>>format.  While RID may be use
> d
>>related standards work

---

From: Adam Montville <[email-masked]>
Date: Thu, 6 Jun 2013 13:41:46 +0000

Gunnar, thanks for putting this out there.  I understand that there's a predisposition to avoid referencing existing work at this point, but I do want to point out that this list represents the areas we'd like to address and does not necessarily convey all the work products this WG would produce.  It is likely that we will reference existing work for more than a few of the items you mention.

Adam
 
________________________________________
From: [email-masked] [[email-masked]] on behalf of Gunnar Engelbach [[email-masked]]
Sent: Wednesday, June 05, 2013 9:23 AM
To: [email-masked]
Subject: [sacm] WG Standards List

2) Controller content

3) Data storage content
   a) Asset Inventory
   b) Collected data items

4) Data transfers

...

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 06 Jun 2013 10:48:26 -0400

I'm also very reticent about taking category 3) very far.  I don't think 
we want to try to define *how* data is stored, but we do want to 
document what the minimal set of data for each type is and how it is 
requested/communicated.

4) e) should be:

   *Controller* metadata request/response

---

From: Adam Montville <[email-masked]>
Date: Thu, 6 Jun 2013 17:17:08 +0000

I guess this is a question for Dan, Kathleen, and perhaps, Sean: Where do we stand right now?  What work does the *charter* need to be presentable? 

For everyone else on the list: Does the charter look "good" and workable?

Adam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rainer Enders
Sent: Wednesday, June 05, 2013 12:56 PM
To: Sean Turner; Adam W. Montville
Cc: [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

I feel this workgroup will address a very relevant problem. A question for clarification that has been on my mind for a while. I assume sacm will not address the issue of lying endpoints or the verification of endpoint identity and/or state? Can someone confirm that this is out of scope?
Thank you.

On 6/4/13 6:11 AM, "Sean Turner" <[email-masked]> wrote:

>Hopefully Gunnar can get his comments in soon and we we can see where 
>we stand then.
>
>spt
>
>> 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 processes to collect, verify, and 
>>update security system configurations would allow easier automation of 
>>the processes. Automating these routine tasks would free security 
>>enterprise use cases pertaining to the ass
> es
>>identified in step 3 from the endpoint.
>>
>> 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 
>>configuration element identifiers, asset classifications, vulnerability identifiers, and so on.
>>
>> - A standards-track document specifying a protocol and data format 
>>for retrieving configuration and policy information for driving data 
>>collection and analysis
>> In accordance with existing IETF processes, the group will 
>>communicate with and invite participation from other relevant 
>>standards bodies and regulatory organizations, and if necessary reuse 
>>existing liaison relationships or request the establishment of new liaison relationships.
>>
>>carry any structured format.  While RID may be use
> d
>>   in multiple sharing models and provides multiple communication 
>>flows (report, query, etc.) with the ability to enable peer-to-peer 
>>object level security, ROLIE provides a RESTful repository transport 
>>option with only the need for a browser on the client end, removing 
>>deployment barriers.
>>
>> After the work items in the current charter have been submitted to 
>>and approved by the IESG, the WG will recharter or close.
>>
>> Goals and Milestones
>>
>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol 
>>and data format for retrieving configuration and policy information 
>>for driving data collection and analysis
>>
>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol 
>>and data format for collecting actual endpoint posture
>>
>>as standards-track RFC

...

---

From: Sean Turner <[email-masked]>
Date: Fri, 07 Jun 2013 09:48:36 -0400

Adam,

At this point, figuring out what's to be done with Gunnar's comments is 
what's left.  If there some way to address his comments without 
rewriting the numbered list that might work.

spt

On 6/6/13 1:17 PM, Adam Montville wrote:
>>> for collecting actual endpoint posture
>>>

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 15:07:42 +0000

> Sent: Wednesday, June 05, 2013 7:06 AM
> periodic data collection, there is a potential risk of missing a critical security-
> related change event that might indicate an attack is underway. If polling is
> performed outside the attack window, it is possible that the attack won't be
> noticed.

Is this becoming too prescriptive in a way?  You rightly point out that attacks could be missed with a polling mechanism, but how are agent-less solutions going to implement anything else? 

Also, is this the type of information we need to have in a charter or is this better applied in the work products of the WG?  I think the latter.

> told what events to collect and pass on. Most of what is described in steps 1-
> 4 of the draft charter still apply in setting up the event-driven collection
> environment. What is different is how steps 5 and 6 work. For step 5, the
> values are not harvested per se; they are generated based on change
> notifications. For step 6, incremental changes are reported on a continuous
> basis, until the endpoint is instructed not to collect those events anymore.

Step 5 would need to be updated to accommodate change notification, such that results are either harvested or reported.  But, again, I think this belongs in our work products and not the charter.

> be reflected in the charter.

The more we carry on this discussion the more I question having anything other than an exemplary list of steps to help describe the concept of "configuration assessment."  We can add language to the charter without needing to enumerate all the possible use cases (we have a document for that already) and then ensure the assessment steps we provide are generic - remember the only reason they were included were to provide additional context for an uninitiated reader to better understand what this WG is about.  

To be more generic, we can take the list and turn it into something like this (I think Sean had not wanted this list to be modified, but...):

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 should be enough to provide context to an external reader to *generally* understand the problem space  this WG addresses (would be interesting to validate by getting someone wholly unfamiliar with this problem domain to review).

To me, this is perfectly acceptable - it's possible for the WG to leave the details (i.e. policy-driven vs. asset-driven, assessment polling vs. near real-time assessment, and so on) to the Use Case and Architecture documents.

Finally, I'd like to point out that the milestones and deliverables for this WG, as expressed in the present draft charter, are fairly encompassing as well.  They do not get into the details - especially in light of the lengthy list Gunnar shared.

> > assets based on reportage of a new vulnerability, ad-hoc queries of specific
> asset settings, etc.
> >
> > primary focus at this point, and then limited to the first several milestones.
> > >
> > > transmit that
> > > policies to be
> > > communicate
> > > threat-related
> > > flows

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 15:36:22 +0000

Are we straying from the intent here?  Policy driven assessments are normally evaluated against a known good.  Is this system running the approved software, approved services with the recommended configuration and permissions, etc…  If we are now talking about an event driven notification architecture, are we looking as something like IF-MAP ?  This seems to be straying and expanding the focus of the charter. I thought that was what we were trying to avoid.

Kent Landfield

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 7, 2013 10:07 AM
To: David Waltermire <[email-masked]<mailto:[email-masked]>>, Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>, "Adam W. Montville" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Updated Candidate Charter Text

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

This is a desirable capability for end-user organizations and I believe it should
be reflected in the charter.

1. Identify endpoints

Sincerely,
Dave
> Cc: [email-masked]<mailto:[email-masked]>
notification..."
asset settings, etc.
identifiers, and so on.
mandatory deliverable.
working group.
barriers.

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 16:00:45 +0000

[snip]
> > To be more generic, we can take the list and turn it into something like this
> (I think Sean had not wanted this list to be modified, but...):
> >
> > 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
[snip] 
> The charter need not to go in to gory detail and we can only guess what other
> people who haven't been involved will say when the charter goes out for
> external review.  I'm good with the existing bullet list or this shortened one
> as long as you can capture that this can supports policy-driven and/or asset-
> driven models.
> 
> spt

If we're going to "capture" that this supports policy-/asset-driven models, then the abbreviated list is better with some explanatory text that simply makes that claim.  What if we simply preface the list with something like this:

"The following general steps accommodate both policy-driven and asset-driven assessment."

Adam

---

From: Sean Turner <[email-masked]>
Date: Fri, 07 Jun 2013 11:38:54 -0400

> To me, this is perfectly acceptable - it's possible for the WG to leave the details (i.e. policy-driven vs. asset-driven, assessment polling vs. near real-time assessment, and so on) to the Use Cas…

The charter need not to go in to gory detail and we can only guess what 
other people who haven't been involved will say when the charter goes 
out for external review.  I'm good with the existing bullet list or this 
shortened one as long as you can capture that this can supports 
policy-driven and/or asset-driven models.

spt

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 07 Jun 2013 12:17:13 -0400

I'm fine with the simplified bullet points as long as it is clear that 
they are an example to help clarify the purpose of the charter and don't 
represent the exact goal of the working group.

On 6/7/2013 11:38 AM, Sean Turner wrote:
>> Is this becoming too prescriptive in a way?  You rightly point out
>> that attacks could be missed with a polling mechanism, but how are
>> agent-less solutions going to implement anything else?
>>
>> Also, is this the type of information we need to have in a charter or
>> is this better applied in the work products of the WG?  I think the
>> latter.
>>
>>
>>>
>> Step 5 would need to be updated to accommodate change notification,
>> such that results are either harvested or reported.  But, again, I
>> think this belongs in our work products and not the charter.
>>
>>>
>> The more we carry on this discussion the more I question having
>> anything other than an exemplary list of steps to help describe the
>> concept of "configuration assessment."  We can add language to the
>> charter without needing to enumerate all the possible use cases (we
>> have a document for that already) and then ensure the assessment steps
>> we provide are generic - remember the only reason they were included
>> were to provide additional context for an uninitiated reader to better
>> understand what this WG is about.
>>
>> To be more generic, we can take the list and turn it into something
>> like this (I think Sean had not wanted this list to be modified, but...):
>>
>> 1. Identify endpoints
>> This should be enough to provide context to an external reader to
>> *generally* understand the problem space  this WG addresses (would be
>> interesting to validate by getting someone wholly unfamiliar with this
>> problem domain to review).
>>
>> To me, this is perfectly acceptable - it's possible for the WG to
>> leave the details (i.e. policy-driven vs. asset-driven, assessment
>> polling vs. near real-time assessment, and so on) to the Use Case and
>> Architecture documents.
>
>> Finally, I'd like to point out that the milestones and deliverables
>> for this WG, as expressed in the present draft charter, are fairly
>> encompassing as well.  They do not get into the details - especially
>> in light of the lengthy list Gunnar shared.
>>
>>>
>>> Sincerely,
>>> Dave
>>>
>> This message and attachments may contain confidential information.  If
>> it appears that this message was sent to you by mistake, any
>> retention, dissemination, distribution or copying of this message and
>> attachments is strictly prohibited.  Please notify the sender
>> immediately and permanently delete the message and any attachments.

---

From: Sean Turner <[email-masked]>
Date: Fri, 07 Jun 2013 12:20:45 -0400

Okay so this looks like it's going to work.  Let's make the changes in 
the draft charter.

spt

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 07 Jun 2013 12:48:05 -0400

Policy, as a codification of best practices, regulatory requirements, or 
known vulnerabilities, is certainly the starting point.

The current model of top-down whole-policy assessment makes the most 
sense as a starting point, but it's also inefficient and leaves a gap of 
exposure between the time of a system change and the next assessment. 
Closing that gap by increasing the periodicity of scans just increases 
the amount of resources dedicated to security assessments (and most of 
which will show no delta), and performing security assessments is not 
the reason why organizations put money into networks.

Processing change notifications is the way out of that spiral.  That's 
not to say that this WG will deal with that to start with, or ever, but 
it all goes back to the policies, which are the core of this WG.

So my point is that while we are focusing on the more traditional 
approach, let's keep the event-oriented future in mind to the extent 
that we are able.

Similarly, Rainer Enders had a very good point about endpoint trust.  My 
feel for this WG is that it won't be addressed, but it's an important 
factor to keep in mind.  That might just be as simple as including a 
field that indicates the trust level of the collected data items.

--gun

On 6/7/2013 11:36 AM, [email-masked] wrote:
> Are we straying from the intent here?  Policy driven assessments are
> normally evaluated against a known good.  Is this system running the
> approved software, approved services with the recommended configuration
> and permissions, etc…  If we are now talking about an event driven
> notification architecture, are we looking as something like IF-MAP ?
>   This seems to be straying and expanding the focus of the charter. I
> thought that was what we were trying to avoid.
>
> *Kent Landfield*
>
> *Web: *www.mcafee.com <http://www.mcafee.com/>
>
> To: David Waltermire <[email-masked]
> <mailto:[email-masked]>>, Gunnar Engelbach
> <[email-masked]
> <mailto:[email-masked]>>, "Adam W. Montville"
> <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>         From: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]] On Behalf Of
>         Waltermire, David A.
>         Cc: [email-masked] <mailto:[email-masked]>
>     Also, is this the type of information we need to have in a charter
>     or is this better applied in the work products of the WG?  I think
>     the latter.
>
>
>     have a document for that already) and then ensure the assessment
>     steps we provide are generic - remember the only reason they were
>     included were to provide additional context for an uninitiated
>     reader to better understand what this WG is about.
>
>     *generally* understand the problem space  this WG addresses (would
>     be interesting to validate by getting someone wholly unfamiliar with
>     this problem domain to review).
>
>     polling vs. near real-time assessment, and so on) to the Use Case
>     and Architecture documents.
>
>         > From:[email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]] On Behalf
>         > Of Gunnar Engelbach
>         > Cc:[email-masked] <mailto:[email-masked]>
>         > >[email-masked] <mailto:[email-masked]>
>         >[email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     This message and attachments may contain confidential
>     information.  If it appears that this message was sent to you by
>     mistake, any retention, dissemination, distribution or copying of
>     this message and attachments is strictly prohibited.  Please notify
>     the sender immediately and permanently delete the message and any
>     attachments.
>     [email-masked] <mailto:[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 17:23:14 +0000

> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Friday, June 07, 2013 9:48 AM
> To: [email-masked]
> Cc: Adam Montville; [email-masked]; [email-masked];
> [email-masked]
> Policy, as a codification of best practices, regulatory requirements, or known
> vulnerabilities, is certainly the starting point.
> 
> sense as a starting point, but it's also inefficient and leaves a gap of exposure
> between the time of a system change and the next assessment.
> Closing that gap by increasing the periodicity of scans just increases the
> amount of resources dedicated to security assessments (and most of which
> will show no delta), and performing security assessments is not the reason
> why organizations put money into networks.

This supports the continuous monitoring part of "Security Automation and Continuous Monitoring."  

> 
> Processing change notifications is the way out of that spiral.  That's not to say
> that this WG will deal with that to start with, or ever, but it all goes back to
> the policies, which are the core of this WG.

Agree.

> 
> So my point is that while we are focusing on the more traditional approach,
> let's keep the event-oriented future in mind to the extent that we are able.

Agree.

> 
> Similarly, Rainer Enders had a very good point about endpoint trust.  My feel
> for this WG is that it won't be addressed, but it's an important factor to keep
> in mind.  That might just be as simple as including a field that indicates the
> trust level of the collected data items.

Agree.

> > approved software, approved services with the recommended
> > configuration and permissions, etc...  If we are now talking about an
> > event driven notification architecture, are we looking as something like IF-
> MAP ?

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 17:23:36 +0000

Dan, I assume you're going to make those updates?

> From: Sean Turner [mailto:[email-masked]]
> Sent: Friday, June 07, 2013 9:21 AM
> To: Adam Montville
> Cc: Waltermire, David A.; Gunnar Engelbach; Adam W. Montville;
> [email-masked]
> Okay so this looks like it's going to work.  Let's make the changes in the draft
> charter.
> 
> spt
> 
> >>> like this
> >>> value of elements 4. Compare actual element values to expected
> >>> element values 5. Report results
> > [snip]
> >> The charter need not to go in to gory detail and we can only guess
> >> what other people who haven't been involved will say when the charter
> >> goes out for external review.  I'm good with the existing bullet list
> >> or this shortened one as long as you can capture that this can
> >> supports policy-driven and/or asset- driven models.
> >>
> >> spt
> >
> > If we're going to "capture" that this supports policy-/asset-driven models,
> then the abbreviated list is better with some explanatory text that simply
> makes that claim.  What if we simply preface the list with something like this:
> >
> > This message and attachments may contain confidential information.  If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited.  Please notify the sender immediately and permanently
> delete the message and any attachments.
> >
> 
> ...

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 18:25:48 +0000

Ok, I went ahead and updated the draft charter language - see below.

Hopefully this is right.

==============================================

Assessment of endpoint posture assessment entails the following general steps, which accommodate policy-driven and asset-driven assessment:

1. Identify endpoints

5. Report results

 
Goals and Milestones

> Adam Montville
> Sent: Friday, June 07, 2013 10:24 AM
> To: Sean Turner
> Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.;
> [email-masked]
> > >>> 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
> > > [snip]
> > >> what other people who haven't been involved will say when the
> > >> charter goes out for external review.  I'm good with the existing
> > >> bullet list or this shortened one as long as you can capture that
> > >> this can supports policy-driven and/or asset- driven models.
> > >>
> > >> spt
> > >
> > then the abbreviated list is better with some explanatory text that
> > simply makes that claim.  What if we simply preface the list with something
> like this:
> > >
> > > "The following general steps accommodate both policy-driven and
> > > asset-
> > driven assessment."
> > >
> > > Adam
> > >
> > dissemination, distribution or copying of this message and attachments
> > is strictly prohibited.  Please notify the sender immediately and
> > permanently delete the message and any attachments.
> > >
> >
> > ...
>

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 19:10:15 +0000

Apparently, I didn't include all the information or grabbed the wrong example charter.  Apologies - specifically to Dave for omitting his contributions!

Either he or I will provide a corrected update.

Adam

> Sent: Friday, June 07, 2013 11:26 AM
> To: Sean Turner
> cases pertaining to the asses  sment of endpoint posture (using the
> 1. A set of standards to enable assessment of endpoint posture. This area of
> focus provides for necessary language and data format specifications.
> 
> Assessment of endpoint posture assessment entails the following general
> steps, which accommodate policy-driven and asset-driven assessment:
> 
> 1. Identify endpoints
> 
> 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. a NEA-specific use vs. a generally applicable assessment used during
> continuous monitoring).  In addition, content repositories are expected to
> store up-to-date dictionary of specific enumerations, such as those used for
> 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 (for example for the repository access protocol) and can be
> used or re-used to meet the goals of more than one working group.
> 
> In accordance with existing IETF processes, the group will communicate with
> and invite participation from other relevant standards bodies and regulatory
> organizations, and if necessary reuse existing liaison relationships or request
> the establishment of new liaison relationships.
> 
> 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.
> 
> designed to carry any structured format.  While RID may be used  in multiple
> sharing models and provides multiple communication flows (report, query,
> etc.) with the ability to enable peer-to-peer object level security, ROLIE
> provides a RESTful repository transport option with only the need for a
> browser on the client end, removing deployment barriers.
> 
> 
> > Of Adam Montville
> > > Okay so this looks like it's going to work.  Let's make the changes
> > > in the draft charter.
> > >
> > > spt
> > >
> > > >> The charter need not to go in to gory detail and we can only
> > > >> guess what other people who haven't been involved will say when
> > > >> the charter goes out for external review.  I'm good with the
> > > >> existing bullet list or this shortened one as long as you can
> > > >> capture that this can supports policy-driven and/or asset- driven
> models.
> > > >>
> > > >> spt
> > > >
> > > dissemination, distribution or copying of this message and

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 19:18:07 +0000

Updated...  Dave, let me know if I missed anything of yours.  Likewise for anyone else :-)

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

1. Identify endpoints

5. Report results

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.

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 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.  Then, injecting known threat information with mitigation options assists the organization in turning detailed security decisions into business-relevant decisions.  The MILE protocols, RID and ROLIE, enable the exchange of structured data and are designed to carry any structured format.  While RID may be used in multiple sharing models and provides multiple communication flows (report, query, etc.) with the ability to enable peer-to-peer object level security, ROLIE provides a RESTful repository transport option with only the need for a browser on the client end, removing deployment barriers.

Goals and Milestones

> Sent: Friday, June 07, 2013 12:10 PM
> To: Sean Turner
> Apparently, I didn't include all the information or grabbed the wrong
> example charter.  Apologies - specifically to Dave for omitting his
> contributions!
> 
> processes.
> > general steps, which accommodate policy-driven and asset-driven
> assessment:
> >
> > 1. Identify endpoints
> >
> > expected values may be "installed" or "not installed." Evaluation of multiple
> posture elements may be combined using Boolean logic.
> >
> > access protocol) and can be used or re-used to meet the goals of more
> than one working group.
> >
> > IETF (and non-IETF) standardization efforts.  There are common "problems"
> > query,
> > etc.) with the ability to enable peer-to-peer object level security,
> > ROLIE provides a RESTful repository transport option with only the
> > consideration as standards- track RFC
> >
> > > > Okay so this looks like it's going to work.  Let's make the
> > > > changes in the draft charter.
> > > >
> > > > spt
> > > >
> > > > then the abbreviated list is better with some explanatory text
> > > > that simply makes that claim.  What if we simply preface the list
> > > > with something
> > > like this:
> > > > >
> > > > appears that this message was sent to you by mistake, any
> > > > retention, dissemination, distribution or copying of this message
> > > > and attachments is strictly prohibited.  Please notify the sender
> > > This message and attachments may contain confidential information.
> > > If it appears that this message was sent to you by mistake, any
> > > retention, dissemination, distribution or copying of this message
> > > and attachments is strictly prohibited.  Please notify the sender

---

From: John Field <[email-masked]>
Date: Fri, 7 Jun 2013 15:32:19 -0400

Three comments:

1) A definite "thumbs Up" or "+1" on the decision to shorten the summary of
the endpoint posture assessment process to be the more succinct, conceptual
list.  At the level of the charter, this generalization is an improvement.

2) Similarly, with respect to David's comments, re: ROLIE.  I agree that
one should not pre-fetch the answer and identify a specific mechanism in
the SACM charter.  As noted, it's better to reference the collaboration
with MILE, and work to identify where we can avoid unnecessary duplication.
 ROLIE does currently specify IODEF as MTI, which would not necessarily be
appropriate for SACM repository.  Of course, OTOH, that was just a stake in
the ground for ROLIE, and this could represent an example of a place where
generalizing ROLIE could enable it's reuse by SACM.  I'm certainly open to
that...

3) And, finally, one nit-pick...quoting from the last sentence of  the
paragraph immediately following the process outline:

" Evaluation of multiple posture elements may be combined using Boolean
logic."

Suggest changing "Boolean logic" to "predicate logic"

Thanks,
John

On Fri, Jun 7, 2013 at 3:10 PM, Adam Montville <
[email-masked]> wrote:

> that
> many
> interest
> area of
> to be
> evaluated
> configuration
> collection and
> SDOs
> IETF
> with
> IETF
> interest
> collected
> an
> multiple
> ROLIE
> data
> data
> > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements
> for
> > consideration as Informational RFC
> >
> driving
> data
> standards-
> > > > > If it

-- 

John P. Field | Security Architect | Pivotal

Direct: (908) 962-3394 | [email-masked]

**
*goPivotal.com <http://www.goPivotal.com>*

---

From: Adam Montville <[email-masked]>
Date: Fri, 7 Jun 2013 22:35:32 +0000

Thanks John.  I've modified the "ROLIE paragraph" by truncating the last few sentences.  Also, changed Boolean to predicate.

Are there any further nits or really bad oversights in this copy of the charter?

If you like it as it stands, +1 it.

For me, +1

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

1. Identify endpoints

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

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.

Goals and Milestones

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 10 Jun 2013 15:20:16 -0400

+1 for me.  Are we good with handing this off to Sean today?

Sincerely,
Dave

> From: Adam Montville [mailto:[email-masked]]
> Sent: Friday, June 07, 2013 6:36 PM
> To: John Field
> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, David
> A.; [email-masked]
> Thanks John.  I've modified the "ROLIE paragraph" by truncating the last few
> sentences.  Also, changed Boolean to predicate.
> 
> cases pertaining to the assessment of endpoint posture (using the
> of multiple posture elements may be combined using predicate logic.
> 
> (i.e. asset inventory, configuration settings, or vulnerabilities).  In addition,
> content repositories are expected to store up-to-date dictionary of specific
> do not overlap and can be used or re-used to meet the goals of more than
> one working group.
> 
> threats and mitigations.

---

From: John Field <[email-masked]>
Date: Mon, 10 Jun 2013 15:34:40 -0400

+1

-- 

**

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 19:35:21 +0000

+1 for me.

Kent Landfield
McAfee Labs
[email-masked]
+1.817.637.8026

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 10 Jun 2013 15:50:48 -0400

I am mostly a +1, but would add one sentence at the end of the MILE description to tie in options for ROLIE and other transports.

Transports from MILE may be used by SACM.

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 10, 2013 3:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Field, John (Pivotal); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

+1 for me.

Kent Landfield
McAfee Labs

---

From: Adam Montville <[email-masked]>
Date: Mon, 10 Jun 2013 20:32:41 +0000

I don't have an objection to adding that sentence.  Other opinions?

> From: Moriarty, Kathleen [mailto:[email-masked]]
> Sent: Monday, June 10, 2013 12:51 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Field, John (Pivotal);
> [email-masked]; [email-masked]; Adam Montville
> I am mostly a +1, but would add one sentence at the end of the MILE
> description to tie in options for ROLIE and other transports.
> 
> Cc: [email-masked]; [email-masked]; Field, John (Pivotal);
> [email-masked]; [email-masked];
> [email-masked]
> >> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire,
> >> David A.; [email-masked]
> >> Thanks John.  I've modified the "ROLIE paragraph" by truncating the
> >> last few sentences.  Also, changed Boolean to predicate.
> >>
> manual processes.
> >> focus on high priority tasks, and should improve operators' ability
> >> to prioritize risk based on timely information about threats and
> >> protocols and data format standards in support of information
> >> practitioners to be more effective by automating routine tasks
> >> enterprise use cases pertaining to the assessment of endpoint posture
> (using the definitions of Endpoint and Posture from RFC 5209).
> >>
> >> standards, preferably IETF standards, that could support automation
> >> of asset, change, configuration, and vulnerability management.
> >>
> >> 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 predicate
> logic.
> >>
> >> required to satisfy different use cases (i.e. asset inventory,
> >> configuration settings, or vulnerabilities).  In addition, content
> >> create solutions that do not overlap and can be used or re-used to
> >> meet the goals of more than one working group.
> >>
> "problems"
> >> 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.
> >>
> >> information for driving data collection and analysis for

---

From: Adam Montville <[email-masked]>
Date: Mon, 10 Jun 2013 20:32:46 +0000

I think once we add the sentence Kathleen would like to see, we're probably good.

Any objections to that?

> From: Waltermire, David A. [mailto:[email-masked]]
> Sent: Monday, June 10, 2013 12:20 PM
> To: Adam Montville; John Field
> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]
> posture elements may be combined using predicate logic.
> >
> > understanding of current threats and mitigations.
> >

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 20:42:12 +0000

If the sentence is "Transports from MILE may be used by SACM." I have no problem with it.

Kent Landfield

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 10, 2013 3:32 PM
To: David Waltermire <[email-masked]<mailto:[email-masked]>>, John Field <[email-masked]<mailto:[email-masked]>>
Cc: Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>, "Adam W. Montville" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Updated Candidate Charter Text

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Updated Candidate Charter Text
> David A.; [email-masked]<mailto:[email-masked]>
processes.
specifications.
mandatory deliverable.
...

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 10 Jun 2013 16:53:48 -0400

Kent's sentence is fine with me, although it is covered by the other text in the charter:

"The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models."
"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."

Unless I am missing something, I think we have already said as much in the existing text.

Dave

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 10, 2013 4:42 PM
To: [email-masked]; Waltermire, David A.; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

Kent Landfield

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Updated Candidate Charter Text
processes.
specifications.
mandatory deliverable.
...

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 20:58:41 +0000

I think that was the sentence Kathleen said she wanted.  Just wanted to verify…  I agree it is already covered but if it is a bit more useful by being called out directly, I am ok with that too.

Kent Landfield

From: <Waltermire>, David Waltermire <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 10, 2013 3:53 PM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sacm] Updated Candidate Charter Text

Kent’s sentence is fine with me, although it is covered by the other text in the charter:

“The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models.”
“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.”

Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, June 10, 2013 4:42 PM
To: [email-masked]<mailto:[email-masked]>; Waltermire, David A.; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Updated Candidate Charter Text

Kent Landfield

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Updated Candidate Charter Text
processes.
specifications.
mandatory deliverable.
...

---

From: Adam Montville <[email-masked]>
Date: Mon, 10 Jun 2013 21:12:51 +0000

I agree that it is already covered, but because the additional sentence doesn't mention any specific transport or data format, I don't think there is any harm by including it.

Adam

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 10, 2013 1:59 PM
To: [email-masked]; Adam Montville; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

I think that was the sentence Kathleen said she wanted.  Just wanted to verify...  I agree it is already covered but if it is a bit more useful by being called out directly, I am ok with that too.

Kent Landfield

Dave

Kent Landfield

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Updated Candidate Charter Text
processes.
specifications.
mandatory deliverable.
...

...

---

From: Adam Montville <[email-masked]>
Date: Mon, 10 Jun 2013 21:13:27 +0000

Sean, are you good with the charter (either before or after adding the sentence proposed by Kathleen)?

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 10 Jun 2013 21:24:57 +0000

Let's not add redundant text. Otherwise, we'll need to add more sentences saying that transports and data formats may come from NEA and so forth.

Either way, I'm +1 on sending the revised charter to Sean.

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Monday, June 10, 2013 5:13 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

Adam

To: [email-masked]<mailto:[email-masked]>; Adam Montville; [email-masked]<mailto:[email-masked]>

Kent Landfield

Dave

Kent Landfield

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Updated Candidate Charter Text
processes.
specifications.
mandatory deliverable.
...

...

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 10 Jun 2013 18:01:42 -0400

A similar sentence is already there for NEA, which trigged the request for the addition.  The thought was more to make sure people understand that the transports are flexible and can carry any data formats, they are not specific to data formats in MILE.  If GRC-Exchange gets revived, that would be a clear example.

Thanks,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Monday, June 10, 2013 5:25 PM
To: Adam Montville; [email-masked]; [email-masked]; Field, John (Pivotal)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Monday, June 10, 2013 5:13 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Updated Candidate Charter Text

Adam

Kent Landfield

Dave

Kent Landfield

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Updated Candidate Charter Text
processes.
specifications.
mandatory deliverable.
...

...

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 10 Jun 2013 22:11:15 +0000

Good point. Never mind.

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Monday, June 10, 2013 6:02 PM
To: Stephen Hanna; Adam Montville; [email-masked]; [email-masked]; Field, John (Pivotal)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Updated Candidate Charter Text

Thanks,
Kathleen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Monday, June 10, 2013 5:25 PM
To: Adam Montville; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Field, John (Pivotal)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Updated Candidate Charter Text

Thanks,

Steve

Adam

Kent Landfield

Dave

Kent Landfield

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Updated Candidate Charter Text
processes.
specifications.
mandatory deliverable.
...

...

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 10 Jun 2013 19:05:25 -0400

To me, the sentence introducing the general assessment steps still reads 
like there's only one expected approach to assessment.

Michael Hammer suggested changing that from

"Assessment of endpoint posture assessment entails the following
general steps, which accommodate policy-driven and asset-driven
assessment:"

to:

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

which is good enough for me.

---

From: Sean Turner <[email-masked]>
Date: Tue, 11 Jun 2013 11:47:53 -0400

I think this is a reasonable suggestion and unless I hear otherwise I'm 
going to add it to the charter.

spt

On 6/10/13 7:05 PM, Gunnar Engelbach wrote:
>>>>> Are there any further nits or really bad oversights in this copy of
>>>>> the
>>> charter?
>>>>>
>>>>> existing liaison relationships or request the establishment of new
>>>>> liaison
>>> relationships.
>>>>>

---

From: "Adam W. Montville" <[email-masked]>
Date: Tue, 11 Jun 2013 08:50:08 -0700

+1
On Jun 11, 2013, at 8:47 AM, Sean Turner <[email-masked]> wrote:

> I think this is a reasonable suggestion and unless I hear otherwise I'm going to add it to the charter.
> 
> spt
>

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 11 Jun 2013 15:56:08 +0000

+1

> Sent: Tuesday, June 11, 2013 11:50 AM
> To: Sean Turner
> Cc: [email-masked]; Adam Montville; Field, John (Pivotal); Gunnar
> Engelbach; [email-masked]; Moriarty, Kathleen;
> >>>>>> decide to make of this document an Informational RFC, but this
> is
> >>>>>> not a
> >>>> mandatory deliverable.
> >>>>>>
> information.
> If

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 11 Jun 2013 11:58:15 -0400

+1

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Tuesday, June 11, 2013 11:56 AM
To: Adam W. Montville; Sean Turner
Cc: [email-masked]; Adam Montville; Field, John (Pivotal); Gunnar Engelbach; [email-masked]; Moriarty, Kathleen; [email-masked]
Subject: RE: [sacm] Updated Candidate Charter Text

+1

---

From: <[email-masked]>
Date: Tue, 11 Jun 2013 15:57:24 +0000

+1

Kent Landfield
McAfee Labs

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 11 Jun 2013 12:03:59 -0400

+1

> Sent: Tuesday, June 11, 2013 11:48 AM
> To: Gunnar Engelbach
> Cc: Adam Montville; Moriarty, Kathleen; [email-masked];
> Waltermire, David A.; [email-masked]; [email-masked]; Field, John
> (Pivotal)
> > To me, the sentence introducing the general assessment steps still
> > reads like there's only one expected approach to assessment.
> >
> >
> > "An example of such an endpoint posture assessment could include, but
> > is not limited to, the following general steps:"
> >
> >
> >>> Of [email-masked]
> >>>>> Thanks John.  I've modified the "ROLIE paragraph" by truncating
> >>>>> the last few sentences.  Also, changed Boolean to predicate.
> >>>>>
> >>>>> Are there any further nits or really bad oversights in this copy
> >>>>> of the
> >>> charter?
> >>>>>
> >>>>> 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 processes to collect, verify, and update security
> >>>>> system configurations would allow easier automation of the
> processes.
> >>>>> Automating these routine tasks would free security practitioners
> >>>>> to focus on high priority tasks, and should improve operators'
> >>>>> ability to prioritize risk based on timely information about
> >>>>> threats and vulnerabilities. This working group will define
> >>>>> security automation protocols and data format standards in support
> >>>>> of information security processes and practices. These standards
> >>>>> will help security practitioners to be more effective by
> >>>>> automating routine tasks related to client and server security,
> >>>>> freeing them to focus on more advanced tasks. The initial focus of
> >>>>> this work is to address enterprise use cases pertaining to the
> >>>>> assessment of endpoint posture
> >>>>> standards, preferably IETF standards, that could support
> >>>>> automation of asset, change, configuration, and vulnerability
> management.
> >>>>>
> >>>>> 1. A set of standards to enable assessment of endpoint posture.
> >>>>> This area of focus provides for necessary language and data format
> >>> specifications.
> >>>>>
> >>>>> 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
> >>> predicate logic.
> >>>>>
> >>>>> 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
> >>>>> configuration element identifiers,
> >>>>> for retrieving configuration and policy information for driving
> >>>>> The working group will create an overview of related standards
> >>>>> work Internet-Draft which will document existing work in the IETF
> >>>>> or in other SDOs which can 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.
> >>>>>
> >>>>> standards bodies and regulatory organizations, and if necessary
> >>>>> reuse existing liaison relationships or request the establishment
> >>>>> of new liaison
> >>> relationships.
> >>>>>
> >>>>> found in SACM, that may be addressed by the work done in SNMP,
> >>>>> IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.  Of
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> Oct. 2013 - Initial submission of an Internet-Draft on
> >>>>> Requirements taking into consideration RFC5706 and RFC3535
> >>>>>
> >>>>> and data format for retrieving configuration and policy
> >>>>> information for driving data collection and analysis
> >>>>>
> >>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a
> >>>>> protocol and data format for collecting actual endpoint posture
> >>>>> for consideration as standards- track RFC
> >>>>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 11 Jun 2013 16:12:28 +0000

+1

> Moriarty, Kathleen
> Sent: Tuesday, June 11, 2013 6:58 PM
> To: Sean Turner
> Cc: [email-masked]
> > reads
> > of
> > system
> > >>>>>> to prioritize risk based on timely information about threats
> > >>>>>> and vulnerabilities. This working group will define security
> > automation
> > automation
> > This
> > >>>>>> 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
> > predicate
> > >>>>>> assessment (see step 2 above).  A content repository is
> > >>>>>> expected
> > to
> > work
> > >>>>>> developing solutions to the SACM requirements. The working
> > >>>>>> group
> > may
> > in
> > reuse
> > IPFIX,
> > repository
> > >>>>>> for further analysis and action.  NEA may also serve the
> > >>>>>> purpose
> > of
> > >>>>>> SACM data, creates enhanced situational awareness, thus
> > >>>>>> enabling increased understanding of current threats and
> mitigations.
> > >>>>>>
> > >>>>>> SACM Architecture for consideration as Informational RFC
> > >>>>>>
> > >>>>>> protocol and data format for retrieving configuration and
> > >>>>>> policy information for driving data collection and analysis for

---

From: Sean Turner <[email-masked]>
Date: Tue, 11 Jun 2013 12:36:12 -0400

All,

This charter is ready in my mind.  If you don't agree, then it's time to 
speak up.  You can do so here on this mailing list, to me privately, or 
more publicly on the [email-masked] mailing list.

What happens now is that I'm going to enter the charter for internal 
IESG review.  It's a one week review so it can't be on the 6/13 telechat 
but it'll be on the 6/27.  I expect comments before then and I'll mostly 
be fielding the questions.  I'm queued up the management ADs and the 
applications ADs so none of this should be a surprise to them, but I've 
no doubt questions will be asked.

Assuming internal review is navigated successfully, the charter will go 
for external review.  This is where the announcement of a possible new 
WG goes to a bunch of SDOs and the IETF list.  Sometimes this step can 
be skipped (for recharters) but it doesn't make any sense to do that for 
new wgs in my mind.

At the earliest, the WG could be formed by the 11th of July.

Because there is no chance it'll be WG before the IETF 87 scheduling 
occurs, I'll enter it on the BOF wiki to reserve a slot for it on the 
agenda.  If the	 WG gets approved the slot gets used, if not then it 
goes back in to the pool.

spt

PS: *NONE* of this should stop anybody from publishing drafts under:
draft-yourlastname-sacm-somethingusefulhere-00.txt

PS: Also, a lot of the drafts I've seen in this space are bending over 
backwards to do tables.  You can do bullet points or something else 
instead no need to make table columns that aren't wide enough for many 
of the element names.

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 11 Jun 2013 12:53:25 -0400

+1

---

From: Adam Montville <[email-masked]>
Date: Wed, 12 Jun 2013 14:25:56 +0000

Can someone get the charter text updated at http://datatracker.ietf.org/wg/sacm/charter/ or tell me how to do so and I'll do it :-)

Adam
________________________________________
From: Gunnar Engelbach [[email-masked]]
Sent: Tuesday, June 11, 2013 9:53 AM
To: Sean Turner
Cc: Adam Montville; Moriarty, Kathleen; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Field, John (Pivotal)
Subject: Re: [sacm] Updated Candidate Charter Text

+1

...