Subject: [sacm] Charter Revised to Focus on UC1

From: Stephen Hanna <[email-masked]>
Date: Wed, 16 Jan 2013 23:10:52 +0000

As agreed, I have edited the draft SACM charter to
remove discussion of enforcement, event management,
and continuous assessment. The revised charter is
below and also attached. I have also attached a
copy of the previous charter for easy comparison.
If anyone has concerns with these edits, please
speak up.

Thanks,

Steve

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

Proposed Working Group Charter

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

Chairs:
TBD
TBD

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

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

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

Description of Working Group

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

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

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

The data exchange protocols will need to meet several exchange types
including those between and within organizations for sharing
intelligence data to increase situational awareness, report exchanges
both internal and external to an enterprise, and those between
enterprise servers and end points for assessments.

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

1. Define, either by normative reference, adoption, or creation, a set
of standards to enable the exchange of data to increase situational
awareness or gain access to shared content to improve the security
posture of an enterprise.  This area of focus provides for the
integration of interoperable protocols to access shared data
repositories between organizations to increase situational awareness
and reduce risks to an enterprise.  In support of accessing shared
intelligence for expected system state and related risks, define,
either by normative reference, adoption, or creation, a set of
standards that can be used for the purpose of assessing and
aggregating device states and comparing these device states against
expected values, and reporting on those results in a predefined or ad
hoc manner.  This area of focus provides for necessary language and
data format specifications.

2. Define, either by normative reference, adoption, or creation, a set
of standards that can be used to assess 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.  This area of focus provides for integration protocols
supporting plug and play system assessment within an enterprise.

This working group will achieve the following milestones:

- A Standards Track document to define a protocol for interacting
  with content repositories
- Standards Track documents specifying communication protocols and
  data formats used for security assessment of systems
- A Standards Track document specifying asset description format
- A Standards Track document specifying asset identification
[- A Standards Track document specifying platform naming
- A Standards Track document specifying platform matching
- A Standards Track document specifying platform applicability]

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

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 16 Jan 2013 18:46:44 -0500

Steve, at first glance this looks good, thanks.

Let me see if I can restate this version in terms of abilities this will 
give rise to.  I'm not going to try to be exhaustive here, just want to 
restate this from a different perspective to see if my understanding is 
on the right track.

So, with these deliverables, we will then have the ability to:

  + Codify a desired state, such as a security policy, into a benchmark 
(where a benchmark is comprised of one or more related documents) where 
the format of the benchmark is standardized and therefore can be both 
validated as following the standard and read by software that correctly 
implements that standard.

  + Communicate with a repository to get the current content to the 
point of collection/assessment.  Scope and granularity to be determined.*

  + Follow the instructions in the benchmark, or possibly external to 
the benchmark, to determine which assets the benchmark applies to 
(and/or, for a given asset, determine all available benchmarks that 
apply to it)

  + Follow the instructions in the benchmark to collect the proper data 
items for the asset**.

  + Follow the instructions in the benchmark to apply the correct logic 
steps associated to determine the state of the asset setting based on 
the collected data.

  + Communicate associated data in a standardized format -- outcome of 
evaluation and possibly intermediary data such as collected asset data.

* That is, will the repository be expected to be able to deliver, for 
example, content at the individual check level along with dependencies 
needed to perform that check based on query criteria (asset information, 
date of last update, pertinent regulation(s), etc).

** Collection may be directly from the asset, but may also be from an 
another source, such as a CMDB.

On 1/16/2013 6:10 PM, Stephen Hanna wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 16 Jan 2013 23:59:51 +0000

Gunnar,

I agree with everything that you wrote and I believe that it's
all consistent with the charter but I don't think we want the
charter to describe all of these things. That's better left to
the Architecture document. But I'm glad to have you confirm
that your view fits into this charter.

That reminds me. We should have deliverables for an Architecture
document and a Use Cases and Requirements document. Right?

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gunnar Engelbach
> Sent: Wednesday, January 16, 2013 6:47 PM
> Cc: [email-masked]
> Subject: Re: [sacm] Charter Revised to Focus on UC1
> 
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 16 Jan 2013 19:19:49 -0500

I would expect some abstraction of these points (protocol and data formats) to be included as deliverables.  Good point on the use case and requirements docs.

Sincerely,
Dave

----- Original Message -----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Wednesday, January 16, 2013 06:59 PM
To: Gunnar Engelbach <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [sacm] Charter Revised to Focus on UC1

Gunnar,

Thanks,

Steve

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 16 Jan 2013 19:21:57 -0500

On 1/16/2013 6:59 PM, Stephen Hanna wrote:
> charter to describe all of these things.

No problem, 'cuz that wasn't my intention.  Just trying to restate some 
of the implications of the charter to check that we're all communicatin' 
here.

That's better left to

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Jan 2013 01:01:48 +0000

Great! I'm glad that you did so. It's easy to get lost
in abstractions.

Thanks,

Steve

> Sent: Wednesday, January 16, 2013 7:22 PM
> To: [email-masked]
> >>>        To Subscribe:
> http://www.ietf.org/mailman/listinfo/sacm

---

From: Gary Gapinski <[email-masked]>
Date: Wed, 16 Jan 2013 20:53:27 -0500

> another source, such as a CMDB.

Nicely stated.

Yes.

A point of past and future attention is a benchmark - an arbitrary
collection of individual policies. Past practice is to attempt to ride
herd on versions thereof as well as versions of its constituents. I
think individual policies are simpler; compilations thereof not so
simple, thus the attention to repositories.

#6 above implies accord on #1, and a means by which to identify
individual policies for compilation based on pertinence.

#4 and #5 imply #4 must be a separate "collection" effort; I think #5
might usually suffice (answers without supporting evidence).

Regardless, you have itemized the essentials.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 16 Jan 2013 20:59:06 -0500

I'll just comment on your last question right now and go through the updates a little more closely tomorrow, thank you very much for taking it on!

Dave & Adam responded on lust earlier this week on that.  The requirements as summarized will be added to the use case document and Dave will work on getting an architecture document out.

Thanks,
Kathleen

Sent from my iPhone

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 16 Jan 2013 23:12:17 -0500

I use the term "benchmark" merely for the sake of convenience.  To be 
more precise about my conception of it, a benchmark is one or more 
documents related by some criteria.  For a HIPAA security evaluation, as 
one example, it could be document(s) that express the parts of HIPAA 
that have been automated, questionnaires for the parts that can't be 
automated, the HIPAA regulation itself, etc., or any meaningful subset.

It could also be a dynamic document(s), such as the result of querying 
for all automated vulnerability checks for Server 2008 R2 since August, 
2010 that have a CVSS score >= 5.4.

That a bit much specificity at this point in the process, but I think 
there's also some baggage that comes with the term "benchmark," so I 
wanted to be clear on my meaning.

Or to be more didactic:

Content:  A collection of electronically stored and transmittable 
artifacts contained in a repository.

Benchmark:  One or more content items related by a common criteria or 
purpose.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Jan 2013 08:33:22 +0000

Hi Steve, 

Thanks for drafting this and thanks for everybody for the good discussions until now. As the latest round of discussions prompted out, we need to add to the list of deliverables (actually start the list of requirements with) the two documents - use cases and requirements, and respectively architecture. No need to put dates by now, but placing them in front of the list will indicate that this team understands the natural order of horses and carriage. 

Regards,

Dan

> Stephen Hanna
> Sent: Thursday, January 17, 2013 1:11 AM
> To: [email-masked]
> Subject: [sacm] Charter Revised to Focus on UC1
> 
> As agreed, I have edited the draft SACM charter to remove discussion of
> enforcement, event management, and continuous assessment. The revised
> charter is below and also attached. I have also attached a copy of the
> previous charter for easy comparison.
> If anyone has concerns with these edits, please speak up.
> 
> Thanks,
> 
> Steve
> 
> --------------
> 
> 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
> support of information security processes and practices where practical.
> These standards will help security practitioners to be better utilized
> within their organizations by automating routine tasks related to
> endpoint and server security so that practitioners can focus on more
> advanced tasks. The initial focus of this work is to address enterprise
> use cases.
> 
> 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.
> 
> repositories, and enabling interoperability through the development and
> use of standard interfaces and communications protocols. Content based
> on rich data standards and protocols will provide the authoritative
> instructions needed by data-driven tools to enable the automated
> collection and exchange of configuration and vulnerability data
> pertaining to enterprise assets. Information produced by these tools
> will provide accurate and timely situational awareness in support of
> organizational decision making.
> 
> repositories between organizations to increase situational awareness and
> reduce risks to an enterprise.  In support of accessing shared
> intelligence for expected system state and related risks, define, either
> by normative reference, adoption, or creation, a set of standards that
> can be used for the purpose of assessing and aggregating device states
> and comparing these device states against expected values, and reporting
> on those results in a predefined or ad hoc manner.  This area of focus
> provides for necessary language and data format specifications.
> 
> personnel, to ensure security process effectiveness in a pre-defined or
> ad-hoc manner.  This area of focus provides for integration protocols
> After this work is completed, complementary deliverables may be defined.

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Jan 2013 17:26:40 +0000

>   data formats used for security assessment of systems

Isn't that exactly what you just requested? An abstraction
of protocols and data formats for system security assessment?

Thanks,

Steve

> From: Waltermire, David A. [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2013 7:20 PM
> To: Stephen Hanna; [email-masked]'
> Cc: [email-masked]'
> I would expect some abstraction of these points (protocol and data
> formats) to be included as deliverables.  Good point on the use case
> and requirements docs.
> 
> Sincerely,
> Dave
>

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Jan 2013 17:31:52 +0000

Great! I'm seeing rough consensus to add those two documents
to the deliverables and also to make the changes that
I suggested in my email yesterday on "Tighter Focus":

* Making our areas of focus just be system security assessment
  and interacting with content repositories

* Removing the exchange of information across organizational
  boundaries from our charter

I will make these changes to the charter, send out a new draft,
and then see what other simplifications I can come up with.
Suggestions from others on simplifications and clarifications
in the charter would be quite welcome.

Thanks,

Steve

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Thursday, January 17, 2013 3:33 AM
> To: Stephen Hanna; [email-masked]
> Subject: RE: Charter Revised to Focus on UC1
> 
> Hi Steve,
> 
> Thanks for drafting this and thanks for everybody for the good
> discussions until now. As the latest round of discussions prompted out,
> we need to add to the list of deliverables (actually start the list of
> requirements with) the two documents - use cases and requirements, and
> respectively architecture. No need to put dates by now, but placing
> them in front of the list will indicate that this team understands the
> natural order of horses and carriage.
> 
> Regards,
> 
> Dan
> 
> 
> 
> all
> practical.
> this
> and
> and
> either
> or

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 Jan 2013 12:36:52 -0500

The second deliverable is the architecture document.  I was referring to the lower-level work items, separate drafts that describe each of the protocols, data formats, or profiles of existing work used to achieve the SACM goals.

Thanks,
Dave

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Thursday, January 17, 2013 12:27 PM
To: Waltermire, David A.; [email-masked]'
Cc: [email-masked]'
Subject: RE: [sacm] Charter Revised to Focus on UC1

>   data formats used for security assessment of systems

Isn't that exactly what you just requested? An abstraction of protocols and data formats for system security assessment?

Thanks,

Steve

> I agree with everything that you wrote and I believe that it's all 
> consistent with the charter but I don't think we want the charter to 
> describe all of these things. That's better left to the Architecture 
> document. But I'm glad to have you confirm that your view fits into 
> this charter.
> 
> > Let me see if I can restate this version in terms of abilities this 
> > will give rise to.  I'm not going to try to be exhaustive here, just 
> > want
> to
> > the format of the benchmark is standardized and therefore can be 
> > both validated as following the standard and read by software that
> correctly
> >   + Follow the instructions in the benchmark, or possibly external 
> > to the benchmark, to determine which assets the benchmark applies to 
> > steps associated to determine the state of the asset setting based 
> > on the collected data.
> >
> > * That is, will the repository be expected to be able to deliver, 
> > for example, content at the individual check level along with
> dependencies
> > needed to perform that check based on query criteria (asset 
> > information, date of last update, pertinent regulation(s), etc).
> >
> > ** Collection may be directly from the asset, but may also be from 
> > an another source, such as a CMDB.
> >
> >
> > > As agreed, I have edited the draft SACM charter to remove 
> > > discussion of enforcement, event management, and continuous 
> > > assessment. The revised charter is below and also attached. I have 
> > > also attached a copy of the previous charter for easy comparison.
> > > that information has become a challenging task for organizations 
> > > of all sizes, and we find that security practitioners spend most 
> > > of
> > their
> > > for expansion on the international stage. Of particular interest 
> > > to this working group are the security automation specifications 
> > > repositories, and enabling interoperability through the 
> > > development and use of standard interfaces and communications protocols.
> Content
> > > data pertaining to enterprise assets. Information produced by 
> > > these tools will provide accurate and timely situational awareness 
> > > in support of organizational decision making.
> > >
> > > of standards to enable the exchange of data to increase 
> > > situational awareness or gain access to shared content to improve 
> > > the security posture of an enterprise.  This area of focus 
> > > provides for the integration of interoperable protocols to access 
> > > shared data repositories between organizations to increase 
> > > situational
> awareness
> > > aggregating device states and comparing these device states 
> > > against expected values, and reporting on those results in a 
> > > predefined or
> ad
> > > hoc manner.  This area of focus provides for necessary language 
> > > and data format specifications.
> > >

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Jan 2013 17:44:50 +0000

Yes, I would like to replace that deliverable with several more specific
deliverables enumerating all the separate drafts that we're going to write
or refer to. The current deliverable is too abstract.

However, I don't think that we yet have consensus on what those specific
deliverables will be. Maybe when we get the architecture document drafted
this will become clear. I hope so. For now, I think that an abstract
deliverable is all we can agree on.

Thanks,

Steve

> Waltermire, David A.
> Sent: Thursday, January 17, 2013 12:37 PM
> The second deliverable is the architecture document.  I was referring
> to the lower-level work items, separate drafts that describe each of
> the protocols, data formats, or profiles of existing work used to
> achieve the SACM goals.
> 
> Thanks,
> Dave
> 
> Isn't that exactly what you just requested? An abstraction of protocols
> and data formats for system security assessment?
> 
> Thanks,
> 
> Steve
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Gunnar Engelbach
> > > restate this from a different perspective to see if my
> understanding
> > is
> > > on the right track.
> > >
> > >
> > > > 1. Define, either by normative reference, adoption, or creation,
> a
> > > set
> > > > 2. Define, either by normative reference, adoption, or creation,
> a
> > > set

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 17 Jan 2013 13:11:53 -0500

>    boundaries from our charter

I'm pretty sure I agree with this as well, but judging from some of the 
comments Gary Gapinski made I think there might be some divergence on 
interpretation of this.

I'm taking it to mean that this would be a communications protocol/data 
format for communicating an extraction of the assessment results to some 
interested party -- basically, the same role that ARF is intended to 
provide.

If that's what is meant then I completely agree, it's not something that 
needs to be part of the initial charter, with the caveat that there 
*does* need to be a way to communicate full results inside the 
organization as part of the initial charter.  The second milestone would 
seem to cover that.

---

From: Gary Gapinski <[email-masked]>
Date: Thu, 17 Jan 2013 13:48:14 -0500

> comments Gary Gapinski made I think there might be some divergence on 

No. I'm OK with the above.
> interested party -- basically, the same role that ARF is intended to 

While that is a salient use case, I suspect there are some who had
additionally expected a repository to contain assessment criteria.
Perhaps I am interpreting the scope of your statement too narrowly.

Is "a communications protocol/data format for communicating an
extraction of the assessment results to some interested party" also the
same as the one to communicate results from a target of evaluation to a
repository? I would expect that it would be.

That is a question for later, and need not be answered in the current
context of establishing the charter scope, if at all, as the charter
already includes this and more in paragraph three.