Subject: [sacm] Proposed Charter for the SACM WG

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Apr 2013 14:38:28 +0000

Hi,

Please find below a new version of the proposed charter for the SACM Working Group. I included the inputs received during and after the second BOF meeting in Orlando, I hope that I did not miss anything important. Please check carefully if all inputs were considered and if this text proposal is good enough or requires more wording changes before being submitted to the IESG for approval. I have also added Goals and Milestones, please check these carefully as well. 

Thanks and 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 most of their time on manual processes relegating them to ineffectiveness. The key to escaping this rut is security automation to collect, verify, and update system configurations with the 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.

There are multiple categories of problems in the security automation realm: enabling interoperable data exchanges through standardized protocols, defining expressions for particular domain concepts (i.e. data formats), establishing a standards-based foundation supporting the curation and exchange of security automation content collections in content repositories, and enabling interoperability through the development and use of standard interfaces and communication protocols. Content based on rich and extensible data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection of configuration and vulnerability data pertaining to enterprise assets. Information produced by these tools will provide accurate and timely situational awareness in support of organizational decision making.

The data exchange protocols will need to support several exchange types including requesting assessments and reporting on assessment results. Exchanging information across organizational boundaries will not be within scope for this effort at this time.

This working group will provide solutions to these categories of problems and the main areas of focus for this working group are described as follows:

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 related to endpoint posture
- A standards-track document specifying a protocol and data format for retrieving endpoint posture

The working group will create a taxonomy 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 developping 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 taxonomy
Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for retrieving configuration and policy information related to endpoint posture
Jan. 2014 - Initial submission of an Internet-Draft a protocol and data format for retrieving 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 related to endpoint posture for consideration as standards-track RFC
Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data format for retrieving endpoint posture for consideration as standards-track RFC

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 2 Apr 2013 12:47:08 -0400

Hi,

A couple comments below ...

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

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 most of their time on manual processes
relegating them to ineffectiveness. 
[dbh>] First, <grin> is it that much work to relegate the manual processes
to ineffectiveness? </grin> I think "them" is ambiguous. Rewording to avoid
the ambiguity would make the result too wordy.
Second, I question whether our charter should declare that security
practitioners are ineffective; Let their bosses decide whether that is true
or not. We don't need to charter that in.
My conclusion is that we should simply eliminate the "relegating them to
ineffectiveness" phrase.
I would change "most of their time" to "much of their time".

The key to escaping this rut is security automation to collect, verify, and
update system configurations with the ability to prioritize risk based on
timely information about threats. 
[dbh>] "The key ... is " sounds like an infomercial claim. I think this
would be better worded as 
"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
more advanced 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. 
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.

There are multiple categories of problems in the security automation realm:
enabling interoperable data exchanges through standardized protocols,
defining expressions for particular domain concepts (i.e. data formats),
establishing a standards-based foundation supporting the curation and
exchange of security automation content collections in content repositories,
and enabling interoperability through the development and use of standard
interfaces and communication protocols. Content based on rich and extensible
data standards and protocols will provide the authoritative instructions
needed by data-driven tools to enable the automated collection of
configuration and vulnerability data pertaining to enterprise assets.
Information produced by these tools will provide accurate and timely
situational awareness in support of organizational decision making.
[dbh>] This whole paragraph seems redundant with the previous paragraphs. It
just seems like a lot of unnecessary marketing. We've already discussed the
need for standard protocols and data formats to support automated
collecting, verifying, and configuration. We've already set expectations to
improve prioritizing risk based on timely information.
Do we really need this paragraph? What is this paragraph adding except a
wordy discussion of the same points?

The data exchange protocols will need to support several exchange types
including requesting assessments and reporting on assessment results. 
[dbh>] There is a  requirements doc in the deliverables. Do we really need
to put requirements in the charter (which could prove problematic in the
long run)?
I recommend dropping this sentence.

Exchanging information across organizational boundaries will not be within
scope for this effort at this time.
[dbh>] I would move this (scoping) sentence up to follow the (scoping)
sentence that says the initial focus will address enterprise use cases.

This working group will provide solutions to these categories of problems
and the main areas of focus for this working group are described as follows:
[dbh>] Would this be way more concise as simply "The working group will
define:"

- 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 related to endpoint posture
- A standards-track document specifying a protocol and data format for
retrieving endpoint posture
[dbh>] I'm not sure I understand the distinction of these last two lines,
and somebody (e.g., an IESG member) reading this for the first time probably
won't either.
Isn't "retrieving endpoint posture" retrieving "information related to
endpoint posture", as well?
Maybe " configuration and policy information related to endpoint posture"
needs to be more specific as to what type of information; is this
"configuration policy "?
Is part of the distinction that the config/policy might be retrieved from a
policy server, whereas the posture is the "actual configuration" (and
possibly assessment) retrieved from the endpoint itself? 
If so, can that be made clearer here (without forcing a given solution)?

The working group will create a taxonomy 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 developping 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.  
[dbh>] Might this be better called "an overview of related standards work",
which would include/compare the taxonomies defined by these other efforts?

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

[dbh>] in my mail client (Outlook), these all concatenated into one line.
<cr><lf> needed?

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 taxonomy 
[dbh>] wouldn't it make sense to do some research before defining the
architecture? Defining an architecture first could easily eliminate many
viable existing solutions. I would think an initial draft of the" existing
work" doc should precede the architecture.

Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data
format for retrieving configuration and policy information related to
endpoint posture Jan. 2014 - Initial submission of an Internet-Draft a
protocol and data format for retrieving endpoint posture 
[dbh>] I am not accustomed to seeing "initial submission" and then
"submission" items. Does initial submission equate to WGLC or IETF LC?

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 related to endpoint posture for consideration as
standards-track RFC Oct. 2014 - Submission to the IESG of the Internet-Draft
a protocol and data format for retrieving 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: Tue, 2 Apr 2013 17:03:21 +0000

Excellent comments, thanks David. I am waiting for more inputs related to the proposed text and your suggestions before spinning a second version (probably by tomorrow morning). 

Regards,

Dan

> -----Original Message-----
> From: ietfdbh [mailto:[email-masked]]
> Sent: Tuesday, April 02, 2013 7:47 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: [sacm] Proposed Charter for the SACM WG
> 
> Hi,
> 
> 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 most of their time on manual
> processes relegating them to ineffectiveness.
> [dbh>] First, <grin> is it that much work to relegate the manual
> processes to ineffectiveness? </grin> I think "them" is ambiguous.
> Rewording to avoid the ambiguity would make the result too wordy.
> practitioners are ineffective; Let their bosses decide whether that is
> true or not. We don't need to charter that in.
> The key to escaping this rut is security automation to collect, verify,
> and update system configurations with the ability to prioritize risk
> based on timely information about threats.
> would be better worded as "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 more advanced 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.
> 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).
> 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.
> 
> exchange of security automation content collections in content
> repositories, and enabling interoperability through the development and
> use of standard interfaces and communication protocols. Content based on
> rich and extensible data standards and protocols will provide the
> authoritative instructions needed by data-driven tools to enable the
> automated collection of configuration and vulnerability data pertaining
> to enterprise assets.
> [dbh>] This whole paragraph seems redundant with the previous
> paragraphs. It just seems like a lot of unnecessary marketing. We've
> already discussed the need for standard protocols and data formats to
> support automated collecting, verifying, and configuration. We've
> already set expectations to improve prioritizing risk based on timely
> information.
> [dbh>] There is a  requirements doc in the deliverables. Do we really
> need to put requirements in the charter (which could prove problematic
> in the long run)?
> Exchanging information across organizational boundaries will not be
> within scope for this effort at this time.
> This working group will provide solutions to these categories of
> problems and the main areas of focus for this working group are
> described as follows:
> retrieving endpoint posture [dbh>] I'm not sure I understand the
> distinction of these last two lines, and somebody (e.g., an IESG member)
> reading this for the first time probably won't either.
> Is part of the distinction that the config/policy might be retrieved
> from a policy server, whereas the posture is the "actual configuration"
> (and possibly assessment) retrieved from the endpoint itself?
> The working group will create a taxonomy 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 developping 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.
> [dbh>] Might this be better called "an overview of related standards
> work", which would include/compare the taxonomies defined by these other
> efforts?
> 
> 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.
> 
> 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 taxonomy [dbh>]
> wouldn't it make sense to do some research before defining the
> viable existing solutions. I would think an initial draft of the"
> existing work" doc should precede the architecture.
> 
> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and
> data format for retrieving configuration and policy information related
> to endpoint posture Jan. 2014 - Initial submission of an Internet-Draft
> a protocol and data format for retrieving endpoint posture [dbh>] I am
> not accustomed to seeing "initial submission" and then "submission"
> items. Does initial submission equate to WGLC or IETF LC?
> 
> 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 related to endpoint posture for
> consideration as standards-track RFC Oct. 2014 - Submission to the IESG
> of the Internet-Draft a protocol and data format for retrieving endpoint
> posture for consideration as standards-track RFC
> _______________________________________________
> sacm mailing list
> [email-masked]

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 2 Apr 2013 13:05:21 -0400

I'm not convinced we need to talk about their effectiveness.
I think it's pretty obvious that operators spending much of their time on
manual processes could limit their effectiveness. 
I really don't think we need to say this in the charter ...

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

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, April 02, 2013 12:55 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sacm] Proposed Charter for the SACM WG

Change to:  "... manual processes limiting their effectiveness."  ??  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ietfdbh
Sent: Tuesday, April 02, 2013 12:47 PM
To: 'Romascanu, Dan (Dan)'; [email-masked]
Subject: Re: [sacm] Proposed Charter for the SACM WG

Hi,

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

The key to escaping this rut is security automation to collect, verify, and
update system configurations with the ability to prioritize risk based on
timely information about threats. 
[dbh>] "The key ... is " sounds like an infomercial claim. I think this
would be better worded as "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
more advanced tasks, and should improve operators' ability to prioritize
risk based on timely information about threats "

retrieving endpoint posture [dbh>] I'm not sure I understand the distinction
of these last two lines, and somebody (e.g., an IESG member) reading this
for the first time probably won't either.

 
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 taxonomy [dbh>] wouldn't
it make sense to do some research before defining the architecture? Defining
an architecture first could easily eliminate many viable existing solutions.
I would think an initial draft of the" existing work" doc should precede the
architecture.

Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data
format for retrieving configuration and policy information related to
endpoint posture Jan. 2014 - Initial submission of an Internet-Draft a
protocol and data format for retrieving endpoint posture [dbh>] I am not
accustomed to seeing "initial submission" and then "submission" items. Does
initial submission equate to WGLC or IETF LC?

---

From: Adam Montville <[email-masked]>
Date: Tue, 2 Apr 2013 17:19:57 +0000

> Romascanu, Dan (Dan)
> Sent: Tuesday, April 02, 2013 10:03 AM
> To: ietfdbh; [email-masked]
> Excellent comments, thanks David. I am waiting for more inputs related to
> the proposed text and your suggestions before spinning a second version
> (probably by tomorrow morning).

Agree - great comments and they're appreciated. 

As an original author of some of the charter's source material I think it's great to have a fresh look at it.  And, I agree with all of the suggestions David made.  Being used in a WG charter was never considered when the original wording was crafted.  For a charter I prefer being succinct over making a point.

> > My conclusion is that we should simply eliminate the "relegating them
> > to ineffectiveness" phrase.
> > The key to escaping this rut is security automation to collect,
> > verify, and update system configurations with the ability to
> > prioritize risk based on timely information about threats.
> > [dbh>] "The key ... is " sounds like an infomercial claim. I think
> > this would be better worded as "Standardized processes to collect,
> > verify, and update security system configurations would allow easier
> > automation of the processes.
> > 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
> > defining expressions for particular domain concepts (i.e. data
> > formats), establishing a standards-based foundation supporting the
> > curation and exchange of security automation content collections in
> > content repositories, and enabling interoperability through the
> > development and use of standard interfaces and communication
> > protocols. Content based on rich and extensible data standards and
> > protocols will provide the authoritative instructions needed by
> > data-driven tools to enable the automated collection of configuration
> > and vulnerability data pertaining to enterprise assets.
> > Do we really need this paragraph? What is this paragraph adding except
> > a wordy discussion of the same points?
> >
> > The data exchange protocols will need to support several exchange
> > types including requesting assessments and reporting on assessment
> results.
> > [dbh>] Would this be way more concise as simply "The working group
> > will define:"
> >
> > distinction of these last two lines, and somebody (e.g., an IESG
> > member) reading this for the first time probably won't either.
> > work", which would include/compare the taxonomies defined by these
> > other efforts?
> >
> > 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.
> >
> > architecture? Defining an architecture first could easily eliminate
> > many viable existing solutions. I would think an initial draft of the"
> > data format for retrieving configuration and policy information
> > related to endpoint posture Jan. 2014 - Initial submission of an
> > Internet-Draft a protocol and data format for retrieving endpoint
> > posture [dbh>] I am not accustomed to seeing "initial submission" and then
> "submission"
> > 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
> > endpoint posture for consideration as standards-track RFC Oct. 2014 -
> > Submission to the IESG of the Internet-Draft a protocol and data
> > format for retrieving endpoint posture for consideration as
> > standards-track RFC