Subject: [sacm] Proposed Charter for the SACM WG - take 2

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Apr 2013 13:39:31 +0000

Hi,

Thanks for the comments, I have incorporated the suggestions made on the list. I have also slightly reformulated the formulation of the two standard-track deliverables, trying to be in synch with the current architectural view without implying a solution. 

Regards,

Dan

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

Name: Security Automation and Continuous Monitoring (SACM)
AREA: Security

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <stephen.farrell at cs.tcd.ie>
     Sean Turner <turners at ieca.com>

Security Area Advisor:
     Sean Turner <turners at ieca.com>

Mailing Lists:
     General Discussion: sacm at ietf.org
     To Subscribe:       http://www.ietf.org/mailman/listinfo/sacm
     Archive:            http://www.ietf.org/mail-archive/web/sacm

Description of Working Group

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 business objectives tasks, and should improve operators' ability to prioritize risk based on timely information about threats. 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 the security automation specifications supporting 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.

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 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 (especially MILE) 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.

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 

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 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: David Harrington <[email-masked]>
Date: Wed, 3 Apr 2013 12:52:08 -0400

Looks good to me. 

David Harrington
[email-masked]
603-828-1401

On Apr 3, 2013, at 9:39 AM, "Romascanu, Dan (Dan)" <[email-masked]> 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 business objectives tasks, and should improve operators' ability to prioritize risk based on timely information about threats. 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 endpoi
> nt posture (using the definitions of Endpoint and Posture from RFC 5209).
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 4 Apr 2013 09:38:51 +0000

Thanks, David. 

Other opinions? Is this text good enough to be submitted to our AD? Note that questions and proposals for changes will almost certainly surge during the IAB, IESG and External reviews. 

Regards,

Dan

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2013 7:52 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [sacm] Proposed Charter for the SACM WG - take 2
> 
> Looks good to me.
> 
> David Harrington
> [email-masked]
> 603-828-1401
> 
> 
> > Thanks for the comments, I have incorporated the suggestions made on
> the list. I have also slightly reformulated the formulation of the two
> standard-track deliverables, trying to be in synch with the current
> architectural view without implying a solution.
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> > 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 business objectives tasks, and should improve
> operators' ability to prioritize risk based on timely information about
> threats. 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 endpoi nt 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 the security automation
> specifications supporting 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.
> >
> > - 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 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 (especially MILE) 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.
> >
> > 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 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 a protocol and
> > data format for collecting actual endpoint posture
> >
> > 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: Adam Montville <[email-masked]>
Date: Thu, 4 Apr 2013 16:29:51 +0000

Dan, these changes look good to me.  

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Romascanu, Dan (Dan)
> Sent: Thursday, April 04, 2013 4:39 AM
> To: David Harrington
> Cc: [email-masked]
> Other opinions? Is this text good enough to be submitted to our AD? Note
> that questions and proposals for changes will almost certainly surge during
> the IAB, IESG and External reviews.
> 
> Regards,
> 
> Dan
> 
> 
> 
> 
> > On Apr 3, 2013, at 9:39 AM, "Romascanu, Dan (Dan)"
> > <[email-masked]>
> > wrote:
> >
> > > Hi,
> > >
> > > Securing information and the systems that store, process, and
> > > transmit that information is a challenging task for organizations of
> > > all sizes,
> > practitioners to focus on business objectives tasks, and should
> > improve operators' ability to prioritize risk based on timely
> > information about threats. 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 endpoi nt posture
> > (using the definitions of Endpoint and Posture from RFC 5209).
> > >
> > > - A standards-track document specifying a protocol and data format
> > > for 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 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.
> > >
> > 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.
> > >
> > > 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
> > >
> > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use
> > > Cases for consideration as Informational RFC
> > >
> > > information for driving data collection and analysis for

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 4 Apr 2013 18:32:52 +0000

This charter keeps getting better and better!

I do have a few nits:

* Current text says our efforts will "free security practitioners
  to focus on business objectives tasks". I don't know what that
  means. The phrase "business objectives tasks" is poor grammar
  and vague. It makes me imagine security folks being asked to
  sell products or design marketing brochures! I suggest we say
  instead "more valuable tasks".

* At the end of that sentence, we say that operators will get
  "timely information about threats". I suggest that we add
  "and vulnerabilities" at the end of that sentence. Gathering
  information about endpoint posture is more likely to inform
  us about vulnerabilities than threats, although both may be
  relevant.

* After the list of deliverables, we say that existing work
  may be "used as-is or as starting point [...]". I think
  that should say "as *a* starting point".

* In the list of "other WGs", I suggest that we list NEA.
  People often ask me what the relationship is. We should
  at least acknowledge that we know that NEA exists and
  that we're planning to avoid overlap.

  BTW, I tell people who ask that the SACM WG will use the
  endpoint posture info gathered via the NEA protocols but
  will also support other ways to gather endpoint posture,
  define more standard data formats for posture and protocols
  to retrieve configuration and policy info for driving data
  collection and analysis.

* In the list of Goals and Milestones, we're missing a line
  break before the Nov. 2013 milestone.

* In the second Jan. 2014 milestone, the word "for" should
  be inserted after "Internet-Draft".

That's all my comments. Just nits, really.

Thanks,

Steve

> Adam Montville
> Sent: Thursday, April 04, 2013 12:30 PM
> To: Romascanu, Dan (Dan); David Harrington
> Cc: [email-masked]
> > > > for collecting actual endpoint posture
> > > >
> > > > After the work items in the current charter have been submitted
> to
> > > > and