Subject: Re: [sacm] Proposed SACM Charter

From: Stephen Hanna <[email-masked]>
Date: Wed, 1 Aug 2012 20:57:14 -0400

Kent,

Thanks for drafting the charter and sending it out for comments. We've got a good start here but I have a few ideas for refinement:

1.       Add "remediation and response" to the first e.g. list. In the SACM Use Cases document, use cases UC1-UC4 all include response and for good reason. Automated attacks proceed quite rapidly. Automated defense must be able to do so also, with appropriate safeguards to ensure that remediation and response don't cause more problems than they solve.

2.       For "i.e. specifications", I would say "i.e. data formats". We'll be creating specifications for many things, including data formats and network protocols. I believe in this instance, you're talking about data formats. Right?

3.       I don't really understand the parenthetical comment "i.e. operations". I think the preceding phrase ("curating domain concept instance collections in content repositories") means "storing security automation content into databases". I don't mind using fancy words for that but I don't see what "i.e. operations" has to do with that. Maybe you mean that the security operations teams will be using that content. But I think that applies to everything we're doing here.

4.       When you say "maintain an authoritative point of reference", that starts to sound like IETF or IANA would be maintaining an authoritative list of vulnerabilities and proper configurations. Of course, that isn't what you mean. I think we want to enable organizations to maintain their own content repositories. I suggest that you rewrite that sentence to fix this confusion and also change from passive voice ("It is one thing ...") to active voice. Replace that sentence with "Defining a standards representation for security content is not enough. To enable interoperable security automation, we must define standard protocols for storing, retrieving, and exchanging that content."

5.       In the numbered list of areas of focus for the WG, why do you say "device states" in item 1 and "systems' state" in item 2? Those seem to be two phrases for the same thing. Also, doesn't 2 include 1? And "response" (including remediation and mitigation) seems to be missing from this list. Do we just want to monitor our system vulnerabilities and watch them get hacked? No, I think we want to be able to use standards to fix vulnerabilities, install countermeasures and mitigations, and intervene when attacks are detected.

6.       UC2, UC4, and UC5 from the use cases document do not seem to be addressed in this charter, except perhaps for the last document on "securely sharing dynamic network state information". Maybe this omission is deliberate. I have been saying for a while that we have too many work items on our plate. If we added UC2, UC4, and UC5 to this charter, we'd probably have 3-4 times as many work items. So I'm actually OK with deciding that UC2, UC4, and UC5 aren't in scope for this WG. But we should make that decision explicitly.

7.       One of the deliverables is "A Standards Track document specifying interfaces and communication protocols used for security automation and continuous monitoring". That sounds like several documents. Why have one document that specifies multiple protocols and interfaces? And which protocols are these, exactly? I could imagine 20 different ones that could all fit in this broad category.

As I said above, this is a good first draft. Thanks for preparing it and for welcoming comments on it. We've started down the path of finding the proper scope for this WG. That's essential.

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 31, 2012 6:12 PM
To: [email-masked]
Subject: [sacm] Proposed SACM Charter

Hi all,

Here is an initial cut at the proposed SACM Working Group charter.  The intent of this is to be a starting point for the conversation. Comments are expected, encouraged and welcomed.

--------
Security Automation Continuous Monitoring (SACM)

Proposed Working Group Charter

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <[email-masked]<mailto:[email-masked]>>
     Sean Turner <[email-masked]<mailto:[email-masked]>>

Security Area Advisor:
     Sean Turner <[email-masked]<mailto:[email-masked]>>

Mailing Lists:
     General Discussion: [email-masked]<mailto:[email-masked]>
     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 is the key to escaping this rut. This working group will enable security automation standards in support of information security processes and practices where practical, such that security practitioners can be better utilized within their organizations and we can meet the more advanced needs of the security community (e.g. information sharing, continuous monitoring, result aggregation and analysis). The initial focus of this work is toaddress enterprise and SOHO use cases. The working group will achieve this by consuming and continuing (with cooperation) the security automation work already performed by various organizations around the world.

The initial work has been fruitful, and the specifications 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. Of secondary interest to this working group are the emerging security automation specifications relating to event management and continuous monitoring.

By undertaking this work, we recognize that there are multiple categories of problems in the security automation domain: defining expressions for particular domain concepts (i.e. specifications), curating domain concept instance collections in content repositories (i.e. operations), and enabling interoperability through the development and use of interfaces and communications protocols. It is one thing to define an expression for vulnerabilities and configuration items, but it is quite another to maintain an authoritative point of reference upon which tools (and their users) can rely and support the automated exchange of vulnerability and configuration information.

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 that can be used for the purpose of assessing, aggregating and comparing device states against expected values,and reporting on those results in a predefined or ad hoc manner.

2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously monitor and report on systems' state and security process effectiveness in a pre-defined or ad-hoc manner.

3. Create relationships between existing operations management standards to enable a comprehensive view of security automation, leveraging existing work and implementations.

This working group will produce the following:

* An Informational document providing an overview of security automation and continuous monitoring to include a reference model
* A Standards Track document specifying benchmark configuration representation
* An Informational document stating guidelines / requirements for specifying checking languages
* Standards Track documents specifying device state checking languages
* A Standards Track document specifying an interrogative checking language
* A Standards Track document specifying platform naming, matching and applicability
* A Standards Track document specifying asset identification and reporting information
* A Standards Track document specifying interfaces and communication protocols used for security automation and continuous monitoring
* A Standards Track document describing the messages and network protocols for distributing Security Automation Content
* A Standards Track document describing integrating security automation and Network Endpoint Assessment capabilities
* A Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems

Goals and Milestones

Needs to be developed.

-------

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: <[email-masked]>
Date: Wed, 1 Aug 2012 20:18:12 -0500

Steve,

This is great feedback and just what I was hoping for. Thank you.  Let's talk about this tomorrow in the Side Meeting.

Thanks again.

Kent Landfield

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 1, 2012 5:57 PM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Proposed SACM Charter

Kent,

Thanks for drafting the charter and sending it out for comments. We’ve got a good start here but I have a few ideas for refinement:

1.       Add “remediation and response” to the first e.g. list. In the SACM Use Cases document, use cases UC1-UC4 all include response and for good reason. Automated attacks proceed quite rapidly. Automated defense must be able to do so also, with appropriate safeguards to ensure that remediation and response don’t cause more problems than they solve.

2.       For “i.e. specifications”, I would say “i.e. data formats”. We’ll be creating specifications for many things, including data formats and network protocols. I believe in this instance, you’re talking about data formats. Right?

3.       I don’t really understand the parenthetical comment “i.e. operations”. I think the preceding phrase (“curating domain concept instance collections in content repositories”) means “storing security automation content into databases”. I don’t mind using fancy words for that but I don’t see what “i.e. operations” has to do with that. Maybe you mean that the security operations teams will be using that content. But I think that applies to everything we’re doing here.

4.       When you say “maintain an authoritative point of reference”, that starts to sound like IETF or IANA would be maintaining an authoritative list of vulnerabilities and proper configurations. Of course, that isn’t what you mean. I think we want to enable organizations to maintain their own content repositories. I suggest that you rewrite that sentence to fix this confusion and also change from passive voice (“It is one thing …”) to active voice. Replace that sentence with “Defining a standards representation for security content is not enough. To enable interoperable security automation, we must define standard protocols for storing, retrieving, and exchanging that content.”

5.       In the numbered list of areas of focus for the WG, why do you say “device states” in item 1 and “systems’ state” in item 2? Those seem to be two phrases for the same thing. Also, doesn’t 2 include 1? And “response” (including remediation and mitigation) seems to be missing from this list. Do we just want to monitor our system vulnerabilities and watch them get hacked? No, I think we want to be able to use standards to fix vulnerabilities, install countermeasures and mitigations, and intervene when attacks are detected.

6.       UC2, UC4, and UC5 from the use cases document do not seem to be addressed in this charter, except perhaps for the last document on “securely sharing dynamic network state information”. Maybe this omission is deliberate. I have been saying for a while that we have too many work items on our plate. If we added UC2, UC4, and UC5 to this charter, we’d probably have 3-4 times as many work items. So I’m actually OK with deciding that UC2, UC4, and UC5 aren’t in scope for this WG. But we should make that decision explicitly.

7.       One of the deliverables is “A Standards Track document specifying interfaces and communication protocols used for security automation and continuous monitoring”. That sounds like several documents. Why have one document that specifies multiple protocols and interfaces? And which protocols are these, exactly? I could imagine 20 different ones that could all fit in this broad category.

As I said above, this is a good first draft. Thanks for preparing it and for welcoming comments on it. We’ve started down the path of finding the proper scope for this WG. That’s essential.

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, July 31, 2012 6:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] Proposed SACM Charter

Hi all,

--------

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously monitor and report on systems’ state and security process effectiveness in a pre-defined or ad-hoc manner.

Goals and Milestones

Needs to be developed.

-------

Kent Landfield

---

From: Adam Montville <[email-masked]>
Date: Thu, 2 Aug 2012 01:32:39 +0000

I completely agree - thanks, Steve, and I'm really looking forward to a good discussion tomorrow evening.

Sent from my iPad

On Aug 1, 2012, at 6:18 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Steve,

Thanks again.

Kent Landfield

Kent,

Thanks,

Steve

Hi all,

--------

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Goals and Milestones

Needs to be developed.

-------

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Thu, 2 Aug 2012 15:40:09 +0000

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 1, 2012 5:57 PM
To: kent_landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Proposed SACM Charter

Kent,

I'd like to point out that "curation" and "storing" are really two different things.  I believe curation would include storing (strictly speaking).  I believe the intent is to manage the content more than simply provide a place for store/retrieve operations.  To me, the distinction is important, and I'd like to see this effort work toward the more pragmatic case of content management than simply store/retrieve.

As an aside, I think we would benefit from a common glossary.  This has been an issue for me for a while, and I've been meaning to create some sort of dynamic glossary the community can use, but haven't gotten around to it.  When semantics make the difference, glossaries can be of great service.  Does anyone else in the community see a need to start and maintain a glossary for our purpose here?  Such a glossary can be based on several glossaries that already exist RFC4949, CNSSI 4009, a variety of NIST publications, common control frameworks, and so on.

Something I was going to ask about at the side meeting this evening, but will pose here instead, is whether we really mean "forensics" in the traditional way (this gets back to my call for a glossary above).  When I hear the term "forensics" used in the context of information security, I think about investigative techniques which are admissible in court.  What we might mean here, at least initially, is "investigation."  Yes, we would someday want to get to the point where we can deal with "forensics" but that seems like a lot of work to abstract enough for multiple jurisdictions across many legal systems.  If we really mean "investigation," I'd opt for using that word instead or "digital investigation" or something similar – just not something that can be quite easily misconstrued as evidence gathering.

Otherwise, I agree that some use cases may not be appropriate for this particular working group, but would be something that is done in a different IETF group, or perhaps another SDO entirely.  I would enjoy seeing this Use Case document turn into something more along the lines of an overall security and compliance architecture document, thus providing a framework from which other working groups within the IETF (across areas) and other SDOs can draw information and context.

I agree with this, Steve.  It does seem like multiple documents.  I'm guessing that the intent here was to first address the specific case of continuously monitoring configuration state across an enterprise, which could be a single document, but may be better off expressed as a series of related documents.  I'm out of my realm of expertise as to which approach is better.

Thanks,

Steve

Hi all,

--------

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Goals and Milestones

Needs to be developed.

-------

Kent Landfield

---

From: <[email-masked]>
Date: Thu, 2 Aug 2012 17:15:54 -0400

+1 on Steve's comments, very good suggestions!  Can these comments get into an updated version of the charter for tonight's discussion?

I also agree on not including all of the use cases in the charter.  I believe UC 5 is assisting with the connection to MILE work.  Where we think another WG is addressing a use case, maybe it would be good to call that out.  I think it would make the most sense to have that int he use case document.  ANy thoughts?

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Hanna [[email-masked]]
Sent: Wednesday, August 01, 2012 8:57 PM
To: [email-masked]; [email-masked]
Subject: Re: [sacm] Proposed SACM Charter

Kent,

Thanks,

Steve

Hi all,

--------

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Goals and Milestones

Needs to be developed.

-------

Kent Landfield

---

From: Adam Montville <[email-masked]>
Date: Thu, 2 Aug 2012 21:32:02 +0000

Sent from my iPhone

On Aug 2, 2012, at 2:18 PM, "[email-masked]" <[email-masked]> wrote:

> Where we think another WG is addressing a use case, maybe it would be good to call that out.  I think it would make the most sense to have that int he use case document.  ANy thoughts?

Excellent suggestion.

---

From: <[email-masked]>
Date: Thu, 2 Aug 2012 16:36:08 -0500

I will try to get them in but I have a question or two on them so not all may make it in for the Side Meeting. I will definitely had clarifying questions of Steve. ;-)

Thanks.

Kent Landfield

From: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 2, 2012 2:15 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Proposed SACM Charter

Thanks,
Kathleen
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Stephen Hanna [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 01, 2012 8:57 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Proposed SACM Charter

Kent,

Thanks,

Steve

Hi all,

--------

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
     Sean Turner <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>

Security Area Advisor:
     Sean Turner <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>

Mailing Lists:
     General Discussion: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
     To Subscribe: http://www.ietf.org/mailman/listinfo/sacm
     Archive:         http://www.ietf.org/mail-archive/web/sacm

Goals and Milestones

Needs to be developed.

-------

Kent Landfield

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 2 Aug 2012 17:42:24 -0400

+1

Steve

> -----Original Message-----
> From: Adam Montville [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 5:32 PM
> To: [email-masked]
> Cc: Stephen Hanna; [email-masked]; [email-masked]
> > Where we think another WG is addressing a use case, maybe it would be
> good to call that out.  I think it would make the most sense to have
> that int he use case document.  ANy thoughts?
> 
> Excellent suggestion.

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 2 Aug 2012 17:47:57 -0400

+1.  Couldn't agree more.  This helps to draw together how efforts in other working groups relate in the context of SACM use cases. In my view this document is important in organizing thinking relative to potential work for SACM based on the other efforts in the IETF and other standards organizations.  In the long run, I would hope that we could adopt the draft into the working group and use it to capture ongoing WG consensus relative to existing and emerging use cases. 
Dave

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Montville [[email-masked]]
Sent: Thursday, August 02, 2012 11:32 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Proposed SACM Charter

Sent from my iPhone

Excellent suggestion.
[email-masked]

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 2 Aug 2012 17:47:28 -0400

Kent,

I don't feel that my suggested changes need to get into the charter before the meeting. In fact, I'd rather not see the charter get changed before the meeting. We've had lots of good questions and suggestions from lots of people in the last day or so on the list. Let's keep gathering comments and discussing them on the list and at the meeting. When/if the charter editors judge that there's rough consensus on a change, then it should go in the charter.

If you believe that there's already rough consensus on some suggestions, I suggest putting those on a slide at the SACM meeting and asking if people agree with them. If all those in the room agree, that's a good sign that there's consensus (to be confirmed on the list, of course). And if it sparks discussion, the suggestions may be refined and improved. But I'd go for highlighting key suggestions on slides for discussion instead of making edits to the charter before the meeting.

Please ask your clarifying questions of me on the list or (if they'd be better asked F2F) let's get together here in Vancouver to discuss them. I can be free at any time today or tonight (although I expect we'd both like to go to saag and sacm!).

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 02, 2012 5:36 PM
To: [email-masked]; Stephen Hanna; [email-masked]
Subject: Re: Proposed SACM Charter

Thanks.

Kent Landfield

Thanks,
Kathleen

Kent,

Thanks,

Steve

Hi all,

--------

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
     Sean Turner <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>

Security Area Advisor:
     Sean Turner <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>

Mailing Lists:

Goals and Milestones

Needs to be developed.

-------

Kent Landfield

---

From: <[email-masked]>
Date: Thu, 2 Aug 2012 16:56:15 -0500

Fair enough. These will be discussed during the meeting.

Thanks Steve!

Kent Landfield

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 2, 2012 2:47 PM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Proposed SACM Charter

Kent,

I don’t feel that my suggested changes need to get into the charter before the meeting. In fact, I’d rather not see the charter get changed before the meeting. We’ve had lots of good questions and suggestions from lots of people in the last day or so on the list. Let’s keep gathering comments and discussing them on the list and at the meeting. When/if the charter editors judge that there’s rough consensus on a change, then it should go in the charter.

If you believe that there’s already rough consensus on some suggestions, I suggest putting those on a slide at the SACM meeting and asking if people agree with them. If all those in the room agree, that’s a good sign that there’s consensus (to be confirmed on the list, of course). And if it sparks discussion, the suggestions may be refined and improved. But I’d go for highlighting key suggestions on slides for discussion instead of making edits to the charter before the meeting.

Please ask your clarifying questions of me on the list or (if they’d be better asked F2F) let’s get together here in Vancouver to discuss them. I can be free at any time today or tonight (although I expect we’d both like to go to saag and sacm!).

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, August 02, 2012 5:36 PM
To: [email-masked]<mailto:[email-masked]>; Stephen Hanna; [email-masked]<mailto:[email-masked]>
Subject: Re: Proposed SACM Charter

Thanks.

Kent Landfield

Thanks,
Kathleen

Kent,

Thanks,

Steve

Hi all,

--------

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Goals and Milestones

Needs to be developed.

-------

Kent Landfield