Subject: [sacm] Latest copy of the Use-Cases & Scenarios

From: "Aaron Woland (aawoland)" <[email-masked]>
Date: Thu, 7 Nov 2013 03:47:49 +0000

This version has the changes/comments from Steve, Adam & the entire group who met in Plaza A.

Here is the meeting recording:

Your recording is now available on the WebEx service site. Click the link below to play it:

https://new-webex.webex.com/new-webex/lsr.php?AT=pb&SP=MC&rID=72851972&rKey=36024fbb1e68fac5

SACM-20131107 0142-1
Wednesday, November 6, 2013 8:42 pm New York Time
2 Hours 3 Minutes

* You can forward this message to others to allow them to play back the recording. *

--
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.10000263&type=1&subid=0>

---

From: "Watson, Kimberly" <[email-masked]>
Date: Thu, 7 Nov 2013 16:39:38 +0000

In reading the building blocks section, I had some thoughts...I have not had time to watch the recordings to see if you discussed these thoughts or not...

I propose that there are objects (e.g., hardware, software, accounts) that have attributes that we want to know or verify as part of security posture assessment...

So we need:

Object discovery - to know what items need to have posture assessed
Object inventory - to determine assessment needs, and (I think) associate both desired state and content with objects
Desired state definition - to define the desired state of attributes for assessment
Content creation/acquisition - to drive collection of required attributes from objects for assessment
Posture Attribute Collection - to collect the necessary attributes from objects for assessment
Posture Evaluation - to compare what was collected to the Desired state definition for the actual assessment result

If you do not call out a desired state specification, then you cannot separate evaluation from collection where desired. I have no issue allowing the definition to be in the content, but I believe it is unnecessary and potentially "bad" to require it to be in the content. (in this context, "bad" means that it might actually limit applicability to some of our scenarios in a manner that scales).

I think all the combination of usage scenarios in fact differentiate on different triggers for assessment associated with these building blocks

trigger assessment when new object is discovered,
periodically assess everything in inventory or define/apply new assessment to items in inventory,
reassess with new desired state or create new content for new desired state,
reassess/collect with new content,
collect when attribute changes, content changes, or periodically,
evaluate against new desired state or with new collected attributes

and do them under different/particular operational constraints
--
Kim Watson
Office of Cybersecurity and Communications
Federal Network Resilience
Blackberry: (202) 494-2534

From: Aaron Woland (aawoland) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 10:48 PM
To: [email-masked]
Subject: [sacm] Latest copy of the Use-Cases & Scenarios

SACM-20131107 0142-1

--
Regards,

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:42:17 +0000

I think setting the building blocks and then defining the usage scenarios is a good idea.

I agree with Steve in that 2.2.6 can be removed since it is very similar to 2.2.2 and 2.2.3 together. Same for 2.2.7, 2.2.8, 2.2.9, 2.2.10 and 2.2.12 being variations of 2.2.2. I think consolidating and avoiding redundant usecases will help the doc be shorter and readable.

Panos

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aaron Woland (aawoland)
Sent: Wednesday, November 06, 2013 10:48 PM
To: [email-masked]
Subject: [sacm] Latest copy of the Use-Cases & Scenarios

SACM-20131107 0142-1

--
Regards,

---

From: Adam Montville <[email-masked]>
Date: Thu, 7 Nov 2013 19:06:48 +0000

I think a lot of the good comments here and elsewhere on the work that is being done this week are predicated on stabilizing our terminology.

I think it might benefit us to think almost in taxonomic ways.  To use "content" as an example, we could represent the concept as follows:

Content
    |
    +-- Assessment Content
    |       +-- Collection Content
    |       +-- Evaluation Content
    +-- Reporting Content

Or something like that.  If we look at the domain like this, then we can (in 2.1.1 of the most recent Word document sent yesterday evening) be precise when we talk about "Content Definition" and choose to, if warranted, write that Assessment Content Definition is a building block for the "Define, Publish, Query, and Retrieve Content" use case instead of "Content Definition" or otherwise do something similar.

Aside: I was not able to join the WebEx for the duration of the meeting and even when I was joined I could pay attention only part of the time, so there may have been some discussion about what I am about to write.  Does it make sense to break out Define, Publish, Query, and Retrieve into separate use cases?

Other suggestions/comments:

* "Repository Content Query" --> "Repository Query".  This makes it clear that the repository is being queried and not the information represented by the content the repository holds.

* Does it make sense to reorder the words in some of our terms?  For example, instead of saying "Assessment Content Definition" should we make it more active by writing "Define Assessment Content"?

* In 2.1.3 it might make things clearer to be more precise about the repository we mean: "Query a repository..." to "Query an Assessment Results Repository" (or something similar).

* The title for 2.1.3 might assume less of a database if it read something like "Mining Available Assessment Information" or something like that.

Thoughts?

Adam

________________________________
From: [email-masked] [[email-masked]] on behalf of Watson, Kimberly [[email-masked]]
Sent: Thursday, November 07, 2013 10:39 AM
To: [email-masked]
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios

In reading the building blocks section, I had some thoughts…I have not had time to watch the recordings to see if you discussed these thoughts or not…

I propose that there are objects (e.g., hardware, software, accounts) that have attributes that we want to know or verify as part of security posture assessment…

So we need:

Object discovery – to know what items need to have posture assessed
Object inventory – to determine assessment needs, and (I think) associate both desired state and content with objects
Desired state definition – to define the desired state of attributes for assessment
Content creation/acquisition – to drive collection of required attributes from objects for assessment
Posture Attribute Collection – to collect the necessary attributes from objects for assessment
Posture Evaluation – to compare what was collected to the Desired state definition for the actual assessment result

If you do not call out a desired state specification, then you cannot separate evaluation from collection where desired. I have no issue allowing the definition to be in the content, but I believe it is unnecessary and potentially “bad” to require it to be in the content. (in this context, “bad” means that it might actually limit applicability to some of our scenarios in a manner that scales).

SACM-20131107 0142-1

--
Regards,

...

. . .

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 7 Nov 2013 19:17:30 +0000

Adam,

I like all your comments!

We struggled last night with the meaning of the word "content". In the end, we decided to just use that word to mean roughly "all the data items you need to collect and evaluate endpoint posture attributes, including the collected attribute values and maybe even results". I'm sure that we need to break this down further and come up with names for all the kinds of data items. Your taxonomy starts down that road. I'm not an expert in this area. Can you or someone else extend your taxonomy to a finer level of detail and make sure that it includes collected attribute values and posture results?

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, November 07, 2013 2:07 PM
To: Watson, Kimberly; [email-masked]
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios

Content
    |
    +-- Assessment Content
    |       +-- Collection Content
    |       +-- Evaluation Content
    +-- Reporting Content

Thoughts?

Adam

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]] on behalf of Watson, Kimberly [[email-masked]]
Sent: Thursday, November 07, 2013 10:39 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios
In reading the building blocks section, I had some thoughts...I have not had time to watch the recordings to see if you discussed these thoughts or not...

So we need:

From: Aaron Woland (aawoland) [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 10:48 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] Latest copy of the Use-Cases & Scenarios

SACM-20131107 0142-1

--
Regards,

...

. . .

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 07 Nov 2013 14:41:08 -0500

I would go even broader with that definition.

Content could be any document that can be stored in a repository and 
retrieved.

Automated content is content that can be interpreted by a software system.

But there is also ancillary content.  For example, the text of the 
regulation that the automated content is intended to satisfy. 
Educational materials related to the automated content, to include 
video.  Related remediation scripts.  And so on.

For the purposes of SACM we would be interested in the automated 
content, but it also makes sense for these standards to allow for they 
querying and retrieval of other related content.

On 11/7/2013 2:17 PM, Stephen Hanna wrote:
> We struggled last night with the meaning of the word “content”. In the
> end, we decided to just use that word to mean roughly “all the data
> items you need to collect and evaluate endpoint posture attributes,
> including the collected attribute values and maybe even results”. I’m
> sure that we need to break this down further and come up with names for
> all the kinds of data items. Your taxonomy starts down that road. I’m
> not an expert in this area. Can you or someone else extend your taxonomy
> to a finer level of detail and make sure that it includes collected
> attribute values and posture results?
>
> Thanks,
>
> Steve
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Adam Montville
> *Sent:* Thursday, November 07, 2013 2:07 PM
> *To:* Watson, Kimberly; [email-masked]
> *Subject:* Re: [sacm] Latest copy of the Use-Cases & Scenarios
>
> I think a lot of the good comments here and elsewhere on the work that
> is being done this week are predicated on stabilizing our terminology.
>
> I think it might benefit us to think almost in taxonomic ways.  To use
> "content" as an example, we could represent the concept as follows:
>
> Content
>
>      |
>
>      +-- Assessment Content
>
>      |       +-- Collection Content
>
>      |       +-- Evaluation Content
>
>      +-- Reporting Content
>
> Or something like that.  If we look at the domain like this, then we can
> (in 2.1.1 of the most recent Word document sent yesterday evening) be
> precise when we talk about "Content Definition" and choose to, if
> warranted, write that Assessment Content Definition is a building block
> for the "Define, Publish, Query, and Retrieve Content" use case instead
> of "Content Definition" or otherwise do something similar.
>
> Aside: I was not able to join the WebEx for the duration of the meeting
> and even when I was joined I could pay attention only part of the time,
> so there may have been some discussion about what I am about to write.
>   Does it make sense to break out Define, Publish, Query, and Retrieve
> into separate use cases?
>
> * "Repository Content Query" --> "Repository Query".  This makes it
> clear that the repository is being queried and not the information
> represented by the content the repository holds.
>
> * Does it make sense to reorder the words in some of our terms?  For
> example, instead of saying "Assessment Content Definition" should we
> make it more active by writing "Define Assessment Content"?
>
> * In 2.1.3 it might make things clearer to be more precise about the
> repository we mean: "Query a repository..." to "Query an Assessment
> Results Repository" (or something similar).
>
> * The title for 2.1.3 might assume less of a database if it read
> something like "Mining Available Assessment Information" or something
> like that.
>
> Thoughts?
>
> Adam
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] <mailto:[email-masked]>
> [[email-masked]] on behalf of Watson, Kimberly
> [[email-masked]]
> *Sent:* Thursday, November 07, 2013 10:39 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sacm] Latest copy of the Use-Cases & Scenarios
>
> In reading the building blocks section, I had some thoughts…I have not
> had time to watch the recordings to see if you discussed these thoughts
> or not…
>
> I propose that there are objects (e.g., hardware, software, accounts)
> that have attributes that we want to know or verify as part of security
> posture assessment…
>
> So we need:
>
> Object inventory – to determine assessment needs, and (I think)
> associate both desired state and content with objects
>
> Posture Evaluation – to compare what was collected to the Desired state
> definition for the actual assessment result
>
> If you do not call out a desired state specification, then you cannot
> separate evaluation from collection where desired. I have no issue
> allowing the definition to be in the content, but I believe it is
> unnecessary and potentially “bad” to require it to be in the content.
> (in this context, “bad” means that it might actually limit applicability
> to some of our scenarios in a manner that scales).
>
> I think all the combination of usage scenarios in fact differentiate on
> different triggers for assessment associated with these building blocks
>
> *From:*Aaron Woland (aawoland) [mailto:[email-masked]]
> *Sent:* Wednesday, November 06, 2013 10:48 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sacm] Latest copy of the Use-Cases & Scenarios
>
> *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.10000263&type=1&subid=0>
>
>
> ...
>
>
> . . .
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 07 Nov 2013 15:01:13 -0500

Sadly, I too have not yet had opportunity to watch the recordings, but I 
think that a couple of the item you mentioned are worth further 
discussion.  Inlined...

> Object discovery – to know what items need to have posture assessed

There is an implied necessity for this -- after all, an assessment 
cannot proceed without having some target for that assessment.

Given the broad range of what could constitute discovery -- querying an 
inventory system, ringing out a network, manually entering targets, 
endpoint self-reporting, capturing DHCP/NAC/NAP events, starting a 
desktop system, etc -- trying to define what constitutes discovery 
should be outside the scope of SACM.

On the other hand, particularly keeping in mind that anything 
implementing the SACM standards is likely exist as part of a larger 
infrastructure, the ability to be able to communicate the target of an 
assessment into a SACM implementation is a reasonable necessity.

If this data flow is merely a list of one or more targets of interest, 
that's a fairly simple but limited data flow.  It quickly gets more 
complex if the SACM system is expected to fulfill the terms of a request 
by ringing out the network, querying an inventory system, monitoring 
network events, etc.

> associate both desired state and content with objects

Are you saying that an inventory is the result of discovery, or that 
inventory is a static repository?

I don't think there's anything within scope of the SACM charter that 
requires the existence of a static inventory as part of SACM.

But there is an implied need:  some of the classifications for endpoints 
necessary to determine the proper content to apply are not able to be 
automated.  For example MAC levels, CAI values, classification level, 
whether or not medical, personal privacy, or financial data is processed 
by that node, and so on.

Being able to automate content selection from the repository, then, 
would also need a static repository to store non-automatable information 
about the assets in some cases.  This, in turn, could be a repository 
that is part of the SACM implementation, an external repository, or a 
combination.

This leads to the need for the data flows and query ability necessary to 
fulfill retrieval of this type of static data.

It seems a bit early in the process to bring this up, but is there a 
feeling for how much of these should fall within the scope of SACM at 
this time?

> *To:* [email-masked]

---

From: Adam Montville <[email-masked]>
Date: Thu, 7 Nov 2013 21:36:23 +0000

I'm happy to extend/record a taxonomy.  I think a logical place for such a taxonomy would be the terminology document.  I guess I'll stay on that document as an author and maintain it as we keep moving forward.

Who has the latest xml for that document or does -01 reflect all the latest changes?

Adam

________________________________
From: Stephen Hanna [[email-masked]]
Sent: Thursday, November 07, 2013 1:17 PM
To: Adam Montville; Watson, Kimberly; [email-masked]
Subject: RE: [sacm] Latest copy of the Use-Cases & Scenarios

Adam,

We struggled last night with the meaning of the word “content”. In the end, we decided to just use that word to mean roughly “all the data items you need to collect and evaluate endpoint posture attributes, including the collected attribute values and maybe even results”. I’m sure that we need to break this down further and come up with names for all the kinds of data items. Your taxonomy starts down that road. I’m not an expert in this area. Can you or someone else extend your taxonomy to a finer level of detail and make sure that it includes collected attribute values and posture results?

Thanks,

Steve

Content
    |
    +-- Assessment Content
    |       +-- Collection Content
    |       +-- Evaluation Content
    +-- Reporting Content

Thoughts?

Adam

So we need:

SACM-20131107 0142-1

--
Regards,

...

. . .

...

. . .

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 7 Nov 2013 17:35:30 -0500

I have the xml.

Now you do too.

(I'm source tracking in CVS, so send me the edited file occasionally and
I'll commit it in my repository.)

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Montville
Sent: Thursday, November 07, 2013 4:36 PM
To: Stephen Hanna; Watson, Kimberly; [email-masked]
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios

I'm happy to extend/record a taxonomy.  I think a logical place for such a
taxonomy would be the terminology document.  I guess I'll stay on that
document as an author and maintain it as we keep moving forward. 

Who has the latest xml for that document or does -01 reflect all the latest
changes?

Adam

  _____  

Adam,

We struggled last night with the meaning of the word "content". In the end,
we decided to just use that word to mean roughly "all the data items you
need to collect and evaluate endpoint posture attributes, including the
collected attribute values and maybe even results". I'm sure that we need to
break this down further and come up with names for all the kinds of data
items. Your taxonomy starts down that road. I'm not an expert in this area.
Can you or someone else extend your taxonomy to a finer level of detail and
make sure that it includes collected attribute values and posture results?

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Montville
Sent: Thursday, November 07, 2013 2:07 PM
To: Watson, Kimberly; [email-masked]
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios

I think a lot of the good comments here and elsewhere on the work that is
being done this week are predicated on stabilizing our terminology.   

Content

    |

    +-- Assessment Content

    |       +-- Collection Content

    |       +-- Evaluation Content

    +-- Reporting Content

Or something like that.  If we look at the domain like this, then we can (in
2.1.1 of the most recent Word document sent yesterday evening) be precise
when we talk about "Content Definition" and choose to, if warranted, write
that Assessment Content Definition is a building block for the "Define,
Publish, Query, and Retrieve Content" use case instead of "Content
Definition" or otherwise do something similar.

Aside: I was not able to join the WebEx for the duration of the meeting and
even when I was joined I could pay attention only part of the time, so there
may have been some discussion about what I am about to write.  Does it make
sense to break out Define, Publish, Query, and Retrieve into separate use
cases?

* "Repository Content Query" --> "Repository Query".  This makes it clear
that the repository is being queried and not the information represented by
the content the repository holds.

* Does it make sense to reorder the words in some of our terms?  For
example, instead of saying "Assessment Content Definition" should we make it
more active by writing "Define Assessment Content"?

* In 2.1.3 it might make things clearer to be more precise about the
repository we mean: "Query a repository..." to "Query an Assessment Results
Repository" (or something similar).  

* The title for 2.1.3 might assume less of a database if it read something
like "Mining Available Assessment Information" or something like that.  

Thoughts?

Adam

  _____  

From: [email-masked] [[email-masked]] on behalf of Watson,
Kimberly [[email-masked]]
Sent: Thursday, November 07, 2013 10:39 AM
To: [email-masked]
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios

In reading the building blocks section, I had some thoughts.I have not had
time to watch the recordings to see if you discussed these thoughts or not.

I propose that there are objects (e.g., hardware, software, accounts) that
have attributes that we want to know or verify as part of security posture
assessment.

So we need:

Object inventory - to determine assessment needs, and (I think) associate
both desired state and content with objects

Desired state definition - to define the desired state of attributes for
assessment

Content creation/acquisition - to drive collection of required attributes
from objects for assessment

Posture Attribute Collection - to collect the necessary attributes from
objects for assessment

Posture Evaluation - to compare what was collected to the Desired state
definition for the actual assessment result

If you do not call out a desired state specification, then you cannot
separate evaluation from collection where desired. I have no issue allowing
the definition to be in the content, but I believe it is unnecessary and
potentially "bad" to require it to be in the content. (in this context,
"bad" means that it might actually limit applicability to some of our
scenarios in a manner that scales).

periodically assess everything in inventory or define/apply new assessment
to items in inventory, 

 

--

Kim Watson

This version has the changes/comments from Steve, Adam & the entire group
who met in Plaza A.

Your recording is now available on the WebEx service site. Click the link
below to play it: 

<https://new-webex.webex.com/new-webex/lsr.php?AT=pb&SP=MC&rID=72851972&rKey
=36024fbb1e68fac5>
https://new-webex.webex.com/new-webex/lsr.php?AT=pb&SP=MC&rID=72851972&rKey=
36024fbb1e68fac5 

SACM-20131107 0142-1 

* You can forward this message to others to allow them to play back the
recording. * 

-- 
Regards,

ciscoSystems, Inc. 

Check out my  <http://www.networkworld.com/community/blog/26151> Secure
Network Access Blog at Network World

Author:
<http://click.linksynergy.com/fs-bin/click?id=176dglGj6oU&offerid=145238.100
00263&type=1&subid=0> Cisco ISE for BYOD and Secure Unified Access

...

. . .

...

. . .

---

From: "Watson, Kimberly" <[email-masked]>
Date: Tue, 12 Nov 2013 19:01:07 +0000

I completely agree that the first two items I mention are required for the SACM usage scenarios/use cases, but that they might not be within the scope SACM. I'm not sure the right balance for this activity and the charter. The inventory is comprised of both things discovered and static things associated with information about them that defines necessary assessment activities/policy. You would want to assess all things in your organization that the assessment applies to...and you would want to know when something was not being assessed.

Without the ability to discover objects and communicate that to the assessment "task engine" (for lack of a better term), you cannot determine what objects have not been assessed...and by extension, you cannot make valid assertions about organizational or enterprise compliance to any policy.

Without some place that knows the objects to be assessed and the information about those objects that determines what content must be "run" (again, for lack of a better term), you cannot determine what objects have not been assessed...yadda yadda yadda.

-----Original Message-----
From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 3:01 PM
To: Watson, Kimberly; [email-masked]
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios

Sadly, I too have not yet had opportunity to watch the recordings, but I think that a couple of the item you mentioned are worth further discussion.  Inlined...

On 11/7/2013 11:39 AM, Watson, Kimberly wrote:
> In reading the building blocks section, I had some thoughts...I have not 
> had time to watch the recordings to see if you discussed these 
> thoughts or not...
>
> that have attributes that we want to know or verify as part of 
> security posture assessment...
>
> So we need:
>

There is an implied necessity for this -- after all, an assessment cannot proceed without having some target for that assessment.

Given the broad range of what could constitute discovery -- querying an inventory system, ringing out a network, manually entering targets, endpoint self-reporting, capturing DHCP/NAC/NAP events, starting a desktop system, etc -- trying to define what constitutes discovery should be outside the scope of SACM.

On the other hand, particularly keeping in mind that anything implementing the SACM standards is likely exist as part of a larger infrastructure, the ability to be able to communicate the target of an assessment into a SACM implementation is a reasonable necessity.

If this data flow is merely a list of one or more targets of interest, that's a fairly simple but limited data flow.  It quickly gets more complex if the SACM system is expected to fulfill the terms of a request by ringing out the network, querying an inventory system, monitoring network events, etc.

>
> Object inventory - to determine assessment needs, and (I think) 

Are you saying that an inventory is the result of discovery, or that inventory is a static repository?

I don't think there's anything within scope of the SACM charter that requires the existence of a static inventory as part of SACM.

But there is an implied need:  some of the classifications for endpoints necessary to determine the proper content to apply are not able to be automated.  For example MAC levels, CAI values, classification level, whether or not medical, personal privacy, or financial data is processed by that node, and so on.

Being able to automate content selection from the repository, then, would also need a static repository to store non-automatable information about the assets in some cases.  This, in turn, could be a repository that is part of the SACM implementation, an external repository, or a combination.

This leads to the need for the data flows and query ability necessary to fulfill retrieval of this type of static data.

> unnecessary and potentially "bad" to require it to be in the content.
> (in this context, "bad" means that it might actually limit applicability
> *

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 12 Nov 2013 16:15:26 -0500

Without these somebody implementing a functional SACM-compliant system 
would need to do them via a proprietary means.  The question is whether 
or not that is significant to SACM.  Is SACM meaningful enough without 
either or both of these?

And to be clear on your last statement, some content selection can be 
automated, but not all.

---

From: "Watson, Kimberly" <[email-masked]>
Date: Wed, 13 Nov 2013 12:19:35 +0000

My last comment wasn't about automated vs non-automated content selection, it was about organizational vs. endpoint compliance reporting/assessment.

You must know the difference between compliant (no findings) and not checked, and it is important to know how long it has been since an endpoint has been checked to do an organizational report. This implies (to me) that without a static repository (I use static loosely here, in that I mean an inventory of known or expected objects that is updated with new objects after every discovery) you cannot determine from 1 "set" of endpoint assessments an organization's compliance posture. You have to have multiple "sets", which implies storage of previous collection, and even then you are not guaranteed to have ever performed collection/assessment for a particular object so you are not guaranteed to generate a valid report. A static repository resolves this issue.

As for the SACM piece, I haven't thought enough to decide if SACM is meaningful without these pieces, but I do know that these items must store/express the information in a manner that is consistent with SACM or else we can't query it to create the organizational reporting needed. And maybe that's the key point...when I looked at the usage scenarios, I assumed that there was limited value in the collection/assessment of a set of endpoints in and of themselves. It was my assumption that these were actually "rolled up" into some enterprise view for awareness and/or action. It is that last piece that creates a more explicit need for the discovery and inventory.

-----Original Message-----
From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 4:15 PM
To: Watson, Kimberly; [email-masked]
Subject: Re: [sacm] Latest copy of the Use-Cases & Scenarios

Without these somebody implementing a functional SACM-compliant system would need to do them via a proprietary means.  The question is whether or not that is significant to SACM.  Is SACM meaningful enough without either or both of these?

And to be clear on your last statement, some content selection can be automated, but not all.

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 14 Nov 2013 22:18:36 +0000

This discussion has been interesting. I am currently integrating the changes from the editorial sessions last week. I'll capture this discussion in the form of questions in the next draft for additional discussion. I hope to have something posted in the next few working days.

Thanks,
Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Watson, Kimberly
> Sent: Wednesday, November 13, 2013 7:20 AM
> To: Gunnar Engelbach; [email-masked]
> My last comment wasn't about automated vs non-automated content
> selection, it was about organizational vs. endpoint compliance
> reporting/assessment.
> 
> You must know the difference between compliant (no findings) and not
> checked, and it is important to know how long it has been since an endpoint
> has been checked to do an organizational report. This implies (to me) that
> without a static repository (I use static loosely here, in that I mean an
> inventory of known or expected objects that is updated with new objects
> after every discovery) you cannot determine from 1 "set" of endpoint
> assessments an organization's compliance posture. You have to have
> multiple "sets", which implies storage of previous collection, and even then
> you are not guaranteed to have ever performed collection/assessment for a
> particular object so you are not guaranteed to generate a valid report. A
> static repository resolves this issue.
> 
> As for the SACM piece, I haven't thought enough to decide if SACM is
> meaningful without these pieces, but I do know that these items must
> store/express the information in a manner that is consistent with SACM or
> else we can't query it to create the organizational reporting needed. And
> maybe that's the key point...when I looked at the usage scenarios, I assumed
> that there was limited value in the collection/assessment of a set of
> endpoints in and of themselves. It was my assumption that these were
> actually "rolled up" into some enterprise view for awareness and/or action. It
> is that last piece that creates a more explicit need for the discovery and
> inventory.
> 
> 
> --
> Kim Watson
> Office of Cybersecurity and Communications Federal Network Resilience
> would need to do them via a proprietary means.  The question is whether or
> not that is significant to SACM.  Is SACM meaningful enough without either or
> both of these?
> 
> > I completely agree that the first two items I mention are required for the
> SACM usage scenarios/use cases, but that they might not be within the
> scope SACM. I'm not sure the right balance for this activity and the charter.
> The inventory is comprised of both things discovered and static things
> associated with information about them that defines necessary assessment
> activities/policy. You would want to assess all things in your organization that
> the assessment applies to...and you would want to know when something
> was not being assessed.
> >
> > Without the ability to discover objects and communicate that to the
> assessment "task engine" (for lack of a better term), you cannot determine
> what objects have not been assessed...and by extension, you cannot make
> valid assertions about organizational or enterprise compliance to any policy.
> >
> > Without some place that knows the objects to be assessed and the
> information about those objects that determines what content must be
> "run" (again, for lack of a better term), you cannot determine what objects
> have not been assessed...yadda yadda yadda.
> >
> > --
> > Kim Watson
> think that a couple of the item you mentioned are worth further discussion.
> Inlined...
> >
> >
> > There is an implied necessity for this -- after all, an assessment cannot
> proceed without having some target for that assessment.
> >
> inventory system, ringing out a network, manually entering targets, endpoint
> self-reporting, capturing DHCP/NAC/NAP events, starting a desktop system,
> etc -- trying to define what constitutes discovery should be outside the scope
> of SACM.
> >
> > On the other hand, particularly keeping in mind that anything implementing
> the SACM standards is likely exist as part of a larger infrastructure, the ability
> to be able to communicate the target of an assessment into a SACM
> implementation is a reasonable necessity.
> >
> > If this data flow is merely a list of one or more targets of interest, that's a
> fairly simple but limited data flow.  It quickly gets more complex if the SACM
> system is expected to fulfill the terms of a request by ringing out the
> network, querying an inventory system, monitoring network events, etc.
> >
> >
> >
> >>
> automated.  For example MAC levels, CAI values, classification level, whether
> or not medical, personal privacy, or financial data is processed by that node,
> and so on.
> >
> > Being able to automate content selection from the repository, then, would
> also need a static repository to store non-automatable information about the
> assets in some cases.  This, in turn, could be a repository that is part of the
> SACM implementation, an external repository, or a combination.
> >