Subject: [sacm] Request for a SACM BOF at IETF-86

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jan 2013 15:35:12 +0000

Hi Sean,

Please accept our request for a second, WG-forming SACM BOF at IETF-86, as follows: 

•Description: Securing information and the systems that store, process, and transmit that information has become a challenging task for organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating them to ineffectiveness. Security automation to verify system configurations with the ability to prioritize risk based on increased situational awareness from shared intelligence is the key to escaping this rut. This working group will develop security automation protocols and data format standards in support of information security processes and practices where practical. These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to client and server security so that practitioners can 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).

•Responsible AD: Sean Turner 

•BoF Chairs: Kathleen Moriarty & Dan Romascanu

•Number of people expected to attend: 80 

•Length of session; 90 mins 

•Conflicts to avoid: SEC area WGs especially MILE, XRBLOCK, EMAN, OPSAWG 

•Does it require WebEX? No 

•Does it require Meetecho? Yes 

•Mailing list: ​[email-masked] 

•List archive: ​https://www.ietf.org/mailman/listinfo/sacm 

•Draft charter: ​

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 has become a challenging task for organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating them to ineffectiveness. Security automation to verify system configurations with the ability to prioritize risk based on increased situational awareness from shared intelligence is the key to escaping this rut. This working group will develop security automation protocols and data format standards in support of information security processes and practices where practical. These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to client and server security so that practitioners can 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 achieve this by enabling the exchange of shared intelligence regarding endpoint posture and continuing the security automation work already performed by various organizations around the world. The initial work has been fruitful, and the data formats previously published are ready for expansion on the international stage. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management.

By undertaking this work, we recognize that there are multiple categories of problems in the security automation domain: 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 communications protocols. Content based on rich data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection and exchange 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 meet 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. Define, either by normative reference, adoption, or creation, a set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications.

2. Define, either by normative reference, adoption, or creation, a set of standards for interacting with repositories of content related to assessment of endpoint posture.

This working group will achieve the following milestones:

- An Informational document on Use Cases and Requirements
- An Informational document on SACM Architecture
- A Standards Track document to define a protocol for interacting
  with content repositories
- Standards Track documents specifying communication protocols and
  data formats used for assessment of endpoint posture

After this work is completed, complementary deliverables may be defined.

•Internet-Drafts:
https://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases/
https://datatracker.ietf.org/doc/draft-booth-sacm-vuln-model/
https://datatracker.ietf.org/doc/draft-davidson-sacm-asr/
https://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protocols/
https://datatracker.ietf.org/doc/draft-montville-sacm-asset-identification/

---

From: Sean Turner <[email-masked]>
Date: Wed, 23 Jan 2013 15:44:02 -0500

Thanks for getting this in early.

And thanks to all those that have participated so far!  Good work on 
whittling it down.

I've got some comments, but most they're editorial nits. I put "spt>" in 
front of my comments/questions.

spt

---- original ----

Hi Sean,

Please accept our request for a second, WG-forming SACM BOF at IETF-86, 
as follows:

•Description: Securing information and the systems that store, process, 
and transmit that information has become a challenging task for

spt> I don't think anybody is going to argue that it is
spt> and has always been a challenge ;)
spt>
spt> r/has become/is

organizations of all sizes, and we find that security practitioners

spt> r/we find that security/many security

spend most of their time on manual processes relegating them to 
ineffectiveness. Security automation to verify system configurations

spt> Maybe just nit picking here but it's more than just
spt> verifying right?  I figured it would have been something like
spt> collect, verify, and update.  Some might be out of scope now
spt> but ultimately that's what you're looking for.

with the ability to prioritize risk based on increased situational

spt> Timely is used later so maybe use it here too:
spt>
spt> r/increased/timely network

awareness from shared intelligence is the key to escaping this rut.

spt> I read this sentence and I know what you're saying, but it
spt> really sounds like something from 24.  Is there some
spt> other way to say shared intelligence?

This working group will develop security automation protocols and data 
format standards in support of information security processes and 
practices where practical. These standards will help security

spt> What do you mean by practical?  I would have thought that
spt> being practical was implied ;)  Is this about reuse of
spt> existing specifications?  If it is, then I'd just drop
spt> practical because I covered the reuse bit later.

practitioners to be better utilized within their organizations by

spt> I just thought this was bit wordy:
spt> r/better utilized within their organizations by/more effective

automating routine tasks related to client and server security so that 
practitioners can focus on more advanced tasks. The initial focus of

spt> r/so that practitioners can/freeing them to

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

spt> Noted. Last time you got more than requested, but this time
spt> I'll keep it to 90 mins.

•Conflicts to avoid: SEC area WGs especially MILE, XRBLOCK, EMAN,
                      OPSAWG

spt> I'll probably add some Apps Area WGs knowing the Barry
spt> (an Apps AD) was interested last time
spt> because a lot of this is XML-schema based and they're really
spt> the folks that'll have something to say about that.

•Draft charter: ​

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Securing information and the systems that store, process, and transmit 
that information has become a challenging task for organizations of all 
sizes, and we find that security practitioners spend most of their time 
on manual processes relegating them to ineffectiveness. Security 
automation to verify system configurations with the ability to 
prioritize risk based on increased situational awareness from shared 
intelligence is the key to escaping this rut. This working group will 
develop security automation protocols and data format standards in 
support of information security processes and practices where practical. 
These standards will help security practitioners to be better utilized 
within their organizations by automating routine tasks related to client 
and server security so that practitioners can 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).

spt> Same changes as above.

The working group will achieve this by enabling the exchange of shared

spt> Is "exchange" used because you're trying to avoid using
spt> the word collection or assessment?  It's not exchange
spt> like exchange between enterprises?  It just seems an odd intro
spt> sentence right after saying the wg is scoped to just enterprise
spt> cases.
spt>
spt> If "exchange" is about sharing between enterprises I could
spt> see moving this to the 3rd paragraph and then rewording a
spt> bit because we don't have to say how great the previous
spt> efforts were:
spt>
spt> The working group will, whenever reasonable and possible,
spt> reuse existing protocols and mechanisms.  Of particular
spt> interest to this working group are the security automation
spt> specifications supporting asset, change, configuration, and
spt> vulnerability management.

intelligence regarding endpoint posture and continuing the security 
automation work already performed by various organizations around the 
world. The initial work has been fruitful, and the data formats 
previously published are ready for expansion on the international stage. 
Of particular interest to this working group are the security automation 
specifications supporting asset, change, configuration, and 
vulnerability management.

By undertaking this work, we recognize that there are multiple

spt> r/By undertaking this work, we recognize that there/There

categories of problems in the security automation domain: enabling

spt> I'm sure somebody will trip over the word domain:
spt>
spt> r/domain/realm

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 communications protocols. Content based

r/communications/communication

on rich data standards and protocols will provide the authoritative
instructions needed by data-driven tools to enable the automated 
collection and exchange of configuration and vulnerability data

spt> Because exchange it out of scope for now:
spt>
spt> r/and exchange/(and in the future exchange)

pertaining to enterprise assets. Information produced by these tools
will provide accurate and timely situational awareness in support of 
organizational decision making.

spt> I'm not sure if it's needed by I could see
spt> r/rich/rich and extensible.  The point being that we're going
spt> build in extension points to allow those organizations who
spt> want to go above and beyond what most enterprises need
spt> to still have and eat their cake.

The data exchange protocols will need to meet several exchange types

spt> Meet or support? r/meet/support

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. Define, either by normative reference, adoption, or creation, a set 
of standards to enable assessment of endpoint posture. This area of 
focus provides for necessary language and data format specifications.

2. Define, either by normative reference, adoption, or creation, a set 
of standards for interacting with repositories of content related to 
assessment of endpoint posture.

spt> Comment: I know you're trying to say "we're going to
spt> investigate what's out there", but if we're going to adopt
spt> something then we'd better make sure that it's willing to
spt> be adopted.
spt>
spt> I'd also probably just do this:
spt>
spt> 1. A set of standards to enable assessment of endpoint
spt>    posture. This area of focus provides for necessary language
spt>    and data format specifications.
spt>
spt> 2. A set of standards for interacting with repositories of
spt>    content related to assessment of endpoint posture.
spt>
spt> If you go with the rewording suggested for the new 3rd
spt> then the following isn't needed paragraph:
spt>
spt> The working group will continue to reuse existing protocols and
spt> mechanisms whenever reasonable and possible.

spt> How many of the last one are we looking at?  Is that one of each?

spt> To avoid somebody asking what "completed" means how about:
spt>
spt> After these work items have been submitted to and approved
spt> by the IESG, the WG will recharter or close.

•Internet-Drafts:

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 24 Jan 2013 01:29:38 +0000

Sean,

Thanks for your very helpful comments. I've been wanting to
wade into some of the thickets of language in the charter
to simplify and clarify them. You've made a good start.

I like all of your suggestions. If anyone has concerns or
questions related to Sean's comments, please raise them
soon. I'm going to start making the edits that he suggested
and will send out a revised charter with these edits tomorrow.

Sean did ask for a rewording of the phrase "increased
situational awareness from shared intelligence" in the
first paragraph of the charter. I suggest instead
"timely information about threats". I think that's
really what we want. Other suggestions for that text?

For context, here's the sentence before that change:

> Security automation to verify system configurations with
> the ability to prioritize risk based on increased
> situational awareness from shared intelligence is the
> key to escaping this rut.

and here's the sentence after that change:

> Security automation to verify system configurations with
> the ability to prioritize risk based on timely information
> about threats is the key to escaping this rut.

We might even want to invert the sentence to say:

> The key to escaping this rut is security automation to
> verify system configurations with the ability to
> prioritize risk based on timely information about
> threats.

This wording helps the reader know what the sentence
is claiming (we have a great idea) instead of making
them parse and understand the tremendously long subject
first and then telling them that it's a great idea.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Turner
> Sent: Wednesday, January 23, 2013 3:44 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [sacm] Request for a SACM BOF at IETF-86
> 
> •Draft charter: 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 24 Jan 2013 10:03:13 -0500

Hi,

Instead of proclaiming what a wonderful idea we have (marketing), why don't we focus on the technical benefits?

"Security automation to verify system 
configurations improves the ability to prioritize risk based on timely 
information about threats."

Or 

"Automatically gathering and verifying systems' security 
configurations improves the ability to prioritize risk based on timely 
information about threats."

I have some concerns about "the ability to prioritize risk" - whose ability? Risk to what?
Is this designed to improves an operator's ability to prioritize risk?
Or is risk assessment automation part of the WG's deliverables?

"Automatically gathering and verifying systems' security 
configurations improves an operator's ability to prioritize risk to the enterprise based on timely 
information about threats."

Are we addressing "timely information about threats"?, or is the timely information about threats something the operator gets through some external means, and operators/applications will need to compare timely information about emerging threats with system security configurations to assess the system's (or enterprise's) ability to mitigate such threats? So is "prioritizing risk based on timely information about threats" a use case we expect to support, but not part of the work of this proposed WG? The work of this proposed WG is to develop standards to enable automatically gathering security configuration postures, right? And then we let application developers and operators do risk assessment (and potentially other things) using this gathered information.

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Wednesday, January 23, 2013 8:30 PM
To: Sean Turner; Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [sacm] Request for a SACM BOF at IETF-86

Sean,

Thanks for your very helpful comments. I've been wanting to wade into some of the thickets of language in the charter to simplify and clarify them. You've made a good start.

I like all of your suggestions. If anyone has concerns or questions related to Sean's comments, please raise them soon. I'm going to start making the edits that he suggested and will send out a revised charter with these edits tomorrow.

Sean did ask for a rewording of the phrase "increased situational awareness from shared intelligence" in the first paragraph of the charter. I suggest instead "timely information about threats". I think that's really what we want. Other suggestions for that text?

For context, here's the sentence before that change:

> Security automation to verify system configurations with the ability 
> to prioritize risk based on increased situational awareness from 
> shared intelligence is the key to escaping this rut.

and here's the sentence after that change:

> Security automation to verify system configurations with the ability 
> to prioritize risk based on timely information about threats is the 

We might even want to invert the sentence to say:

> The key to escaping this rut is security automation to verify system 
> configurations with the ability to prioritize risk based on timely 
> information about threats.

This wording helps the reader know what the sentence is claiming (we have a great idea) instead of making them parse and understand the tremendously long subject first and then telling them that it's a great idea.

Thanks,

Steve

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Sean Turner
> •Description: Securing information and the systems that store, 
> process, and transmit that information has become a challenging task 
> for
> 
> spt> I don't think anybody is going to argue that it is and has always 
> spt> been a challenge ;)
> spt>
> spt> r/has become/is
> 
> spt> Maybe just nit picking here but it's more than just verifying 
> spt> right?  I figured it would have been something like collect, 
> spt> verify, and update.  Some might be out of scope now but 
> spt> ultimately that's what you're looking for.
> 
> spt> I read this sentence and I know what you're saying, but it really 
> spt> sounds like something from 24.  Is there some other way to say 
> spt> shared intelligence?
> 
> spt> What do you mean by practical?  I would have thought that being 
> spt> practical was implied ;)  Is this about reuse of existing 
> spt> specifications?  If it is, then I'd just drop practical because I 
> spt> covered the reuse bit later.
> 
> spt> Noted. Last time you got more than requested, but this time I'll 
> spt> keep it to 90 mins.
> 
> spt> I'll probably add some Apps Area WGs knowing the Barry (an Apps 
> spt> AD) was interested last time because a lot of this is XML-schema 
> spt> based and they're really the folks that'll have something to say 
> spt> about that.
> 
> that information has become a challenging task for organizations of 
> all sizes, and we find that security practitioners spend most of their 
> time on manual processes relegating them to ineffectiveness. Security 
> within their organizations by automating routine tasks related to 
> client and server security so that practitioners can 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).
> 
> spt> Is "exchange" used because you're trying to avoid using the word 
> spt> collection or assessment?  It's not exchange like exchange 
> spt> between enterprises?  It just seems an odd intro sentence right 
> spt> after saying the wg is scoped to just enterprise cases.
> spt>
> spt> If "exchange" is about sharing between enterprises I could see 
> spt> moving this to the 3rd paragraph and then rewording a bit because 
> spt> we don't have to say how great the previous efforts were:
> spt>
> spt> The working group will, whenever reasonable and possible, reuse 
> spt> existing protocols and mechanisms.  Of particular interest to 
> spt> this working group are the security automation specifications 
> spt> supporting asset, change, configuration, and vulnerability 
> spt> management.
> 
> Of particular interest to this working group are the security 
> automation specifications supporting asset, change, configuration, and 
> repositories, and enabling interoperability through the development 
> and use of standard interfaces and communications protocols. Content 
> based
> 
> spt> I'm not sure if it's needed by I could see r/rich/rich and 
> spt> extensible.  The point being that we're going build in extension 
> spt> points to allow those organizations who want to go above and 
> spt> beyond what most enterprises need to still have and eat their 
> spt> cake.
> 
> spt> Comment: I know you're trying to say "we're going to investigate 
> spt> what's out there", but if we're going to adopt something then 
> spt> we'd better make sure that it's willing to be adopted.
> spt>
> spt> If you go with the rewording suggested for the new 3rd then the 
> spt> following isn't needed paragraph:
> spt>
> spt> After these work items have been submitted to and approved by the 
> spt> IESG, the WG will recharter or close.
> 
> 
> •Internet-Drafts: