Subject: [sacm] Proposed use cases to move forward

From: "Omar Santos (osantos)" <[email-masked]>
Date: Fri, 3 Aug 2012 03:17:35 +0000

During today's IETF meeting it was suggested to narrow down the scope of the things to be initially addressed in the potential SACM working group. Several commented that UC 1 and UC3 may be the best use-cases to be initially scoped. I also agree that UC 1 & UC 3 are the best choices; and wanted to take discussion back to the alias. Even though UC 1 and UC 3 may be the best choice; they also need to be scoped and defined carefully.

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: [email-masked]
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

---

From: Luis Nunez <[email-masked]>
Date: Fri, 3 Aug 2012 08:17:59 -0400

Thanks Omar.

Below are the use cases.  I agree we should focus on refining these use cases to form a charter.  I would like to see work that will connect SCAP endpoint assessments to NEA transport mechanisms and enforcement.  There are synergies between the two that IETF could bind together.
We maybe able to combine both UC1 and UC2 into one use case.  Three things I would like to tie together are:
1. NEA
2. SCAP 
3. Endpoints.  We need to define what an endpoint is.

UC1: Assessment and Enforcement of Acceptable State
–Controlling access to networks and services based on the assessment and analysis of host and/or network state based on machine processable content.

•UC3: Security Control Verification and Monitoring
–Continuous assessment of the implementation and effectiveness of security controls based on machine processable content.

-ln

On Aug 2, 2012, at 11:17 PM, Omar Santos (osantos) wrote:

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

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 3 Aug 2012 18:51:11 -0400

I certainly agree that connecting NEA and SCAP together is a good first
step. TCG has been working on that for several years. Several vendors
have demonstrated such capabilities and one shipped this in a product.
We should be able to supply an Internet-Draft on the topic with a
proposal, if there's interest.

As for defining the term "Endpoint", RFC 5209 (the NEA Overview) has
the following definition:

   Endpoint - Any computing device that can be connected to a network.
      Such devices normally are associated with a particular link layer
      address before joining the network and potentially an IP address
      once on the network.  This includes: laptops, desktops, servers,
      cell phones, or any device that may have an IP address.

Does that definition look acceptable? I hope so, since it would be
confusing to have multiple incompatible definitions of a term in
related specs! ;-)

I would point out that there's probably more to UC1 and UC3 than
just carrying SCAP content over the NEA protocols. For one thing,
we'd want to have open, referencable standards for the relevant
SCAP specs (or something equivalent, if we can't get acceptable
IP rights for the SCAP specs). We might also want to include some
standards for response (remediation or mitigation) when problems
are detected. Or we could leave that for later. The NEA protocols
already include a standard message for remediation instructions.
See section 4.2.10 of RFC 5792. This message is very extensible
so it can include contents that support automated remediation,
in addition to the manual remediation supported by the values
defined in that spec for Remediation Parameters Type: URI and
String (human-readable instructions).

And I also agree on the importance of scoping UC1 and UC3 carefully.
We should prioritize which parts of the problem are most urgent
and focus on those first.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Luis Nunez
> Sent: Friday, August 03, 2012 8:18 AM
> To: Omar Santos
> Cc: [email-masked]
> Subject: Re: [sacm] Proposed use cases to move forward
> 
> Thanks Omar.
> 
> Below are the use cases.  I agree we should focus on refining these use
> cases to form a charter.  I would like to see work that will connect
> SCAP endpoint assessments to NEA transport mechanisms and enforcement.
> There are synergies between the two that IETF could bind together.
> -Controlling access to networks and services based on the assessment
> and analysis of host and/or network state based on machine processable
> content.
> 
> 
> *UC3: Security Control Verification and Monitoring
> -Continuous assessment of the implementation and effectiveness of
> security controls based on machine processable content.
> 
> -ln
> 
> > During today's IETF meeting it was suggested to narrow down the scope
> of the things to be initially addressed in the potential SACM working
> group. Several commented that UC 1 and UC3 may be the best use-cases to
> be initially scoped. I also agree that UC 1 & UC 3 are the best
> choices; and wanted to take discussion back to the alias. Even though
> UC 1 and UC 3 may be the best choice; they also need to be scoped and
> defined carefully.
> >
> >
> > Regards,
> >
> > Omar Santos
> > Incident Manager, PSIRT

---

From: Adam Montville <[email-masked]>
Date: Mon, 6 Aug 2012 14:27:01 +0000

>confusing to have multiple incompatible definitions of a term in

It seems acceptable to me.  If there is some distinction to be made
between the definition presented here and what Luis had in mind, let's
explore it.

>and focus on those first.

UC1 and UC3 both require assessment of endpoint state. If not for the NEA
ties in UC1, it seems a subset of UC3.  So, we should be able to start
with the main concern of UC3: Security Configuration Management.

---

From: Adam Montville <[email-masked]>
Date: Wed, 15 Aug 2012 14:29:57 +0000

>with the main concern of UC3: Security Configuration Management.

I haven't seen much activity on this thread (there was another thread,
"Using the Frame of Reference," discussing some approaches we can use to
keep us focused and meaningful).

Are there any objections to tackling UC3 followed by UC1?  Does anyone
disagree with my assertion that UC3 is a subset of UC1 and that a
reasonable starting point is Security Configuration Management?

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 15 Aug 2012 11:24:26 -0400

I agree. Let's work on UC1 and UC3. The other use cases are
valuable but just doing UC1 and UC3 is plenty of work for this
group for the next year or two (maybe five!).

I saw several emails in favor of this a few weeks ago. I thought
that it was settled. I'd like to see a revised charter and use case
document, scoped down to focus on just UC1 and UC3.

What do others think? Do we have rough consensus on this?
If so, let's get moving.

Thanks,

Steve

> From: Adam Montville [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 10:30 AM
> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos
> Cc: [email-masked]

---

From: Luis Nunez <[email-masked]>
Date: Wed, 15 Aug 2012 11:48:15 -0400

+1

-ln

---

From: Adam Montville <[email-masked]>
Date: Wed, 15 Aug 2012 16:17:47 +0000

On 8/15/12 8:24 AM, "Stephen Hanna" <[email-masked]> wrote:

>Do we have rough consensus on this?

I believe we do.  Does anyone disagree?

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 15 Aug 2012 13:12:45 -0400

+1 on scoping the charter to UC1 and UC3.

I think we are better served with a use cases document, and eventually an architecture documemnt, that is broader scoped.  Both of these documents will help inform the work we will do under the charter as it relates to the larger context.

To this end I would suggest we focus on expanding the use case document primarily in the areas of UC1 and UC3 for now.  We can expand the other use cases later.

Sincerely,
Dave

> Stephen Hanna
> Sent: Wednesday, August 15, 2012 11:24 AM
> To: Adam Montville; Luis Nunez; Omar Santos
> Cc: [email-masked]
> I agree. Let's work on UC1 and UC3. The other use cases are valuable
> but just doing UC1 and UC3 is plenty of work for this group for the
> next year or two (maybe five!).
> 
> I saw several emails in favor of this a few weeks ago. I thought that
> it was settled. I'd like to see a revised charter and use case
> > >UC1 and UC3 both require assessment of endpoint state. If not for
> the
> > NEA
> > >ties in UC1, it seems a subset of UC3.  So, we should be able to
> > >start with the main concern of UC3: Security Configuration
> Management.
> > >
> > >
> >
> >
> > "Using the Frame of Reference," discussing some approaches we can use
> > to keep us focused and meaningful).
> >

---

From: Adam Montville <[email-masked]>
Date: Wed, 15 Aug 2012 17:40:47 +0000

On 8/15/12 10:12 AM, "Waltermire, David A." <[email-masked]>
wrote:

>To this end I would suggest we focus on expanding the use case document
>primarily in the areas of UC1 and UC3 for now.  We can expand the other
>use cases later.

How would you prefer to get started?  I have some time set aside on Friday
to devote to this effort exclusively.  I am happy to work on polishing
section 3.3 and start on corresponding language in sections 4, 5, and 6.

Adam

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 15 Aug 2012 13:52:51 -0400

Adam,

That works for me.  As I mentioned, my preference would be to flesh out all sections relative to UC1 and UC3.  I would be happy to meet with you on Friday morning to dicuss how to collaborate on the edits.  We have plenty of good content to include from all the list discussion.

Sincerely,
Dave

> Sent: Wednesday, August 15, 2012 1:41 PM
> To: Waltermire, David A.; Stephen Hanna; Luis Nunez; Omar Santos
> Cc: [email-masked]
> How would you prefer to get started?  I have some time set aside on
> Friday to devote to this effort exclusively.  I am happy to work on
> polishing section 3.3 and start on corresponding language in sections
> 4, 5, and 6.
> 
> Adam
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 15 Aug 2012 17:56:28 +0000

On 8/15/12 10:52 AM, "Waltermire, David A." <[email-masked]>
wrote:

>Adam,
>
>That works for me.  As I mentioned, my preference would be to flesh out
>all sections relative to UC1 and UC3.  I would be happy to meet with you
>on Friday morning to dicuss how to collaborate on the edits.  We have
>plenty of good content to include from all the list discussion.

Agreed.  Friday's wide open for me, so just let me know when you plan to
call.

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 15 Aug 2012 14:02:08 -0400

Would 10a EDT work for you?

Thanks,
Dave

> Sent: Wednesday, August 15, 2012 1:56 PM
> >all sections relative to UC1 and UC3.  I would be happy to meet with
> >you on Friday morning to dicuss how to collaborate on the edits.  We
> >have plenty of good content to include from all the list discussion.
> 
> 
> Agreed.  Friday's wide open for me, so just let me know when you plan
> to call.
> 
> >
> >Sincerely,
> >Dave
> >
> >
> 
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 15 Aug 2012 18:09:28 +0000

Yes.

Sent from my iPhone

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 15 Aug 2012 15:55:27 -0400

I love broad scope. Don't get me wrong! But I'm concerned about
having a use cases document and an architecture document for
this working group that goes way beyond the charter and initial
scope for the group.

I'm concerned that this will lead to lots of discussions on
the sacm list and lots of effort being spent on topics that
are out of scope, diverting us from the tasks at hand and
slowing our progress.

I'm concerned that the working group chairs won't be able to
cut off discussion of topics by saying they're out of scope
for the working group.

I'm concerned that we'll get sidetracked or even derailed by
controversies that aren't relevant to the scope of the group.

I'm concerned that by including all of security automation
within our use cases and architecture, we may actually prevent
the formation of other working groups that could work on
those other use cases.

We have plenty of work to keep us busy for years with UC1
and UC3. There's agreement that the technology needed is
mature enough for IETF standardization. I suggest that
we scope this working group to address only those use cases
and that our use cases and architecture be limited to them.

I'm sorely tempted to create an ambitious architecture for
security automation that encompasses all of the use cases
that we have described so far and maybe more. I understand
that people have a hard time understanding how the NEA and
MILE and SACM standards fit together and I would love to
address that in an IETF RFC. But I have seen several grand
architecture efforts die or come to nothing in IETF. IETF is
filled with smart engineers with clever ideas. We're great at
solving problems but if we can't agree on the problem to solve
or if we choose the wrong problem, we can easily spin an
intricate and pointless web.

I think we'll do better if we scope our effort properly.

Maybe a few people can create an individual submission
describing a grand architecture and roadmap for security
automation and ask people in SACM to review and provide
feedback on that document. That would be a good way to get
a grand architecture while still ensuring that the SACM
effort keeps its focus. In IETF as in so many things, you
must keep your focus or you'll never succeed.

Thanks,

Steve

> Waltermire, David A.
> Sent: Wednesday, August 15, 2012 1:13 PM
> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos
> Cc: [email-masked]
> I think we are better served with a use cases document, and eventually
> an architecture documemnt, that is broader scoped.  Both of these
> documents will help inform the work we will do under the charter as it
> relates to the larger context.
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 15 Aug 2012 16:08:32 -0400

+2

It's worth having a broad document even if parts of it aren't clearly 
defined to stake out the expected scope of the working group and because 
considerations of the broader scope might affect decisions on the focus 
areas.

But I absolutely agree that the best way to make real progress is to 
focus on a tight subset, and it looks like UC1 and UC3 is the consensus 
(and there's no dissent on that here).

--gun

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 17 Aug 2012 12:30:02 -0400

Steve,

These are all valid concerns that I completely agree with.  What I am struggling with is insuring that the work we are embarking on remains relevant in the broader context.  My fear is that if we narrow our thinking too much, we may inadvertently make decisions that drift from addressing the broader set of use cases.  I like the idea of working on an individual draft to address the larger context.  What I am not sure about is how introduce a feedback loop that would result in minimizing this kind of risk.  I guess this type of issue is something that we will need to collectively monitor and address as needed.

Sincerely,
Dave

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 3:55 PM
To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Cc: [email-masked]
Subject: RE: [sacm] Proposed use cases to move forward

I love broad scope. Don't get me wrong! But I'm concerned about having a use cases document and an architecture document for this working group that goes way beyond the charter and initial scope for the group.

I'm concerned that this will lead to lots of discussions on the sacm list and lots of effort being spent on topics that are out of scope, diverting us from the tasks at hand and slowing our progress.

I'm concerned that the working group chairs won't be able to cut off discussion of topics by saying they're out of scope for the working group.

I'm concerned that we'll get sidetracked or even derailed by controversies that aren't relevant to the scope of the group.

I'm concerned that by including all of security automation within our use cases and architecture, we may actually prevent the formation of other working groups that could work on those other use cases.

We have plenty of work to keep us busy for years with UC1 and UC3. There's agreement that the technology needed is mature enough for IETF standardization. I suggest that we scope this working group to address only those use cases and that our use cases and architecture be limited to them.

I'm sorely tempted to create an ambitious architecture for security automation that encompasses all of the use cases that we have described so far and maybe more. I understand that people have a hard time understanding how the NEA and MILE and SACM standards fit together and I would love to address that in an IETF RFC. But I have seen several grand architecture efforts die or come to nothing in IETF. IETF is filled with smart engineers with clever ideas. We're great at solving problems but if we can't agree on the problem to solve or if we choose the wrong problem, we can easily spin an intricate and pointless web.

Maybe a few people can create an individual submission describing a grand architecture and roadmap for security automation and ask people in SACM to review and provide feedback on that document. That would be a good way to get a grand architecture while still ensuring that the SACM effort keeps its focus. In IETF as in so many things, you must keep your focus or you'll never succeed.

Thanks,

Steve

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Waltermire, David A.
> To this end I would suggest we focus on expanding the use case 
> document primarily in the areas of UC1 and UC3 for now.  We can expand 
> the other use cases later.
> 
> Sincerely,
> Dave
>

---

From: Adam Montville <[email-masked]>
Date: Fri, 17 Aug 2012 17:33:55 +0000

I like taking the scope down as well - and I think we all believe we've
agreed to UC1 and UC3.  I don't have an issue having the other use cases
(2, 4, and 5) described in the use case document, but not fleshed out in
the functional capabilities, components, and data/protocol sections.  The
charter can be derived from the use cases we take on, and a separate
informational document can help place those use cases in the right context
with respect to the "grand scheme of things."

No matter how we slice it, right now we need to focus on the use cases and
charter, and to focus on the use cases we would ideally need to work on
setting the context.  I've tried to do that (to a limited extent) with the
informational document I sent to the list.

Additionally, I think these efforts need to be done in parallel
irrespective of any idealistic dependencies.  For example, we should be
able to work on a charter, a use case doc, and an informational doc all at
the same time, but join the threads for a final alignment pass before
submitting them.

Adam

On 8/17/12 9:30 AM, "Waltermire, David A." <[email-masked]>
wrote:

>Steve,
>
>These are all valid concerns that I completely agree with.  What I am
>struggling with is insuring that the work we are embarking on remains
>relevant in the broader context.  My fear is that if we narrow our
>thinking too much, we may inadvertently make decisions that drift from
>addressing the broader set of use cases.  I like the idea of working on
>an individual draft to address the larger context.  What I am not sure
>about is how introduce a feedback loop that would result in minimizing
>this kind of risk.  I guess this type of issue is something that we will
>need to collectively monitor and address as needed.
>
>Sincerely,
>Dave
>
>
>I love broad scope. Don't get me wrong! But I'm concerned about having a
>use cases document and an architecture document for this working group
>that goes way beyond the charter and initial scope for the group.
>
>I'm concerned that this will lead to lots of discussions on the sacm list
>and lots of effort being spent on topics that are out of scope, diverting
>us from the tasks at hand and slowing our progress.
>
>I'm concerned that the working group chairs won't be able to cut off
>discussion of topics by saying they're out of scope for the working group.
>
>I'm concerned that by including all of security automation within our use
>cases and architecture, we may actually prevent the formation of other
>working groups that could work on those other use cases.
>
>We have plenty of work to keep us busy for years with UC1 and UC3.
>There's agreement that the technology needed is mature enough for IETF
>standardization. I suggest that we scope this working group to address
>only those use cases and that our use cases and architecture be limited
>to them.
>
>I'm sorely tempted to create an ambitious architecture for security
>automation that encompasses all of the use cases that we have described
>so far and maybe more. I understand that people have a hard time
>understanding how the NEA and MILE and SACM standards fit together and I
>would love to address that in an IETF RFC. But I have seen several grand
>architecture efforts die or come to nothing in IETF. IETF is filled with
>smart engineers with clever ideas. We're great at solving problems but if
>we can't agree on the problem to solve or if we choose the wrong problem,
>we can easily spin an intricate and pointless web.
>
>Maybe a few people can create an individual submission describing a grand
>architecture and roadmap for security automation and ask people in SACM
>to review and provide feedback on that document. That would be a good way
>to get a grand architecture while still ensuring that the SACM effort
>keeps its focus. In IETF as in so many things, you must keep your focus
>or you'll never succeed.
>
>Thanks,
>
>Steve
>
>> Of

---

From: <[email-masked]>
Date: Mon, 20 Aug 2012 14:59:36 -0500

Yes, I agree we need to focus. It appears we have consensus on working on UC1 and UC3.  The use case document as it exists is very broad and its intent has expanded a great deal from the initial meeting in Paris. ;-)

It is time to focus on the charter and what it is we want this working group to do. We need to put a reasonable box around the effort so we can be productive.

To that end, what follows is an updated version of the charter that was posted just prior to the Vancouver meeting.  It has taken into consideration requests made on the lists.  Let's start discussing it as is. I know there are some good suggestions that I have not gotten to incorporate yet.

One question that I did have is the draft charter talks about remediation.  What are other's thoughts on including that as a 'potential' for the work to be done under SACM?

Please take a look at it and let's talk about what is here.  We will need to develop the list of deliverables and the milestones we expect to meet but that will hopefully be driven by the base charter discussions.

As a point of reference, how does the list want to see differences from one version of the charter to the next?  Let's keep it simple if possible…

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

Proposed Working Group Charter

Chairs:
TBD
TBD

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

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

Mailing Lists:
     General Discussion: [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 develop security automation standards in support of information security processes and practices where practical. These standards will support security practitioners to be better utilized within their organizations by allowing them to meet the more advanced needs of the security community (e.g. information sharing, continuous monitoring, remediation and response, result aggregation and analysis). The initial focus of this work is to address 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 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. Of additional interest to this working group are the emerging security automation interfaces and data formats 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. 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 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.

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 the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure 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 (XCCDF)
* An Informational document stating guidelines / requirements for specifying checking languages
* Standards Track documents specifying device state checking languages (OVAL, ECL, ACEML, …)
* A Standards Track document specifying an interrogative checking language (OCIL)
* A Standards Track document specifying platform naming, matching and applicability (CPE)
* Standards Track documents specifying asset identification and reporting information (Asset ID, ARF)
* Standards Track documents 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  (content repository)
* Standards Track document describing integrating security automation and Network Endpoint Assessment capabilities (if-m for SCAP?)
* A Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems (if-map)

Goals and Milestones

TBD
--------------------------------------------

Thanks.

Kent Landfield

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

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 17, 2012 12:33 PM
To: David Waltermire <[email-masked]<mailto:[email-masked]>>, Stephen Hanna <[email-masked]<mailto:[email-masked]>>, Luis Nunez <[email-masked]<mailto:[email-masked]>>, Omar Santos <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Proposed use cases to move forward

Adam

On 8/17/12 9:30 AM, "Waltermire, David A." <[email-masked]<mailto:[email-masked]>>
wrote:

Steve,

Sincerely,
Dave

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 3:55 PM
To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Proposed use cases to move forward

Thanks,

Steve

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of Waltermire, David A.
Cc: [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of
> Cc: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > On 8/6/12 7:27 AM, "Adam Montville" <[email-masked]<mailto:[email-masked]>>
wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

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

---

From: <[email-masked]>
Date: Mon, 20 Aug 2012 15:07:35 -0500

In addition to the remediation question….  I know we talked about the applicability of this work being targeted at the enterprise.  SOHO can be an extension of the enterprise but I get the feeling from rereading traffic that SOHO should not be included in the charterapplicability and we should focus ONLY on the enterprise…

Thoughts?

Kent Landfield

From: <Landfield>, Kent Landfield <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 20, 2012 2:59 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Proposed use cases to move forward

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

Goals and Milestones

TBD

Thanks.

Kent Landfield

Adam

Steve,

Sincerely,
Dave

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 3:55 PM
To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Proposed use cases to move forward

Thanks,

Steve

-----Original Message-----
Of

---

From: Adam Montville <[email-masked]>
Date: Tue, 21 Aug 2012 13:31:24 +0000

On 8/20/12 1:07 PM, "[email-masked]"
<[email-masked]> wrote:

>In addition to the remediation questionŠ.  I know we talked about the
>applicability of this work being targeted at the enterprise.  SOHO can be
>an extension of the enterprise but I get the feeling from rereading
>traffic that SOHO should not be included in the charterapplicability and
>we should focus ONLY on the enterpriseŠ

I would like to keep initial on the enterprise, only because I don't feel
that we've completed the necessary work there for real automated
configuration assessments, let alone continuous monitoring.

Still, SOHO (and the related BYOD issues) is a hard problem, and we could
keep it there - it's important for every enterprise of size, really, and
could be equally important for the "little guy."

I don't object to the SOHO language in the most recent charter proposal
you send out, Kent.  The deliverables are still the same, really.

---

From: Luis Nunez <[email-masked]>
Date: Tue, 21 Aug 2012 09:41:38 -0400

I agree with Adam.  We first need a foundation from which to expand the uses cases.  The Enterprise use case could be the basis for others: SOHO, Data Center, Virtualization, Mobile, etc.

-ln

---

From: Adam Montville <[email-masked]>
Date: Tue, 21 Aug 2012 14:11:16 +0000

On 8/20/12 12:59 PM, "[email-masked]"
<[email-masked]> wrote:
>One question that I did have is the draft charter talks about
>remediation.  What are other's thoughts on including that as a
>'potential' for the work to be done under SACM?

I would like to see it included.  We may need to rethink some of the work
that has already been done in this area.  Maybe we start by providing some
way to standardize the minimum set of information that should be
represented in manual remediation instructions before we move on to
automated remediation - essentially, walk before we run.

>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 develop security automation standards in support
>of information security processes and practices where practical. These
>standards will support security practitioners
> to be better utilized within their organizations by allowing them to
>meet the more advanced needs of the security community (e.g. information
>sharing, continuous monitoring, remediation and response, result
>aggregation and analysis). The initial focus of this
> work is to address 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 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. Of additional interest to this working
>group are the emerging security automation interfaces and data formats
>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. 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 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.
>
>
>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 the
>state of systems, composed of many different types of devices and
>networks, operated by varying personnel, to
> ensure 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.

At some point I believe we had a 4 and 5 here as well.  I can't remember,
were those recommended to be removed?

Otherwise, I agree with the three "main" areas of focus.

>* An Informational document providing an overview of security automation
>and continuous monitoring to include a reference model

Is this a reference to the use case document or something else (I.e. the
informational document I've talked about in the past)?

>* Standards Track documents specifying device state checking languages
>(OVAL, ECL, ACEML, Š)
>* Standards Track documents 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  (content
>repository)

I would remove the word "network" from "network protocols."

>* Standards Track document describing integrating security automation and
>Network Endpoint Assessment capabilities (if-m for SCAP?)
>* A Standards Track document describing protocols and data formats for
>securely sharing dynamic network state information among security systems
>(if-map)

I was working on some thought exercises yesterday for the Use Case
document, and I think we might have some gaps in existing capabilities
that we should address (either through normative reference or by creating
something new):

1. Do we need a way to identify, express, and perhaps score patches in a
way that differs from vulnerabilities?  This may be something akin to CPE
- perhaps an extension to it.

2. Should we consider breaking apart the constituents of a technical
control checking system in a way that allows us to talk about security and
non-security related system objects?  There are almost certainly ties to
other areas of IETF and perhaps other SDOs here, but I can use OVAL as a
frame of reference.  OVAL talks about definitions, tests, objects, states,
and values (ultimately assigned to states).  Is there a need to talk about
objects, and their applicable range of states, outside the context of what
we would generically call a test?

3. Do we need a way to talk about assets in a non-identifying way?  I'm
thinking things like criticality, classification (I.e. level of secrecy),
and other properties that may not necessarily be used for the purposes of
identification?

4. Do we need to consider documents dealing with targeting issues?

These four points essentially speak to functional components that may be
lacking in the existing set of specifications/formats.  It is my
expectation that the Use Case document will identify and highlight such
gaps, where we know we need certain functional capabilities (security
configuration management including configuration assessment and
remediation, asset characterization/management, and vulnerability
assessment, perhaps among others).

>Web: www.mcafee.com <http://www.mcafee.com/>
>
>
>
>
>
>From: Adam Montville <[email-masked]>
>To: David Waltermire <[email-masked]>, Stephen Hanna
><[email-masked]>, Luis Nunez <[email-masked]>,
> Omar Santos <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Tue, 21 Aug 2012 14:13:44 +0000

On 8/20/12 12:59 PM, "[email-masked]"
<[email-masked]> wrote:

>As a point of reference, how does the list want to see differences from
>one version of the charter to the next?  Let's keep it simple if possibleŠ

Do more experienced IETFers have any suggestions?  It seems that we'll
just have to keep track of these things from "round to round" in the
e-mail list.  Kent just sent out a proposal, it'll have a period of
comment/review, then he'll probably post another draft.

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 09:14:04 -0500

So are we talking about removing the SOHO aspects from the charter for now?  I have no problem with that as it would help us to focus on the base enterprise capabilities.  If that's the direction, we could recharter down the road once we are successful with the enterprise uses.

I would personally rather have this charter more focused on what we are actually going to work on now and we can decide if we need to expand it in the future…

Kent Landfield

From: Luis Nunez <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 21, 2012 8:41 AM
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Proposed use cases to move forward

-ln

On 8/20/12 1:07 PM, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>> wrote:

---

From: Adam Montville <[email-masked]>
Date: Tue, 21 Aug 2012 14:20:59 +0000

On 8/21/12 7:14 AM, "[email-masked]"
<[email-masked]> wrote:

>So are we talking about removing the SOHO aspects from the charter for
>now?

I am not, but I am not opposed to its removal.  It depends on what others
feel.  As I tried to convey, perhaps poorly, whether the term "SOHO" is
included in the prose of the charter seems inconsequential to the
documents we want to deliver - at their core, they are still the same
documents.

That said, if taking SOHO out seems to be the right thing to do, I'm not
opposed to its removal.

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 21 Aug 2012 10:44:53 -0400

I favor removing the SOHO use cases from the charter and
focusing only on enterprise use cases for now.

SOHO adds many complications, both technical and political.
We should walk first before we try to run. There's plenty
of value in standards for enterprise security automation
and plenty of work for us to do just in addressing the
enterprise use cases. If we design in extensibility,
these standards can be extended later to cover SOHO.

Thanks,

Steve

> Adam Montville
> Sent: Tuesday, August 21, 2012 10:21 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Luis Nunez <[email-masked]>
Date: Tue, 21 Aug 2012 10:47:51 -0400

I would suggest removing SOHO for focus and clarity.  I think we can expand and extend the Enterprise to include(connect) to  SOHO later.  

thanks.

-ln

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 21 Aug 2012 10:53:54 -0400

In the current charter, I see 3 areas of focus, 2 Informational
documents, and at least 9 Standards Track documents. That's more
than one Working Group should be taking on at one time. We need
to focus on narrowing our scope not expanding it.

Remediation is a great topic but we should not work on it in
this (proposed) working group at this time. Instead, we should
include hooks for sending remediation instructions (like the
NEA Working Group did in PA-TNC) and encourage others to create
and experiment with various remediation systems. When they have
found something that works, we can bring it into SACM or just
publish it straight as an RFC.

At least, that's my view.

Thanks,

Steve

> Sent: Tuesday, August 21, 2012 10:11 AM
> To: [email-masked]; [email-masked]
> >* Standards Track documents specifying asset identification and
> reporting
> >information (Asset ID, ARF)
> >>No matter how we slice it, right now we need to focus on the use
> cases
> >>and
> >>setting the context.  I've tried to do that (to a limited extent)
> with
> >>the
> >>able to work on a charter, a use case doc, and an informational doc
> all
> >>at
> having a
> >>>I'm concerned that by including all of security automation within
> our
> >>>use
> >>>smart engineers with clever ideas. We're great at solving problems
> but
> >>>if
> >>>to review and provide feedback on that document. That would be a
> good
> >>>way
> valuable
> >>>>> > "Using the Frame of Reference," discussing some approaches we
> can
> >>>>use

---

From: Adam Montville <[email-masked]>
Date: Tue, 21 Aug 2012 14:57:55 +0000

> to focus on narrowing our scope not expanding it.

For the sake of playing devil's advocate, if we have deliverables and milestones (implying order), what warrants "to much" work?

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 09:59:59 -0500

Comments inline…

On 8/20/12 12:59 PM, "[email-masked]<mailto:[email-masked]>"

Noted.

……

No has not been in either of the posted drafts.  Both only had three.

This was intended to be something else. Not the Use Case document.  It is more the overview document we discussed in the past.

Ok.  I agree with that.

One of the discussions we had in Vancouver was around trying to reduce the scope of the working group.  I totally agree there may be other scoring mechanisms that are needed. I am also aware there is a need for a real framework to integrate all these differing scoring mechanisms.  I know there has been talk that maybe this isn't the right group to do that kind of work in.  Thoughts?

I am wondering how this plays with the charter discussion….  Maybe I need more coffee but…

Again, from a charter discussion….  I see this playing in the Asset ID / Asset reporting but much of this work is covered by the MILE Charter.

Correct me if I am wrong here folks but there is nothing to stop anyone from creating an I-D and proposing it to the working group for acceptance as a working group document after the charter is developed as long as the document can be fit under the auspices of the working group's charter.  Correct?

Kent

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 10:18:53 -0500

Steve wrote….

My question is more about how to properly address this in the charter rather than if this should be addressed directly…

Today the charter states:

    This working group will develop security automation standards in support of information security processes and
    practices where practical. These standards will support security practitioners to be betterutilized within their organizations
    by allowing them to meet the more advanced needs of the security community (e.g. information sharing, continuous monitoring,
    remediation and response, result aggregation and analysis).

My understanding is this type of reference will include remediation as a potential "in-scope" work item if there is sufficient interest in the group to do so but does not obligate us to tackle the issue directly as a deliverable.  It allows us to accept non-identified (at the time of charter) I-Ds into the working group if it is so decided by the group the I-D is a valuable work item.

Remediation aside, is my understanding of the process accurate?

Kent Landfield

---

From: Michael Hammer <[email-masked]>
Date: Tue, 21 Aug 2012 15:37:53 +0000

The charter is to keep out stuff that is off-topic.

That said, you don't want to constantly thrash on the charter.

If folks can agree on the priorities, then hopefully all will respect the
consensus.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 21, 2012 11:00 AM
To: [email-masked]; [email-masked]
Subject: Re: [sacm] Proposed use cases to move forward

Comments inline.

 

Noted.

 

..

follows:

manner.

 

 

 

 

 

 

 

This was intended to be something else. Not the Use Case document.  It is
more the overview document we discussed in the past.

 

repository)

Ok.  I agree with that.

something new):

One of the discussions we had in Vancouver was around trying to reduce the
scope of the working group.  I totally agree there may be other scoring
mechanisms that are needed. I am also aware there is a need for a real
framework to integrate all these differing scoring mechanisms.  I know there
has been talk that maybe this isn't the right group to do that kind of work
in.  Thoughts?

I am wondering how this plays with the charter discussion..  Maybe I need
more coffee but. 

identification?

Again, from a charter discussion..  I see this playing in the Asset ID /
Asset reporting but much of this work is covered by the MILE Charter.

Correct me if I am wrong here folks but there is nothing to stop anyone from
creating an I-D and proposing it to the working group for acceptance as a
working group document after the charter is developed as long as the
document can be fit under the auspices of the working group's charter.
Correct?

Kent

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 21 Aug 2012 13:15:45 -0400

Adam Montville wrote:
> For the sake of playing devil's advocate, if we have deliverables and
> milestones (implying order), what warrants "to much" work?

There's no hard-and-fast rule for this but I was just on
a boring concall so I ran some numbers on the existing
IETF SEC area Working Groups.

* The number of WG documents varies from 0 to 11 with 3/4 of the
  WGs having between 2 & 6 WG documents.

* The number of authors per WG document (not double-counting authors
  who are on more than one doc in a single WG) varies from 1.25 to
  3.5 with 2/3 of the WGs having between 1.4 and 2.3 authors per spec.

* The number of emails per month varies between about 8 and about 150.
  Removing two WGs with lots of legacy RFCs and therefore an extra
  amount of email traffic (PKIX and IPSECME), the number of emails
  per month per WG document varies between 6 and 20 with the
  average around 12.

Looking at SACM, 9 WG documents would be way more than average
for the SEC area. Our email list traffic is about 60 emails per
month. That would indicate we can support about 5 WG documents.
I think that's consistent with the number of active participants
and likely document authors that I have seen on the list so far.
I see about 15 active participants on the list in the last few
months. We could gain or lose some as time goes on but that's
what I see. If half of those become document editors, we could
easily support 4-5 WG documents.

Maybe we should figure out how to stage our work into two stages.
That way, we could have 4-5 documents in a first stage and 4-5
documents in a second stage. Many WGs do that. We can list all
the documents in our charter and have milestones that stage them.

Now that I reread your email, I think that's exactly what you
were suggesting. So maybe we're agreeing! But I still think
that remediation shouldn't be in the first two stages. It's
the least understood aspect of this work.

Thanks,

Steve

> Sent: Tuesday, August 21, 2012 10:58 AM
> To: Stephen Hanna
> Cc: [email-masked]; [email-masked]
> For the sake of playing devil's advocate, if we have deliverables and
> milestones (implying order), what warrants "to much" work?
>
>
>
>
> >
> >> that has already been done in this area.  Maybe we start by
> providing
> >> some
> >>>    To Subscribe:
> http://www.ietf.org/mailman/listinfo/sacm
> >>> pertaining to enterprise assets. Information produced by these
> tools
> >> will
> >>> 1. Define, either by normative reference, adoption, or creation, a
> set
> >> of
> >>> standards that can be used for the purpose of assessing,
> aggregating
> >> and
> >>> 2. Define, either by normative reference, adoption, or creation, a
> set
> >> of
> >>> * A Standards Track document specifying platform naming, matching
> and
> >>> applicability (CPE)
> >>> * Standards Track document describing integrating security
> automation
> >> and
> >> 1. Do we need a way to identify, express, and perhaps score patches
> in
> >> a
> >> way that differs from vulnerabilities?  This may be something akin
> to
> >> CPE
> >> control checking system in a way that allows us to talk about
> security
> >> and
> >> non-security related system objects?  There are almost certainly
> ties
> >> to
> >> other areas of IETF and perhaps other SDOs here, but I can use OVAL
> as
> >> a
> >> objects, and their applicable range of states, outside the context
> of
> >> what
> >> and other properties that may not necessarily be used for the
> purposes
> >> of
> >> identification?
> >>
> >> These four points essentially speak to functional components that
> may
> >> be
> >>>> (2, 4, and 5) described in the use case document, but not fleshed
> out
> >> in
> >>>> the functional capabilities, components, and data/protocol
> sections.
> >> The
> >>>> charter, and to focus on the use cases we would ideally need to
> work
> >> on
> >>>> irrespective of any idealistic dependencies.  For example, we
> should
> >> be
> >>>>> These are all valid concerns that I completely agree with.  What
> I
> >> am
> >>>>> addressing the broader set of use cases.  I like the idea of
> working
> >> on
> >>>>> this kind of risk.  I guess this type of issue is something that
> we
> >> will
> >>>>> I'm concerned that this will lead to lots of discussions on the
> sacm
> >>>>> list
> >>>>> discussion of topics by saying they're out of scope for the
> working
> >>>>> group.
> >>>>>
> >>>>>
> security
> >>>>> understanding how the NEA and MILE and SACM standards fit
> together
> >> and I
> >>>>> would love to address that in an IETF RFC. But I have seen
> several
> >> grand
> filled
> >>>>> Maybe a few people can create an individual submission describing
> a
> >>>>> grand
> >>>>> architecture and roadmap for security automation and ask people
> in
> >> SACM
> >>>>>> documents will help inform the work we will do under the charter
> as
> >> it
> >>>>>>>> Are there any objections to tackling UC3 followed by UC1?
> Does
> >>>>>>> anyone
> >>>>>>>> disagree with my assertion that UC3 is a subset of UC1 and
> that
> >> a

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 21 Aug 2012 13:53:35 -0400

I agree with your understanding of the process and I'm fine with having remediation mentioned in the charter. I just don't think we should have it as a deliverable in the schedule.

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 21, 2012 11:19 AM
To: Stephen Hanna; [email-masked]; [email-masked]
Subject: Re: [sacm] Proposed use cases to move forward

Steve wrote....

My question is more about how to properly address this in the charter rather than if this should be addressed directly...

Kent Landfield

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 21 Aug 2012 15:04:48 -0400

Same goes for SOHO.  I think it needs to be recognized up front that 
SOHO and Enterprise are not the same, but I don't expect the initial 
deliverables to address that.

I don't see any dissent from UC1 and UC3 as the starting point.  The 
process of breaking those up into deliverables will, I think, give a 
more concrete idea of the scope of work and help decide which items 
should get the initial attention.

--gun

On 8/21/2012 1:53 PM, Stephen Hanna wrote:
> I agree with your understanding of the process and I’m fine with having
> remediation mentioned in the charter. I just don’t think we should have
> it as a deliverable in the schedule.
>
> Thanks,
>
> Steve
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Tuesday, August 21, 2012 11:19 AM
> *To:* Stephen Hanna; [email-masked]; [email-masked]
> *Subject:* Re: [sacm] Proposed use cases to move forward
>
> Steve wrote….
>
> My question is more about how to properly address this in the charter
> rather than if this should be addressed directly…
>
>      This working group will develop security automation standards in
> support of information security processes and
>
>      practices where practical. These standards will support security
> practitioners to be betterutilized within their organizations
>
>      by allowing them to meet the more advanced needs of the
> security community (e.g. information sharing, continuous monitoring,
>
> My understanding is this type of reference will include remediation as a
> potential "in-scope" work item if there is sufficient interest in the
> group to do so but does not obligate us to tackle the issue directly as
> a deliverable.  It allows us to accept non-identified (at the time of
> charter) I-Ds into the working group if it is so decided by the group
> the I-D is a valuable work item.
>
> *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: Adam Montville <[email-masked]>
Date: Tue, 21 Aug 2012 21:40:48 +0000

Remind me not to bore you on a call - you'll have too much time to dig up
useful data :-)

At the end of it all, I believe you're correct in that we are agreeing.  I
would much prefer to see a more complete view of the work this group would
like to do over time and stage it using milestones.  I further agree that
remediation is the least understood of the subdomains, and have no issue
relegating such work to a later stage.

Adam

On 8/21/12 10:15 AM, "Stephen Hanna" <[email-masked]> wrote:

>> >> support

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 23 Aug 2012 15:10:58 -0400

I did a complete review of this proposed SACM charter today. Here are my comments. Please review and respond!

*         Now that we have narrowed our focus to UC1 and UC3, we should continue to narrow the charter to match that focus. One way to do this would be to change the proposed WG name from "Security Automation and Continuous Monitoring" to "Security Compliance Automation" OR "Security Automation for Compliance". The topic of security automation is a really broad one, including many MILE projects and other things that go way beyond UC1 and UC3.

*         In the first paragraph of the WG Description, I'd like to suggest a few changes to this sentence: "These standards will support security practitioners to be better utilized within their organizations by allowing them to meet the more advanced needs of the security community (e.g. information sharing, continuous monitoring, remediation and response, result aggregation and analysis)." Right now, the text seems to imply that our focus will be on defining standards to "meet the more advanced needs of the security community", including information sharing, continuous monitoring, remediation and response, and result aggregation and analysis. I don't quite agree. I think that our goal now is to automate routine tasks related to gathering and managing information about endpoint security so that information security practitioners can focus on more advanced needs. Our scope may include some aspects of information sharing, continuous monitoring, remediation and response, and result aggregation and analysis but not the complete and total extent of any of those broad topics. So I suggest this replacement sentence: "These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to endpoint security so that practitioners can focus on more advanced work."

*         We should delete "and SOHO" from this sentence: "The initial focus of this work is to address enterprise and SOHO use cases." We need to maintain our focus and avoid the added complexities of SOHO. Anyway, that's my view.

*         I think the last sentence in the first paragraph (about consuming and continuing work) belongs at the start of the second paragraph. The second paragraph is about how we're going to use and enhance standards developed elsewhere. The first paragraph explains why our work is needed.

*         In the third paragraph, I'd say "use of standard interfaces" not just "use of interfaces". We only want to develop and use standard interfaces. We don't want to design a system that will be based on proprietary interfaces.

*         The first area of focus is "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." I suggest changing "assessing, aggregating and comparing device states against expected values" to "assessing and aggregating device states and comparing these device states against expected values". Otherwise it's not clear which verbs are modified by the adverbial phrase "against expected values".

*         I don't think that the third area of focus is needed to address UC1 and UC3. Therefore, we should take it out. That area is "3. Create relationships between existing operations management standards to enable a comprehensive view of security automation, leveraging existing work and implementations."

*         Let's narrow the reference model document to UC1 and UC3 and add requirements in that document for all the standards that we're going to need. That way, we can do all our architecture and requirements definition in one place. And we can delete the other Informational document in our list of deliverables.

*         Delete the parenthetical mentions of specific existing external specs from the deliverables (e.g. XCCDF, OVAL). We should not prejudge which standard the working group will choose for each purpose.

*         Don't call for multiple Standards Track documents on a single topic at this point. We should aim to have one standard for each purpose. I think this comment only applies to the device state checking languages. Asset identification and reporting are separate things, right? If so, they should be separate deliverables. And I don't know what this deliverable means: "Standards Track documents specifying interfaces and communication protocols used for security automation and continuous monitoring". If we know what it means, let's explain it more clearly. If we don't know what it means, it shouldn't be on the list. We can always add deliverables later if we need to. We should pare back our list to only things that we understand now and can describe.

*         I guess we're going to break our deliverables into two phases. Which deliverables should go in Phase 2? It's always hard to decide what can wait but I'd suggest these: "Standards Track document describing the messages and network protocols for distributing Security Automation Content", "Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems", and any of the other deliverables where we don't have a mature spec (stable with several implementations) with good IPR terms that can be published as an RFC or referenced with a normative reference. This will allow us to rapidly get an open standard solution, even if it can't do everything we want.

We should check whether pushing out all those deliverables will still let us meet a useful subset of UC1 and UC3. If not, we may need to pull some things in from Phase 2 but doing so will probably slow down the completion of Phase 1 considerably. We could also define a Phase 1.5 for any such items where lots of work is needed but we really need them. Then we could start work on those Phase 1.5 deliverables right away, knowing that they probably won't be ready until after the Phase 1 deliverables. And I hope that we'll make the reference model and protocols extensible so that people can try out draft specs in a prototype implementation or even make up their own solution for some problem and experiment with it without causing massive problems.

To answer Kent's question about how we can most easily track differences between versions of the charter, I suggest that whoever's editing the charter (Kent, it seems) provide a plain text file version of each version of the charter. Send that out as an attachment to your email and we can all use our own tools to do a diff.

Good charter discussion!

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, August 20, 2012 4:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Proposed use cases to move forward

As a point of reference, how does the list want to see differences from one version of the charter to the next?  Let's keep it simple if possible...

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

* Standards Track documents specifying device state checking languages (OVAL, ECL, ACEML, ...)

Goals and Milestones

TBD

Thanks.

Kent Landfield

Adam

Steve,

Sincerely,
Dave

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 3:55 PM
To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Proposed use cases to move forward

Thanks,

Steve

-----Original Message-----
Of

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 23 Aug 2012 16:37:08 -0400

Dave,

Sorry to be late in responding to your email. I agree that
we must avoid having our work stray from its place in the
larger picture of security automation. In order to do that
effectively, it would be very useful (one might say essential!)
to have a document that provides that larger picture. If you
want to work on an individual submission to do so, I'd be
glad to work on it with you. Probably several other people
would also. And we can send it to MILE and SACM and other
lists for review.

In IETF, the feedback loop across WGs is usually provided
by having the same people participating in multiple WGs.
The IESG, IAB, and directorates can also provide some
coordination but mostly we count on the individual
participants to do it. 

Thanks,

Steve

> From: Waltermire, David A. [mailto:[email-masked]]
> Sent: Friday, August 17, 2012 12:30 PM
> this kind of risk.  I guess this type of issue is something that we
> will need to collectively monitor and address as needed.
> 
> Sincerely,
> Dave
> 
> 
> I love broad scope. Don't get me wrong! But I'm concerned about having
> a use cases document and an architecture document for this working
> group that goes way beyond the charter and initial scope for the group.
> 
> I'm concerned that this will lead to lots of discussions on the sacm
> list and lots of effort being spent on topics that are out of scope,
> diverting us from the tasks at hand and slowing our progress.
> 
> I'm concerned that by including all of security automation within our
> use cases and architecture, we may actually prevent the formation of
> other working groups that could work on those other use cases.
> 
> understanding how the NEA and MILE and SACM standards fit together and
> I would love to address that in an IETF RFC. But I have seen several
> grand architecture efforts die or come to nothing in IETF. IETF is
> filled with smart engineers with clever ideas. We're great at solving
> problems but if we can't agree on the problem to solve or if we choose
> the wrong problem, we can easily spin an intricate and pointless web.
> 
> Maybe a few people can create an individual submission describing a
> grand architecture and roadmap for security automation and ask people
> in SACM to review and provide feedback on that document. That would be
> a good way to get a grand architecture while still ensuring that the
> SACM effort keeps its focus. In IETF as in so many things, you must
> keep your focus or you'll never succeed.
> 
> Thanks,
> 
> Steve
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 23 Aug 2012 16:45:24 -0400

Hello,

I am a little behind in my email, so hopefully my response has all of the relevant context.  I do agree with Steve that if we can focus the effort to the scope of a working group with the larger scope defined separately (individual draft is a great idea), then we should get closer to WG formation and driving progress in the WG.

Best regards,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Thursday, August 23, 2012 4:37 PM
To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Cc: [email-masked]
Subject: Re: [sacm] Proposed use cases to move forward

Dave,

Thanks,

Steve

---

From: Adam Montville <[email-masked]>
Date: Fri, 24 Aug 2012 13:47:47 +0000

>would also. And we can send it to MILE and SACM and other

I'm feeling that we're talking about two different levels of document -
one is the use case document, which I think needs to be "broad" in the
sense that we keep the five use cases represented, but only address UC1
and UC3; the second is a more abstract, context setting informational
document.  Are we talking about two things or am I missing something?

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 24 Aug 2012 10:44:55 -0400

Adam,

I think the core issue here is scope. Successful IETF Working Groups
must have a charter that clearly articulates a fairly narrow scope
with a limited set of deliverables that will provide significant value
when completed. Then they must stick to that scope.

Without a clear and narrow scope, WGs wander around and never complete.
WG chairs can't shut down irrelevant discussions on the email list.
People bring in interesting and perhaps worthwhile ideas that distract
the group from their goal. Eventually, people get frustrated and leave.
The only people who are left are impractical and create a monument to
their huge intelligence that nobody implements.

You didn't say that you disagree about scope, though. In fact, I think
that you have previously said that you agree that we should have a
narrow scope. So I'll assume that we agree on that topic.

Why would we want to have use cases in the key architecture document
for SACM that are not in scope for the WG? That will just encourage
the WG to spend time talking about those use cases. In fact, we'd
be obligated to spend time talking about them if they're in our
key architecture document, the main document guiding our WG's work.
We couldn't approve something with use cases that we haven't reached
consensus on.

Maybe you're arguing that UC2, UC4, and UC5 should also be in scope
for this WG. I thought we had already settled that matter but if
you want to reopen it, please speak up and explain why.

Thanks,

Steve

> Sent: Friday, August 24, 2012 9:48 AM
> To: Stephen Hanna; Waltermire, David A.; Luis Nunez; Omar Santos
> Cc: [email-masked]
> having
> solving
> that a

---

From: Adam Montville <[email-masked]>
Date: Fri, 24 Aug 2012 15:36:37 +0000

I agree on WG scope. Just distinguishing between doc scope. UC1 and UC3 for WG scope.  Seems that 2, 4, and 5 should be pulled up into a more informational doc.

So we can renumber 3 to 2, and describe the others elsewhere.

Make sense?

Sent from my iPhone

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 24 Aug 2012 12:20:33 -0400

I agree completely as long as the document that contains 2, 4, and 5
is not a WG document for this WG. Maybe we can put use cases into
the broader architecture document that Dave and I are going to write
(the independent submission). We could even start a non-WG email list
to talk about that document and/or others that span multiple WGs. We
should find ways to continue the broader discussion but not in this WG.

Does that make sense?

Thanks,

Steve

> Sent: Friday, August 24, 2012 11:37 AM
> To: Stephen Hanna
> Cc: Adam Montville; Waltermire, David A.; Luis Nunez; Omar Santos;
> [email-masked]
> I agree on WG scope. Just distinguishing between doc scope. UC1 and UC3
> for WG scope.  Seems that 2, 4, and 5 should be pulled up into a more
> informational doc.
> 
> >>>> in SACM to review and provide feedback on that document. That
> would
> >> be

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 24 Aug 2012 09:42:11 -0700

Yes.

Sent from my iPhone

---

From: Adam Montville <[email-masked]>
Date: Fri, 24 Aug 2012 16:56:01 +0000

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 23, 2012 12:10 PM
To: kent_landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward)

·         Now that we have narrowed our focus to UC1 and UC3, we should continue to narrow the charter to match that focus. One way to do this would be to change the proposed WG name from “Security Automation and Continuous Monitoring” to “Security Compliance Automation” OR “Security Automation for Compliance”. The topic of security automation is a really broad one, including many MILE projects and other things that go way beyond UC1 and UC3.

I'm not opposed to changing the name, but I don't want to loose continuous monitoring.  I agree that we are compliance focused, but there is an aspect of continuous monitoring that needs to be addressed and which may not be implied by "security automation."

Of the two names suggested, I prefer the latter.

·         In the first paragraph of the WG Description, I’d like to suggest a few changes to this sentence: “These standards will support security practitioners to be better utilized within their organizations by allowing them to meet the more advanced needs of the security community (e.g. information sharing, continuous monitoring, remediation and response, result aggregation and analysis).” Right now, the text seems to imply that our focus will be on defining standards to “meet the more advanced needs of the security community”, including information sharing, continuous monitoring, remediation and response, and result aggregation and analysis. I don’t quite agree. I think that our goal now is to automate routine tasks related to gathering and managing information about endpoint security so that information security practitioners can focus on more advanced needs. Our scope may include some aspects of information sharing, continuous monitoring, remediation and response, and result aggregation and analysis but not the complete and total extent of any of those broad topics. So I suggest this replacement sentence: “These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to endpoint security so that practitioners can focus on more advanced work.”

Essentially, remove the word "support" from the first sentence and shorten it up a bit.  I agree.

·         We should delete “and SOHO” from this sentence: “The initial focus of this work is to address enterprise and SOHO use cases.” We need to maintain our focus and avoid the added complexities of SOHO. Anyway, that’s my view.

Agree.  This was discussed on the list previously, and I had the sense that we wanted to remove it, but retain it as an option in the future.

·         I think the last sentence in the first paragraph (about consuming and continuing work) belongs at the start of the second paragraph. The second paragraph is about how we’re going to use and enhance standards developed elsewhere. The first paragraph explains why our work is needed.

·         In the third paragraph, I’d say “use of standard interfaces” not just “use of interfaces”. We only want to develop and use standard interfaces. We don’t want to design a system that will be based on proprietary interfaces.

Agree.

·         The first area of focus is “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.” I suggest changing “assessing, aggregating and comparing device states against expected values” to “assessing and aggregating device states and comparing these device states against expected values”. Otherwise it’s not clear which verbs are modified by the adverbial phrase “against expected values”.

Good catch.

·         I don’t think that the third area of focus is needed to address UC1 and UC3. Therefore, we should take it out. That area is “3. Create relationships between existing operations management standards to enable a comprehensive view of security automation, leveraging existing work and implementations.”

This depends on whether "security automation" implies "continuous monitoring."  Referencing your proposed name change above, if we call the WG "Security Compliance Automation," would that imply continuous monitoring?  If the suggestion is that it would not, then where and when do we work on continuous monitoring?

·         Let’s narrow the reference model document to UC1 and UC3 and add requirements in that document for all the standards that we’re going to need. That way, we can do all our architecture and requirements definition in one place. And we can delete the other Informational document in our list of deliverables.

Agree.  The informational document would not be included in the WG, but could still be an independent submission.

·         Delete the parenthetical mentions of specific existing external specs from the deliverables (e.g. XCCDF, OVAL). We should not prejudge which standard the working group will choose for each purpose.

Agree.

·         Don’t call for multiple Standards Track documents on a single topic at this point. We should aim to have one standard for each purpose. I think this comment only applies to the device state checking languages. Asset identification and reporting are separate things, right? If so, they should be separate deliverables.

Agree.

And I don’t know what this deliverable means: “Standards Track documents specifying interfaces and communication protocols used for security automation and continuous monitoring”. If we know what it means, let’s explain it more clearly. If we don’t know what it means, it shouldn’t be on the list. We can always add deliverables later if we need to. We should pare back our list to only things that we understand now and can describe.

Here is another point raising the question of whether continuous monitoring should be included in the WG.  If my understanding of your previous comments is correct, continuous monitoring may be on the chopping block until we get the automated compliance work completed, and this set of "Standards Track documents specifying interfaces and communication protocols used for security automation and continuous monitoring" could reasonably be omitted.

·        I guess we’re going to break our deliverables into two phases. Which deliverables should go in Phase 2? It’s always hard to decide what can wait but I’d suggest these: “Standards Track document describing the messages and network protocols for distributing Security Automation Content”, “Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems”, and any of the other deliverables where we don’t have a mature spec (stable with several implementations) with good IPR terms that can be published as an RFC or referenced with a normative reference. This will allow us to rapidly get an open standard solution, even if it can’t do everything we want.

We should check whether pushing out all those deliverables will still let us meet a useful subset of UC1 and UC3. If not, we may need to pull some things in from Phase 2 but doing so will probably slow down the completion of Phase 1 considerably. We could also define a Phase 1.5 for any such items where lots of work is needed but we really need them. Then we could start work on those Phase 1.5 deliverables right away, knowing that they probably won’t be ready until after the Phase 1 deliverables. And I hope that we’ll make the reference model and protocols extensible so that people can try out draft specs in a prototype implementation or even make up their own solution for some problem and experiment with it without causing massive problems.

I'm always curious about defining "half phases."  Why not just call it three phases?

If I were to draw the line on two phases:

Phase 1: Cover foundations relevant to talking about assets and collecting data

  *   A Standards Track document specifying a device state checking language (NOTE CHANGE from multiple to single)
  *   A Standards Track document specifying an interrogative checking language
  *   A Standards Track document specifying platform naming, matching and applicability
  *   Standards Track documents specifying asset identification and reporting information
  *   NEW: Standards Track document specifying asset description format (non-identifying information)
  *   A Standards Track document specifying benchmark configuration representation

Phase 2: Cover the rest

  *   An Informational document stating guidelines / requirements for specifying checking languages
  *   IN QUESTION: Standards Track documents specifying standard 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  (content repository)
  *   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
  *   NEW: A Standards Track document specifying a control framework representation format

So, I guess I'm also suggesting a slight change in scope (after having thought about and worked on the use case document on mornings and evenings this week).  Something I didn't include here was targeting/tasking, but I think we should perhaps consider that – arguably, targeting/tasking could be included in the definition of standard interfaces and communications protocols, which is why I haven't included it here.

In phase one, I'm proposing the addition of a specification pertaining to holding asset information beyond identification attributes.

In phase two, I'm proposing the addition of a standard pertaining to describing and referencing control frameworks.

To answer Kent’s question about how we can most easily track differences between versions of the charter, I suggest that whoever’s editing the charter (Kent, it seems) provide a plain text file version of each version of the charter. Send that out as an attachment to your email and we can all use our own tools to do a diff.

Agree, but add the (implied) requirement that each version be consistently formatted.

Good charter discussion!

Thanks,

Steve

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, August 20, 2012 4:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Proposed use cases to move forward

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Goals and Milestones

TBD

Thanks.

Kent Landfield

Adam

Steve,

Sincerely,
Dave

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 3:55 PM
To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] Proposed use cases to move forward

Thanks,

Steve

-----Original Message-----
Of

---

From: Anton Chuvakin <[email-masked]>
Date: Fri, 24 Aug 2012 11:18:09 -0700

> I'm not opposed to changing the name, but I don't want to loose continuous monitoring.  I agree that we are compliance focused, but there is an aspect of continuous monitoring that needs to be addr…

Where is the word "assessment"?  Continuous monitoring really isn't
monitoring (well, not activity monitoring), but control assessment.

Please don't say "security automation" as we all know security cannot
be fully automated. Maybe "security assessment automation", "control
assessment automation", but not security automation.

-- 
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 24 Aug 2012 14:29:09 -0400

Adam,

I found it hard to distinguish your comments from mine in your email
so I'll mark your comments here with AM>, and respond inline. I'll
mark my previous comments with SH>. And I'll edit out a lot.

AM> I'm not opposed to changing the name, but I don't want to loose
AM> continuous monitoring.  I agree that we are compliance focused, but
AM> there is an aspect of continuous monitoring that needs to be addressed
AM> and which may not be implied by "security automation."

The term "continuous monitoring" seems to be causing confusion.
I've seen at least three meanings for it:

1) Everything that's in CAESARS-FE

2) Big Brother monitoring user behavior (web sites visited, etc.)

3) The ability to rapidly detect and handle changes in endpoint assessment

I suspect you intend meaning 3). Is that right? I'm going to
assume so for the rest of this email. But please clarify. And
I think you can see why using that term is problematic.

I agree that we don't want to lose the idea that changes in things
previously assessed are rapidly detected and handled. That's the
core of UC3.

I'm looking for a name that matches UC1 and UC3. I'm not entirely
happy with any of the names that I proposed but I think they match
our revised scope better than SACM. Other suggestions are welcome!

SH> *         I don't think that the third area of focus is needed to
SH> address UC1 and UC3. Therefore, we should take it out. That area is "3.
SH> Create relationships between existing operations management standards
SH> to enable a comprehensive view of security automation, leveraging
SH> existing work and implementations."

AM> This depends on whether "security automation" implies "continuous
AM> monitoring."  Referencing your proposed name change above, if we call
AM> the WG "Security Compliance Automation," would that imply continuous
AM> monitoring?  If the suggestion is that it would not, then where and
AM> when do we work on continuous monitoring?

I don't think that "security automation" is any better defined
than "continuous monitoring". Ignore the WG name for a moment
and let's stop using those poorly defined terms for now.

Let's use UC1 and UC3 as our guide for what's in scope for this
WG. UC3 definitely includes the ability to rapidly detect and
handle changes in assessed endpoint state. But I still don't think
the third area of focus is needed. Can you explain why area 1 and
area 2 are not enough? Remember that area 2 includes "a set of
standards that can be used to continuously monitor and report
on the state of systems". I think that covers UC3.

AM> Phase 1: Cover foundations relevant to talking about assets and
AM> collecting data
AM> 
AM> 
AM>   *   A Standards Track document specifying a device state checking
AM> language (NOTE CHANGE from multiple to single)
AM>   *   A Standards Track document specifying an interrogative checking
AM> language
AM>   *   A Standards Track document specifying platform naming, matching
AM> and applicability
AM>   *   Standards Track documents specifying asset identification and
AM> reporting information
AM>   *   NEW: Standards Track document specifying asset description format
AM> (non-identifying information)
AM>   *   A Standards Track document specifying benchmark configuration
AM> representation
AM> 
AM> 
AM> Phase 2: Cover the rest
AM> 
AM> 
AM>   *   An Informational document stating guidelines / requirements for
AM> specifying checking languages
AM>   *   IN QUESTION: Standards Track documents specifying standard
AM> interfaces and communication protocols used for security automation and
AM> continuous monitoring
AM>   *   A Standards Track document describing the messages and network
AM> protocols for distributing Security Automation Content  (content
AM> repository)
AM>   *   Standards Track document describing integrating security
AM> automation and Network Endpoint Assessment capabilities
AM>   *   A Standards Track document describing protocols and data formats
AM> for securely sharing dynamic network state information among security
AM> systems
AM>   *   NEW: A Standards Track document specifying a control framework
AM> representation format

Your Phase 1 only includes data formats. How can we satisfy
any part of UC1 or UC3 without some protocols? I think we
at least need this deliverable in Phase 1:

AM>   *   Standards Track document describing integrating security
AM> automation and Network Endpoint Assessment capabilities

Thanks,

Steve

---

From: Adam Montville <[email-masked]>
Date: Fri, 24 Aug 2012 19:10:21 +0000

>mark my previous comments with SH>. And I'll edit out a lot.

Thanks, and sorry about that.  This thread enjoys plain text; internal
people enjoy HTML; Outlook for the Mac doesn't handle the mix gracefully.

>I think you can see why using that term is problematic.

Yes, yes, and yes I can see.  Suggest we take Anton's suggestion and
consider a different word from "monitoring," such as "assessment."  It's
concise.

>our revised scope better than SACM. Other suggestions are welcome!

I'm at a loss for names, except for this one.

Acceptable State/Security Enforcement and Setting Support = ASSESS

>AM> automation and Network Endpoint Assessment capabilities

Agreed.  Good catch - working too quickly in the face of deadlines and a
week-long vacation.

We would change the term "security automation" to whatever we consider
more appropriate, and potentially split these into two documents.  Would
it make sense for one document to describe the integration with NEA
capabilities and the other to describe the coordination of the data
formats for the actual assessment?

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 24 Aug 2012 15:33:03 -0400

Adam,

Quick response and very thorough, considering you're going
away on vacation soon!

Now that we're back in plain text, things should work better.
I have simplified the Subject line since we're clearly talking
about the charter.

Adam Montville wrote:
> Steve Hanna wrote:
> Suggest we take Anton's suggestion and consider a different word
> from "monitoring," such as "assessment." It's concise.

Good idea! We used "assessment" in the NEA working group so
it also remains consistent with previous IETF terminology.

So we can talk about assessment. And when we want to specifically
mention the ability to rapidly detect and handle changes in
assessment, we can talk about "continuous assessment". But
"assessment" should do the trick, for the most part.

I love your suggested WG name: Acceptable State/Security Enforcement
and Setting Support = ASSESS! It's a cute acronym in the tradition of
mile and kitten and lemonade. I don't think the words will cause any
trouble or confusion. We'll see. I'm sure we'll hear from other people
with concerns and other ideas.

I didn't see any comments from you about why the third area of focus
is needed in the charter. Unless I hear otherwise, I'll assume that
you're OK with deleting it.

I'm glad that you agreed with adding this deliverable to Phase 1:

> automation and Network Endpoint Assessment capabilities

I agree that we should change the term "security automation" there
to something more appropriate. How about this text instead?

*   Standards Track document describing how to use the languages
and other content defined in this group with the NEA protocols

I don't think we need to split this document into two. TCG has
been working on one document that covers all of that handily.
If this deliverable gets adopted, I expect that TCG will donate
the document to IETF so that it can become an RFC. That's what
we did for several of the TNC protocols that became NEA RFCs.

Thanks,

Steve

> Sent: Friday, August 24, 2012 3:10 PM
> To: Stephen Hanna
> Cc: [email-masked]
> Subject: Re: [sacm] Proposed SACM Charter (was re: Proposed use cases
> to move forward)
> 
> >SH> address UC1 and UC3. Therefore, we should take it out. That area
> is
> >"3.
> >AM> interfaces and communication protocols used for security
> automation
> >and