Subject: [sacm] combining use case 2.5 & 2.10

From: Chris Inacio <[email-masked]>
Date: Wed, 6 Nov 2013 14:55:58 +0000

I read through 2.5 & 2.10 pretty carefully and everything, save one feature, is more than adequately covered in 2.5.  So my basic statement is, just eliminate 2.10.

The point that 2.10 contains that isn't in 2.5 is somewhat contentious though.  2.10 makes the point of capturing "e.g. command and control traffic".  I'm personally on the side of adding passive inventory collection information from the network into the posture system - but I don't know if the group has achieved any type of consensus on this.

The only other detail that 2.10 calls out is to specifically mention file hashes.  I can capture that quite easily.  I would like to tighten the "voices" to a singular voice in the document.  Or at least have it not seem like 8 people just wrote a paragraph and we dropped it together.  I know that Aaron rewrote his piece, and I generally liked his thoughts on building blocks + scenario in a single section with subsections.

I can tweak 2.5 pretty quickly, but I want to structure it like everyone else.  Can we get some of those on the list and I can make the formatting / structure fall in line?

Chris

---

From: Lisa Lorenzin <[email-masked]>
Date: Wed, 6 Nov 2013 23:34:41 +0000

Hi Chris et al.,

Per my comments on Monday, I'd like to do something similar for 2.8 - 
break it into two use cases, to highlight what I think are the key 
functional points (periodic assessment and asynchronous requests / 
updates - David, please correct me if I'm still not interpreting it
correctly!), and revise format for consistency of voice with the other 
instances.  So I'm also interested in seeing the updated content on 
the list...

(I wish I could have participated last night, but I had a prior
commitment - I do hope to join the session tonight!)

					Regards,

						Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Inacio
Sent: Wednesday, November 06, 2013 7:56 AM
To: [email-masked]
Subject: [sacm] combining use case 2.5 & 2.10

Chris

---

From: "Aaron Woland (aawoland)" <[email-masked]>
Date: Wed, 6 Nov 2013 23:44:04 +0000

All,

Working with Steve Hanna, Kent, Nancy, Chris & Dave W last night, we came
up with 3 major Use-Cases & their building blocks that encompassed ALL the
existing use-cases; and moved those Use-Cases to ³Usage Secenarios² that
Steve Hanna was going to work on last night/today.

Here is what we came up with; that we will be reviewing this evening.
Keep in mind, NO text was deleted from the draft, simply moved to ³usage
scenarios² instead of Use-Cases.  We all would love some feedback, if you
think it¹s a good idea/bad idea, etc.

The formatting would (of course) be better than this, and we will be
sharing this out via WebEx this evening.

----- Begin Snippet from Draft ----

2.1 SACM Use-Cases
 
2.1.1 Define, Publish and Retrieve Content
This use case describes the need for content to be
created, published and retrieved for the explicit use of posture
evaluation.
 
The building blocks for defining, publishing and
retrieving content are as follows:
·      
Defining the ³content² to drive Collection & Evaluation
·      
Having a mechanism to publish that ³Content² to a content repository
(repository could be public, enterprise, private, anything)
o   Example
of content:  listing of posture attributes
one would collect from an endpoint.  Or,
a SET of those posture attributes.
o   Another
Example:  Boolean logic that describes
how you would evaluate the value of the posture attributes in order to make
³some determination².
·      
Notification. 
An administrator should be able to register with repository for
immediate notification of new security vulnerability content that match a
selection filter.
·      
Query.  An
administrator should be able to query a content repository for an on-demand
report of content.
[NOTE:  Should be differentiate
between endpoint specific (attribute values) & endpoint independent content
(checklists)]
 
2.1.2  Verify
Endpoint Compliance
This use case describes the need to identify an endpoint
so that the applicable set of content may be selected for purposes of
evaluation by an application.  Applications
will determine the posture-result, which is a direct outcome of the
evaluation
process.
 
The Building Blocks of the Automated Checklist
Verification use-case are:
·      
Discovery. 
The purpose of discovery is to determine the type of endpoint to be
posture assessed. 
·      
Inventory. Need a mechanism to consume the
inventory (software or hardware).
·      
Query the Content. Based on inventory the
application will query different stores of content to find the ³applicable²
content for the endpoint in question.
o   The
content retrieved by the query will be the published content from use-case
2.1.
·      
Collection. 
The accumulation of values associated to the posture attributes
resulting out of the query.
o   As
part of collection, transport of attribute values must be stored in a
repository for evaluation and mining.
o   Transport
must take into consideration the constraints of low-bandwidth,
intermittent, or
high-latency links.
·      
Evaluation. 
The resulting attribute values of the Collection process are evaluated
against the ³content² to provide a set of posture results.
o   An
example evaluation could be comparing the collected attribute values
against a
list of known vulnerable software (³content²).
o   Another
example evaluation might be comparing the collected attribute values
against a
checklist of required patches for corporate policy compliance.
·      
Posture Result. 
The end product of the collection & evaluation process is the
posture result.
 
2.1.3  Mining the
Database
This use case describes the need for an application to be
able to interact with repositories in order to identify compliant as well
as
anomalous endpoints.
 
The building blocks for mining the database are as
follows:
·      
Query a repository for attributes.
o   One
example of querying a repository for attributes is to search for all
endpoints
that have a specific file or other attribute that matches a new
vulnerability. 
o   Another
example is to search for all endpoints that are missing a specific
attribute, such
as an installed application or file.
o   Prepare
a compliance report for all endpoints that match a specific class.
·      
Automated Notification.  An administrator should be able to register
with repository for immediate notification of new endpoints that match a
specific filter or query.
 
2.2  Usage Scenarios
[NOTE:  We want to reference the building block from
above within the scenario.  I.e.: this is
an example of Discovery block from 2.1.2]
 
2.2.1     A vendor manufactures a number of
specialized endpoint devices.  They also
develop and maintain an operating system for these devices that enables
end-user organizations to configure a number of security and operational
settings.  As part of their customer support
activities, they publish a number of secure configuration guides that
provide minimum
security guidelines for configuring their devices.

<<<<<REMAINDER REMOVED TO NOT SPAM YOU COMPLETELY>>>>

Aaron

-- 
Regards,

Aaron T. Woland, CCIE #20113
Secure Access TME, SAMPG ciscoSystems, Inc.
Check out my Secure Network Access Blog
<http://www.networkworld.com/community/blog/26151> at Network World
Author:  Cisco ISE for BYOD and Secure Unified Access
<http://click.linksynergy.com/fs-bin/click?id=176dglGj6oU&offerid=145238.10
000263&type=1&subid=0>

On 11/6/13, 6:34 PM, "Lisa Lorenzin" <[email-masked]> wrote:

>I read through 2.5 & 2.10 pretty carefully and everything, save one
>feature, is more than adequately covered in 2.5.  So my basic statement
>is, just eliminate 2.10.
>
> 
>
>The point that 2.10 contains that isn't in 2.5 is somewhat contentious
>though.  2.10 makes the point of capturing "e.g. command and control
>traffic".  I'm personally on the side of adding passive inventory
>collection information from the network into the posture system - but I
>don't know if the group has achieved any type of consensus on this.
>
> 
>
>The only other detail that 2.10 calls out is to specifically mention file
>hashes.  I can capture that quite easily.  I would like to tighten the
>"voices" to a singular voice in the document.  Or at least have it not
>seem like 8 people just wrote a paragraph and we dropped it together.  I
>know that Aaron rewrote his piece, and I generally liked his thoughts on
>building blocks + scenario in a single section with subsections.
>
> 
>
>I can tweak 2.5 pretty quickly, but I want to structure it like everyone
>else.  Can we get some of those on the list and I can make the formatting
>/ structure fall in line?
>
> 
>
>Chris
>
> 
>
>
>_______________________________________________
>sacm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sacm

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 7 Nov 2013 00:26:59 +0000

Thanks for the offer. Are you able to call in tonight?

Dave
________________________________________
From: [email-masked] <[email-masked]> on behalf of Lisa Lorenzin <[email-masked]>
Sent: Thursday, November 07, 2013 12:34:41 AM
To: [email-masked]
Subject: Re: [sacm] combining use case 2.5 & 2.10

Hi Chris et al.,

                                        Regards,

                                                Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Inacio
Sent: Wednesday, November 06, 2013 7:56 AM
To: [email-masked]
Subject: [sacm] combining use case 2.5 & 2.10

Chris

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 7 Nov 2013 00:37:27 +0000

I changed the subject line to better reflect the topic.

For those in Vancouver, I believe that this informal editing
group (design team in RFC 2418 parlance) will be meeting at
the IETF reg desk at 5:30 PM PST. We'll look for an empty
room and connect into the Webex from there with audio and
screen-sharing.

Of course, the outcome of the editing session will be
totally subject to approval, rejection or modification
by the WG as a whole.

Thanks,

Steve

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Waltermire, David A.
> Sent: Wednesday, November 06, 2013 7:27 PM
> To: Lisa Lorenzin; [email-masked]
> The only other detail that 2.10 calls out is to specifically mention
> file hashes.  I can capture that quite easily.  I would like to tighten
> the "voices" to a singular voice in the document.  Or at least have it
> not seem like 8 people just wrote a paragraph and we dropped it
> together.  I know that Aaron rewrote his piece, and I generally liked
> his thoughts on building blocks + scenario in a single section with
> subsections.
> 
> 
> 
> I can tweak 2.5 pretty quickly, but I want to structure it like
> everyone else.  Can we get some of those on the list and I can make the
> formatting / structure fall in line?
> 
> 
> 
> Chris
> 
> 
> 
>

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 7 Nov 2013 01:21:02 +0000

As Aaron noted below, I have been working on the usage scenarios,
mainly annotating each one with a list of Building Blocks used.
Here (attached) is the file that I have. Look at the end to
find the usage scenarios.

This work will need to be revisited as the Building Blocks change.
We can review this tonight if we have time after reviewing the
Building Blocks. I also hope this will stir up a healthy
discussion on the list!

Thanks,

Steve

> Aaron Woland (aawoland)
> Sent: Wednesday, November 06, 2013 6:44 PM
> <http://click.linksynergy.com/fs-
> bin/click?id=176dglGj6oU&offerid=145238.10
> 000263&type=1&subid=0>
> 
> 
> 
> 
> 
> 
> 
> 
> >Chris Inacio
> file
> everyone

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 6 Nov 2013 17:35:51 -0800

I had an opportunity to look at the first several building blocks and have offered some naming suggestions for what they might be worth.  I need to attend the ops plenary, so I'm not going to be able to make the meeting live.

On Nov 6, 2013, at 5:21 PM, Stephen Hanna <[email-masked]> wrote:

> <Use-Cases_v02.docx>

Adam

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 7 Nov 2013 01:42:00 +0000

FYI, we ended up in the Plaza A meeting room on the second floor.

Thanks,

Steve

> Stephen Hanna
> Sent: Wednesday, November 06, 2013 7:37 PM
> To: Waltermire, David A.; Lisa Lorenzin; [email-masked]
> Subject: [sacm] Editing Session Tonight
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 7 Nov 2013 01:50:19 +0000

Here is the 2.15 to 2.18 text:

Identification and Retrieval of Repository Content

In preparation for performing an assessment, an operator or autonomous system will need to identify one or more content repositories that contain the content entries necessary to perform data collection and evaluation tasks. The location of a given content entry will either be known a priori or known content repositories will need to be queried to determine the location of applicable content.

To query the location of appropriate content, a repository will need to be queried using a user selectable combination of publication metadata (e.g. publishing identity, create time, modification time) and content-specific criteria. Once the appropriate locations of content have been identified, one or more requests can be made to retrieve the content. A variation on this approach would be to maintain a local cache of previously retrieved content. In this case, only content that is determined to be stale by some measure will be identified for retrieval.

Once the locations of all necessary content have been identified, the content will be retrieved using one or more requests based on the operator’s authorized level of access.
Alternately, content can be discovered by iterating over content published with a given context within a content repository. Applicable content can be retrieved as needed.

Notification of Content Changes
An operator may need to identify new, updated, or deleted content in a content repository for which they have been authorized to access. This may be achieved by querying or iterating over content in a content repository, or through a notification mechanism that describes changes made to a content repository.

Once content changes have been determined, data collection and evaluation activities may be triggered.

________________________________________
From: [email-masked] <[email-masked]> on behalf of Adam W. Montville <[email-masked]>
Sent: Thursday, November 07, 2013 2:35 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [sacm] Usage Scenarios