[CCE-WORKING-GROUP-LIST] Capturing CCE Info

[Kent Landfield]

This is a discussion occurring on the asset-dev working group that really needs to be addressed here.

This effort has been one of maturing and evolving.  We struggled with the right level to assign CCEs and got past that hurdle.  We moved from v4 to v5 to add the Luhn check digit.  Now we need to make it   usable for other efforts to really use it appropriately.

Thoughts on making this useful from a programmatic perspective for other efforts to benefit from?

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: [phone]
Web: www.mcafee.com<http://www.mcafee.com/>

From: Kent Landfield <[hidden email]<mailto:[hidden email]>>
Date: Thu, 11 Aug 2011 10:15:53 -0500
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: Follow-up from Last Call about Capturing CCE Info (UNCLASSIFIED)

This is something that has to be address in CCE.  I do not agree that it was intended to be a human-readable format for the long term. That is where is stands today because of inadequacies in how we deal with a CCE entry that need to be further specified, but for the sake of it's usability and viability, it needs to be machine readable.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: [phone]
Web: www.mcafee.com<http://www.mcafee.com/>

From: "Davidson II, Mark S" <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Thu, 11 Aug 2011 09:52:00 -0500
To: Multiple recipients of list <[hidden email]<mailto:[hidden email]>>
Subject: RE: Follow-up from Last Call about Capturing CCE Info (UNCLASSIFIED)

CCE is intended to be a human-readable format, not a machine readable
format. For that reason, I think it will be difficult if not infeasible to
discern CCE metadata in a programmatic way.

Relevant snippet for context:
<asr:metadata>
<asrm:cce_metadata>
<asrm:param_state>disabled</asrm:param_state>
<asrm:param_setting param="roles">
<asrm:setting>admin</asrm:setting>
<asrm:setting>user</asrm:setting>
</asrm:param_setting>
</asrm:cce_metadata>
</asr:metadata>
I think it will be difficult to fill the CCE param_state/param_setting for
the following reasons:
1) There is not a machine-readable mapping from CCE to CCE parameters
2) There is not a machine-readable mapping from CCE parameters to actual
values (IE, enabled=0, disabled=1, etc)
3) There is not a machine-readable mapping from CCE to method for collecting
the value (technical mechanism)

I think if you had the data to communicate, this structure would accommodate
that data effectively. I'm not sure how we will actually get the data to
populate this structure.

-Mark

-----Original Message-----
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]] On Behalf Of WOLFKIEL,
JOSEPH L CIV DISA PEO-MA
Sent: Thursday, August 11, 2011 10:21 AM
To: Multiple recipients of list
Subject: RE: Follow-up from Last Call about Capturing CCE Info
(UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

Classification:  UNCLASSIFIED
Caveats: NONE

I can't think of a better alternative.  Not sure how well we will be able to
use this, but it appears to meet the need.  I'm worried about the lack of
structure.  Can we specify schemas for the known types of metadata (the CCE,
specifically)?  I'm also concerned that the CCE structure doesn't really
help a tool automate the translation of checks into structured results.

Looking at the schemas & documents themselves, I can't figure out why you've
structured the documents the way you have.  If all idents in a report are in
the same system, you should only have to specify the system once at the
beginning, it doesn't make sense to re-specify the system for each result
value set.  For results against a common ident, the results should be
subordinate elements with relevant group-by attributes.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
[phone]
[hidden email]<mailto:[hidden email]>


-----Original Message-----
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]] On Behalf Of
Halbardier, Adam
Sent: Monday, August 08, 2011 1:46 PM
To: Multiple recipients of list
Subject: Follow-up from Last Call about Capturing CCE Info

All,


On the last call we discussed the difficulty with reporting against CCEs
separate from the XCCDF benchmark and profile that checked the CCE.  I took
an action to look at CCE and try to come up with a mechanism that could
possibly support such a case.  Attached is a possible solution.  Basically,
I added a "metadata" construct to the result element that can capture
arbitrary metadata about the setting of an ident.  For simpler idents, we
just capture the relevant information as parameters on the result (see the
CPE example).  For the CCE example, we can use the metadata element to
capture the CCE settings.  I attached an extension schema for the CCE
metadata.  Basically, a CCE has one or more parameters.  Scanning through
the CCE spreadsheets, I think there are two categories of parameters.  One
category is what I'm calling "state" parameters.  Those are parameters that
just have a value, without a name associated with the parameter (e.g.,
"enabled/disabled").  For the first !
category, the name of the parameter is the setting.  The second category of
parameters is a named parameter that has a value, or list of values,
associated with it (e.g., user roles).  In this case, the parameter needs to
be identified, along with the value or list of values for the instance of
the CCE.  The second category I called "setting param".


A CCE metadata construct can have one or more of each of the two types of
parameters.  The parameters MUST be provided in the same order as documented
in the CCE.  The one potential disconnect here is that the values for
"setting params" isn't enumerated (and I don't think it can be), so that
could lead to data disconnects, but it might be a limitation we just have to
live with in the near-term.  Please provide thought/feedback on this
approach, and if you think it will solve the current needs.


-Adam

Classification:  UNCLASSIFIED
Caveats: NONE

Classification:  UNCLASSIFIED
Caveats: NONE

[Adam Montville]

For CCE to be machine-useful (I'm assuming you're asking the question not
just for the short term), I think the specification needs to be fleshed
out a bit - it needs to go deeper.  I'd like to see individual (typed, in
a sense) representation of technical mechanisms.  I'd like to see each
entry have a range of valid values.  Taking it a step further, I'd really
like to see each entry's relationship to other entries.  Consider the
basic example of "strong authentication" for passwords.  It's not just
length, but the collection of settings including length, complexity,
history, age, and so on.

Also, this is really where CCSS could make a difference.  It is difficult
to view CCSS as particularly meaningful until the score is dependent upon
expected values for the configuration being scored and the configurations
effecting it.

I would love to see any update to CCE be explicitly tied back to
stakeholders and process.  We find shortcomings like this in
specifications and standards in part because we didn't have a full
understanding of the needs - process and stakeholders matter.  We can use
NIST's RMF, Continuous Monitoring, any C&A process, or any number of
non-Federal IT processes to inform what CCE should be capable of (ITIL v3,
ISO 20000).

Adam

On 8/11/11 8:28 AM, "Kent Landfield" <[hidden email]> wrote:

>This is a discussion occurring on the asset-dev working group that really
>needs to be addressed here.
>
>This effort has been one of maturing and evolving.  We struggled with the
>right level to assign CCEs and got past that hurdle.  We moved from v4 to
>v5 to add the Luhn check digit.  Now we need to make it   usable for
>other efforts to really use it appropriately.
>
>Thoughts on making this useful from a programmatic perspective for other
>efforts to benefit from?
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee, Inc.
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: [phone]
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>From: Kent Landfield
><[hidden email]<mailto:[hidden email]>>
>Date: Thu, 11 Aug 2011 10:15:53 -0500
>To: "[hidden email]<mailto:[hidden email]>"
><[hidden email]<mailto:[hidden email]>>
>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>This is something that has to be address in CCE.  I do not agree that it
>was intended to be a human-readable format for the long term. That is
>where is stands today because of inadequacies in how we deal with a CCE
>entry that need to be further specified, but for the sake of it's
>usability and viability, it needs to be machine readable.
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee, Inc.
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: [phone]
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>From: "Davidson II, Mark S"
><[hidden email]<mailto:[hidden email]>>
>Reply-To: "[hidden email]<mailto:[hidden email]>"
><[hidden email]<mailto:[hidden email]>>
>Date: Thu, 11 Aug 2011 09:52:00 -0500
>To: Multiple recipients of list
><[hidden email]<mailto:[hidden email]>>
>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>CCE is intended to be a human-readable format, not a machine readable
>format. For that reason, I think it will be difficult if not infeasible to
>discern CCE metadata in a programmatic way.
>
>Relevant snippet for context:
><asr:metadata>
><asrm:cce_metadata>
><asrm:param_state>disabled</asrm:param_state>
><asrm:param_setting param="roles">
><asrm:setting>admin</asrm:setting>
><asrm:setting>user</asrm:setting>
></asrm:param_setting>
></asrm:cce_metadata>
></asr:metadata>
>I think it will be difficult to fill the CCE param_state/param_setting for
>the following reasons:
>1) There is not a machine-readable mapping from CCE to CCE parameters
>2) There is not a machine-readable mapping from CCE parameters to actual
>values (IE, enabled=0, disabled=1, etc)
>3) There is not a machine-readable mapping from CCE to method for
>collecting
>the value (technical mechanism)
>
>I think if you had the data to communicate, this structure would
>accommodate
>that data effectively. I'm not sure how we will actually get the data to
>populate this structure.
>
>-Mark
>
>-----Original Message-----
>From: [hidden email]<mailto:[hidden email]>
>[mailto:[hidden email]] On Behalf Of WOLFKIEL,
>JOSEPH L CIV DISA PEO-MA
>Sent: Thursday, August 11, 2011 10:21 AM
>To: Multiple recipients of list
>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>I can't think of a better alternative.  Not sure how well we will be able
>to
>use this, but it appears to meet the need.  I'm worried about the lack of
>structure.  Can we specify schemas for the known types of metadata (the
>CCE,
>specifically)?  I'm also concerned that the CCE structure doesn't really
>help a tool automate the translation of checks into structured results.
>
>Looking at the schemas & documents themselves, I can't figure out why
>you've
>structured the documents the way you have.  If all idents in a report are
>in
>the same system, you should only have to specify the system once at the
>beginning, it doesn't make sense to re-specify the system for each result
>value set.  For results against a common ident, the results should be
>subordinate elements with relevant group-by attributes.
>
>Joseph L. Wolfkiel
>Engineering Group Lead
>DISA PEO MA/IA52
>[phone]
>[hidden email]<mailto:[hidden email]>
>
>
>-----Original Message-----
>From: [hidden email]<mailto:[hidden email]>
>[mailto:[hidden email]] On Behalf Of
>Halbardier, Adam
>Sent: Monday, August 08, 2011 1:46 PM
>To: Multiple recipients of list
>Subject: Follow-up from Last Call about Capturing CCE Info
>
>All,
>
>
>On the last call we discussed the difficulty with reporting against CCEs
>separate from the XCCDF benchmark and profile that checked the CCE.  I
>took
>an action to look at CCE and try to come up with a mechanism that could
>possibly support such a case.  Attached is a possible solution.
>Basically,
>I added a "metadata" construct to the result element that can capture
>arbitrary metadata about the setting of an ident.  For simpler idents, we
>just capture the relevant information as parameters on the result (see the
>CPE example).  For the CCE example, we can use the metadata element to
>capture the CCE settings.  I attached an extension schema for the CCE
>metadata.  Basically, a CCE has one or more parameters.  Scanning through
>the CCE spreadsheets, I think there are two categories of parameters.  One
>category is what I'm calling "state" parameters.  Those are parameters
>that
>just have a value, without a name associated with the parameter (e.g.,
>"enabled/disabled").  For the first !
>category, the name of the parameter is the setting.  The second category
>of
>parameters is a named parameter that has a value, or list of values,
>associated with it (e.g., user roles).  In this case, the parameter needs
>to
>be identified, along with the value or list of values for the instance of
>the CCE.  The second category I called "setting param".
>
>
>A CCE metadata construct can have one or more of each of the two types of
>parameters.  The parameters MUST be provided in the same order as
>documented
>in the CCE.  The one potential disconnect here is that the values for
>"setting params" isn't enumerated (and I don't think it can be), so that
>could lead to data disconnects, but it might be a limitation we just have
>to
>live with in the near-term.  Please provide thought/feedback on this
>approach, and if you think it will solve the current needs.
>
>
>-Adam
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>

[Ronayne, James K.]

I think the lack of precision in CCE was deliberate both for practical
concerns and to allow flexibility.  Note Dave Mann's description from a
few years ago (attached).  I think the expectation has always been that
the check mechanism (typically OVAL) is the place to define parameters
and technical mechanisms in a precise machine-readable manner.  I don't
think CCE by itself was supposed to be "machine-useful". Like CVE, it
was just supposed to be an identifier for a concept.  Also like CVE, we
may make repositories where we add useful metadata that can be
associated with a CCE.  I don't think it belongs in the CCE spec but it
would be nice if some CCE repository and data feed carried additional
metadata about each item so one could derive relationships.  

CCSS specifically allows for multiple scores for a given CCE.  From the
spec: "There are potentially multiple vectors and base scores for a
single configuration issue, if there is more than one way in which it
can be configured that causes a negative security impact."  The unsolved
part I think you are suggesting is the question of how we attach each
score to a given state.  Multiple scores for CVEs are easy because they
are attached to the CVE-CPE pair.  Of course, the CPE is extra data NIST
assigns to CVEs.  It is not part of the actual CVE definition (i.e., it
wouldn't be called out in a CVE spec if one existed).  How will we
express multiple scores for CCEs?  We will need to express, in a
machine-readable way, the conditions (typically tied to parameter
values) under which each score applies.  When we run an OVAL check and
get a result how will a results tool know which score to apply?  

Jim



-----Original Message-----
From: Adam Montville [mailto:[hidden email]]
Sent: Thursday, August 11, 2011 3:07 PM
To: [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info

For CCE to be machine-useful (I'm assuming you're asking the question
not
just for the short term), I think the specification needs to be fleshed
out a bit - it needs to go deeper.  I'd like to see individual (typed,
in
a sense) representation of technical mechanisms.  I'd like to see each
entry have a range of valid values.  Taking it a step further, I'd
really
like to see each entry's relationship to other entries.  Consider the
basic example of "strong authentication" for passwords.  It's not just
length, but the collection of settings including length, complexity,
history, age, and so on.

Also, this is really where CCSS could make a difference.  It is
difficult
to view CCSS as particularly meaningful until the score is dependent
upon
expected values for the configuration being scored and the
configurations
effecting it.

I would love to see any update to CCE be explicitly tied back to
stakeholders and process.  We find shortcomings like this in
specifications and standards in part because we didn't have a full
understanding of the needs - process and stakeholders matter.  We can
use
NIST's RMF, Continuous Monitoring, any C&A process, or any number of
non-Federal IT processes to inform what CCE should be capable of (ITIL
v3,
ISO 20000).

Adam

On 8/11/11 8:28 AM, "Kent Landfield" <[hidden email]> wrote:

>This is a discussion occurring on the asset-dev working group that
really
>needs to be addressed here.
>
>This effort has been one of maturing and evolving.  We struggled with
the
>right level to assign CCEs and got past that hurdle.  We moved from v4
to
>v5 to add the Luhn check digit.  Now we need to make it   usable for
>other efforts to really use it appropriately.
>
>Thoughts on making this useful from a programmatic perspective for
other

>efforts to benefit from?
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee, Inc.
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: [phone]
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>From: Kent Landfield
><[hidden email]<mailto:[hidden email]>>
>Date: Thu, 11 Aug 2011 10:15:53 -0500
>To: "[hidden email]<mailto:[hidden email]>"
><[hidden email]<mailto:[hidden email]>>
>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>This is something that has to be address in CCE.  I do not agree that

it

>was intended to be a human-readable format for the long term. That is
>where is stands today because of inadequacies in how we deal with a CCE
>entry that need to be further specified, but for the sake of it's
>usability and viability, it needs to be machine readable.
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee, Inc.
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: [phone]
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>From: "Davidson II, Mark S"
><[hidden email]<mailto:[hidden email]>>
>Reply-To: "[hidden email]<mailto:[hidden email]>"
><[hidden email]<mailto:[hidden email]>>
>Date: Thu, 11 Aug 2011 09:52:00 -0500
>To: Multiple recipients of list
><[hidden email]<mailto:[hidden email]>>
>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>CCE is intended to be a human-readable format, not a machine readable
>format. For that reason, I think it will be difficult if not infeasible

to

>discern CCE metadata in a programmatic way.
>
>Relevant snippet for context:
><asr:metadata>
><asrm:cce_metadata>
><asrm:param_state>disabled</asrm:param_state>
><asrm:param_setting param="roles">
><asrm:setting>admin</asrm:setting>
><asrm:setting>user</asrm:setting>
></asrm:param_setting>
></asrm:cce_metadata>
></asr:metadata>
>I think it will be difficult to fill the CCE param_state/param_setting

for
>the following reasons:
>1) There is not a machine-readable mapping from CCE to CCE parameters
>2) There is not a machine-readable mapping from CCE parameters to

actual
>values (IE, enabled=0, disabled=1, etc)
>3) There is not a machine-readable mapping from CCE to method for
>collecting
>the value (technical mechanism)
>
>I think if you had the data to communicate, this structure would
>accommodate
>that data effectively. I'm not sure how we will actually get the data
to

>populate this structure.
>
>-Mark
>
>-----Original Message-----
>From: [hidden email]<mailto:[hidden email]>
>[mailto:[hidden email]] On Behalf Of WOLFKIEL,
>JOSEPH L CIV DISA PEO-MA
>Sent: Thursday, August 11, 2011 10:21 AM
>To: Multiple recipients of list
>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>I can't think of a better alternative.  Not sure how well we will be

able
>to
>use this, but it appears to meet the need.  I'm worried about the lack

of
>structure.  Can we specify schemas for the known types of metadata (the
>CCE,
>specifically)?  I'm also concerned that the CCE structure doesn't
really
>help a tool automate the translation of checks into structured results.
>
>Looking at the schemas & documents themselves, I can't figure out why
>you've
>structured the documents the way you have.  If all idents in a report
are
>in
>the same system, you should only have to specify the system once at the
>beginning, it doesn't make sense to re-specify the system for each
result

>value set.  For results against a common ident, the results should be
>subordinate elements with relevant group-by attributes.
>
>Joseph L. Wolfkiel
>Engineering Group Lead
>DISA PEO MA/IA52
>[phone]
>[hidden email]<mailto:[hidden email]>
>
>
>-----Original Message-----
>From: [hidden email]<mailto:[hidden email]>
>[mailto:[hidden email]] On Behalf Of
>Halbardier, Adam
>Sent: Monday, August 08, 2011 1:46 PM
>To: Multiple recipients of list
>Subject: Follow-up from Last Call about Capturing CCE Info
>
>All,
>
>
>On the last call we discussed the difficulty with reporting against

CCEs
>separate from the XCCDF benchmark and profile that checked the CCE.  I
>took
>an action to look at CCE and try to come up with a mechanism that could
>possibly support such a case.  Attached is a possible solution.
>Basically,
>I added a "metadata" construct to the result element that can capture
>arbitrary metadata about the setting of an ident.  For simpler idents,

we
>just capture the relevant information as parameters on the result (see
the
>CPE example).  For the CCE example, we can use the metadata element to
>capture the CCE settings.  I attached an extension schema for the CCE
>metadata.  Basically, a CCE has one or more parameters.  Scanning
through
>the CCE spreadsheets, I think there are two categories of parameters.
One
>category is what I'm calling "state" parameters.  Those are parameters
>that
>just have a value, without a name associated with the parameter (e.g.,
>"enabled/disabled").  For the first !
>category, the name of the parameter is the setting.  The second
category
>of
>parameters is a named parameter that has a value, or list of values,
>associated with it (e.g., user roles).  In this case, the parameter
needs
>to
>be identified, along with the value or list of values for the instance
of
>the CCE.  The second category I called "setting param".
>
>
>A CCE metadata construct can have one or more of each of the two types
of
>parameters.  The parameters MUST be provided in the same order as
>documented
>in the CCE.  The one potential disconnect here is that the values for
>"setting params" isn't enumerated (and I don't think it can be), so
that
>could lead to data disconnects, but it might be a limitation we just
have

>to
>live with in the near-term.  Please provide thought/feedback on this
>approach, and if you think it will solve the current needs.
>
>
>-Adam
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>

Dennis Moreau wrote:
> I want to thank Dave very much for raising this issue. It is near and
> dear to me, as some of you already know. However, I have been
> suppressing my instinct to grapple with the longer term security
> semantics issues to avoid distraction from the progress being made on
> CCE.

Well then, I'm glad that I tossed that note out as I think it's
super important for us to achieve as much unity in vision for CCE as
possible and that will only happen if we work through these issues.
I'm afraid the issue of CCE as it relates to semantics is already
a distraction -- at least one that's percolating along just under
the surface, so perhaps this is a subject who's time has come.

I'd like to name some statements that I think we more or less
agree on and, by parroting them back, see if we can jointly affirm
the agreement.  I'd also like to press into some of the other related
statements to get a better understanding of them but I'll address
them in a second e-mail so that we can first consolidate the common
ground.  


Dave Mann wrote:

> I would like us to consider ISBN numbers, which appear
> on books and want to call out some interesting features
> about them.  The first thing that I find so interesting
> is that there is no shortage of semantically rich and well
> established data bases (and ontologies, no doubt) that
> deal with books.  Book stores like Amazon have them.
> Your local library has them.  But despite the availability
> of these semantically rich repositories that describe
> books in precise detail, ISBNs continue to persist
> and have meaning.

Dennis Moreau wrote:
> There is little need in the primary use cases associated with these
> identifiers to do more than associate emergent information with them
> unambiguously.
[snip...]
> This is one possible type of role for CCEs, and is analogous to the
> role CVEs play as vulnerability identifiers; primarily as an
> establishment of control attribute "identity" and subsequently as an
> associator of emergent information from many sources.  


Wolfkiel, Joseph wrote:
> So my take on CCEs is that they should be viewed as entryways into a
> richer data model.

I think the 3 of us are driving at the same observation but
I think Joe has made the clearest and most succinct statement!

Based on some our internal literature reviews, I think what we are
all is that CVE and CCE might be described as "boundary objects".  

Here are 2 excerpts from a paper entitled "Between Chaos and
Routine: Boundary Negotiating Artifacts in Collaboration" by
Charlotte Lee (ECSCW 2005: Proceedings of the Ninth European
Conference on Computer Supported Cooperative Work) in which Lee
refers to the book "Sorting Things Out: Classification and Its
Consequences" by Bowker and Star (1999, The MIT Press).  Lee writes,

  Boundary Objects are created when groups from different worlds work
  together. Shared work creates objects which inhabit multiple worlds
  simultaneously. In /Sorting Things Out/, Bowker and Star (1999)
  describe the concept of boundary objects.
   
    Boundary objects are those objects that both inhabit several
    communities of practice and satisfy the informational requirements
    of each of them. Boundary objects are thus both plastic enough
    to adapt to local needs and constraints of the several parties
    employing them, yet robust enough to maintain common identity
    across sites. They are weakly structured in common use and become
    strongly structured in individual-site use. These objects may be
    abstract or concrete. Star and Griesemer (1989) first noticed the
    phenomenon in studying a museum, where specimens of dead birds had
    very different meaning to amateur bird watchers and professional
    biologists, but "the same" bird was used by each group. Such
    objects have different meaning in different social worlds but
    structure is common enough to more than one world to make them
    recognizable, a means of translation. The creation and management
    of boundary objects is a key process in developing and maintaining
    coherence across intersecting communities (Bowker an Star 1999).
   
So, there you have it.  CCEs are like a collection of dead birds. ;^)

There are a few aspects of this definition that deserve to be
highlighted
in the context of CVE and CCE.  The first is that unlike dead birds,
which are concrete material objects,  CCEs are abstract.  Bowker and
Star recognize that abstract constructs can still function as boundary
objects.

The second is Bowker and Star's assertion that boundary objects are
"weakly structured in common use". This is similar to the
(almost 10 year old) CVE mantra that CVE is a dictionary, not a
database. In CVE, we've repeatedly stated that our primary internal
goal of the CVE data model is to provide just enough information to
a) justify the existence of an entry and b) to discriminate that entry
from other entries. We think this is precisely the guiding principle
of dictionaries and I think it lines up nicely with Bowker and Star's
idea of objects that are weakly structured in common use.

Thirdly, Bowker and Star observe that the boundary objects
become "strongly structured in individual-site use".  I think this
lines
up perfectly with what Joe Wolfkiel was getting at when he wrote that
CCEs "should be viewed as entryways into a richer data model".
Following
Bowker and Star, I think we can extend Joe's comment to recognize that
different communities of practice will have different "richer data
models".  I think we can begin to identify some of the different
communities of practice that may be mutual interest in CCEs as
boundary objects including but not limited to: regulators, auditors,
system designers, configuration management processes, configuration
assessment tools, CIOs and reporting.  It may be that different members
of each of these sub-communities have rich data models are that more
or less alike and even sharable for that specific community of
practice.
For example, OVAL might be seen as a semantically rich data model
that is sharable within the configuration assessment practice. But we
would not expect that data model to be useful for regulators or even
security guide authors.  That is, the different practices will have
data models that are significantly different from one practice to
another.  So, the notion of a configuration control may have different
specific meaning to auditors than it does to assessment products,
just as the dead birds had different specific meanings to the bird
watchers and biologists.

Notice, and I think this is key, that the fact that the different
meanings held by the different communities of practice doesn't imply
that they are talking about different things.  They aren't.  The
bird watchers and biologists were talking about the same birds. In
the same way, guide authors and assessment tools might talk about
the same CCE definitions. The only difference is that a bird is
seen as being concrete whereas the CCE definition is seen as being
an abstraction.  Again, boundary object can be either. I also think
this lines up nicely with what Dennis wrote when he suggested that
CVEs and CCEs provide the "establishment of a control attribute
"identity".   The fact that we have different semantic understandings
of a configuration control does not imply that the abstract identity
provided by the CCE definition stops being the same thing.  The
CCE definition remains the same (weakly defined) control attribute
identity just as the material birds are the same.

The fourth aspect of this definition of boundary objects that we
should call out is that they are recognizable to human participants
in different communities of practice which makes them a "means of
translation" according to Bowker and Star.  I think this is mirrored
in Joe's description of CVEs and CCEs as "gateways" and Dennis's
description of them as functioning as an "associator".  This process
of aligning different communities of practice via a set of shared
"gateways" or "associators" strikes me as a (primarily) human
activity (which may be augmented by information systems). This is what
I was clumsily groping for when I asked us all to consider why
ISBNs and VINs persist despite the availability of semantically
rich data models.  I think Bowker and Star are pointing us to the
answer.  CVE and CCEs are operating as boundary objects by which
we (humans) engage in the process of "developing and maintaining
coherence across intersecting communities."


I thought I'd mention one more aspect of boundary objects that Lee
makes in describing a partial list of types of boundary objects.
Here she draws on:
 + Star, S.L. (1987- 1989) "The Structure of Ill-Structured Solutions:
   Boundary Objects and Heterogeneous Distributed Problem Solving"
   Distributed Artificial Intelligence. Gassner and Huhns. Morgan
   Kaufmann. Vol II
 + Star, S.L. and J.R.Griesemer (1989). "Institutional Ecology,
   'Translations' and Boundary Object: Amateurs and Professionals
   in Berkley's Museum of Vertebrate Zoology, 1907-39". Social
   Studies of Science Vol 19.
   
Lee writes,
  Boundary objects arise over time from durable cooperation among
  communities of practice. Star lists four types of boundary objects
  (Star 1987-1989; Star and Griesemer 1989):
  + Repositories which are 'piles of objects that are indexed in a
    standardized fashion such as libraries'.
  + Ideal Type which does accurately describe the details of any one
    locality or thing but is abstract and vague and therefore
    adaptable, such as a diagram or atlas.
  + Coincident Boundaries which are common objects which have the
    same boundaries but different internal contents, such as the
    political boundary of the state of California.
  + Standardized Forms which are standardized indices that serve
    as methods of common communication, such as forms.
   
  While Star notes that this list is by no means exhaustive, it is
  interesting to note that two of the four types of boundary objects
  have standardization as a key component. Repositories are indexed
  in a /standardized fashion/ and standardized forms are /standardized
  indicies/.
 
I think Lee's observation here may give us a foothold in understanding
the difference between CVE and CCE's namespace and CPE's namespace.
If I'm understanding Lee's point about Star and Griesemer's types
correctly (and I may be off base here), I think we can say that all
three are used as identifiers or indicies that serve as harmonizing
boundary objects.  However, I think CVE and CCE would be characterized
as (abstract) repositories, whereas CPE would be characterized as an
abstract form.

With respect to CVE and CCE, I think the "piles of objects" are the
(abstract) piles of CVE and CCE definitions which are then indexed
in a standard fashion by CVE and CCE ids.   On the other hand, I
think the CPE model is a standardized form as defined by the CPE
specification. Once created, each instance of a CPE name that is
created according to the standardized form can act as a standardized
index.    

So, while repositories and standardized forms are constructed
differently, they both have the affect of producing common identifiers
that can be used as shared boundary objects .


Dennis has raised some interesting questions about CCE's long term
utility viz-a-viz linkages to other semantics that I would like to
clarify.  Joe has raised several other questions regarding management
of the ids and construction of the namespace.  And I've got a few
other issues I'd like to raise as well.   But before we proceed,
I'd like to hear more feedback to confirm our collective commitment
to this fundamental use-case for CCE.

Can we firm jointly affirm CCEs as weakly defined boundary objects
that can be used to align semantics across the different communities
of practice that we collectively represent?


-Dave
=================================================================
David Mann   |   CVE & CCE Project   |  The MITRE Corporation
-----------------------------------------------------------------
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================

[Adam Montville]

Rushing through this a bit...

On 8/12/11 8:21 AM, "Ronayne, James K." <[hidden email]> wrote:

>I think the lack of precision in CCE was deliberate both for practical
>concerns and to allow flexibility.  Note Dave Mann's description from a
>few years ago (attached).  I think the expectation has always been that
>the check mechanism (typically OVAL) is the place to define parameters
>and technical mechanisms in a precise machine-readable manner.

I can buy this.  It seems, then, that there ought to be a strong
relationship between the two - CCE and OVAL.  Is this a spec issue or an
operational issue?

>  I don't
>think CCE by itself was supposed to be "machine-useful". Like CVE, it
>was just supposed to be an identifier for a concept.

Concepts can have value ranges, so we need to find some way of getting
this done.  If OVAL is the solution, great.  If it's not, what is?

>Also like CVE, we
>may make repositories where we add useful metadata that can be
>associated with a CCE.

If multiple repositories exist, how do we make them useful in an
interoperable way?

>  I don't think it belongs in the CCE spec but it
>would be nice if some CCE repository and data feed carried additional
>metadata about each item so one could derive relationships.

That's totally fair.  These capabilities may not belong in the spec
proper, but something needs to define relationships and bindings between
what we conceive as a CCE and extended information about it - even if this
is really more of an operational problem.



>
>CCSS specifically allows for multiple scores for a given CCE.

Didn't realize that - apologies to the list.

> From the
>spec: "There are potentially multiple vectors and base scores for a
>single configuration issue, if there is more than one way in which it
>can be configured that causes a negative security impact."  The unsolved
>part I think you are suggesting is the question of how we attach each
>score to a given state.

Sounds like a fair characterization to me, and it seems that the
distinction (as you point out below in the CVE example) is one of "spec"
vs. "operation."  Is this at all like X.509 and Certificate Authorities?
X.509 provides the details of what makes a certificate, how to express
that in a machine consumable manner, but essentially leaves the
operational aspects up to the entity issuing X.509 certificates.  Such an
entity has a Certification Practice Statement (CPS), which is - more or
less - their operational contract expressing to the world how they intend
to operate, what the exact certificate lifecycle is, and so on.

Do we need a "CPS" framework for entities with the desire to create
repositories?

Is that totally off base?

>  Multiple scores for CVEs are easy because they
>are attached to the CVE-CPE pair.  Of course, the CPE is extra data NIST
>assigns to CVEs.  It is not part of the actual CVE definition (i.e., it
>wouldn't be called out in a CVE spec if one existed).  How will we
>express multiple scores for CCEs?  We will need to express, in a
>machine-readable way, the conditions (typically tied to parameter
>values) under which each score applies.  When we run an OVAL check and
>get a result how will a results tool know which score to apply?
>
>Jim
>
>
>
>-----Original Message-----
>From: Adam Montville [mailto:[hidden email]]
>Sent: Thursday, August 11, 2011 3:07 PM
>To: [hidden email]
>Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info
>
>For CCE to be machine-useful (I'm assuming you're asking the question
>not
>just for the short term), I think the specification needs to be fleshed
>out a bit - it needs to go deeper.  I'd like to see individual (typed,
>in
>a sense) representation of technical mechanisms.  I'd like to see each
>entry have a range of valid values.  Taking it a step further, I'd
>really
>like to see each entry's relationship to other entries.  Consider the
>basic example of "strong authentication" for passwords.  It's not just
>length, but the collection of settings including length, complexity,
>history, age, and so on.
>
>Also, this is really where CCSS could make a difference.  It is
>difficult
>to view CCSS as particularly meaningful until the score is dependent
>upon
>expected values for the configuration being scored and the
>configurations
>effecting it.
>
>I would love to see any update to CCE be explicitly tied back to
>stakeholders and process.  We find shortcomings like this in
>specifications and standards in part because we didn't have a full
>understanding of the needs - process and stakeholders matter.  We can
>use
>NIST's RMF, Continuous Monitoring, any C&A process, or any number of
>non-Federal IT processes to inform what CCE should be capable of (ITIL
>v3,
>ISO 20000).
>
>Adam
>
>On 8/11/11 8:28 AM, "Kent Landfield" <[hidden email]> wrote:
>
>>This is a discussion occurring on the asset-dev working group that
>really
>>needs to be addressed here.
>>
>>This effort has been one of maturing and evolving.  We struggled with
>the
>>right level to assign CCEs and got past that hurdle.  We moved from v4
>to
>>v5 to add the Luhn check digit.  Now we need to make it   usable for
>>other efforts to really use it appropriately.
>>
>>Thoughts on making this useful from a programmatic perspective for
>other
>>efforts to benefit from?
>>
>>Kent Landfield
>>Director Content Strategy, Architecture and Standards
>>
>>McAfee, Inc.
>>5000 Headquarters Dr.
>>Plano, Texas 75024
>>
>>Direct: +1.972.963.7096
>>Mobile: [phone]
>>Web: www.mcafee.com<http://www.mcafee.com/>
>>
>>From: Kent Landfield
>><[hidden email]<mailto:[hidden email]>>
>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>To: "[hidden email]<mailto:[hidden email]>"
>><[hidden email]<mailto:[hidden email]>>
>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>(UNCLASSIFIED)
>>
>>This is something that has to be address in CCE.  I do not agree that
>it
>>was intended to be a human-readable format for the long term. That is
>>where is stands today because of inadequacies in how we deal with a CCE
>>entry that need to be further specified, but for the sake of it's
>>usability and viability, it needs to be machine readable.
>>
>>Kent Landfield
>>Director Content Strategy, Architecture and Standards
>>
>>McAfee, Inc.
>>5000 Headquarters Dr.
>>Plano, Texas 75024
>>
>>Direct: +1.972.963.7096
>>Mobile: [phone]
>>Web: www.mcafee.com<http://www.mcafee.com/>
>>
>>From: "Davidson II, Mark S"
>><[hidden email]<mailto:[hidden email]>>
>>Reply-To: "[hidden email]<mailto:[hidden email]>"
>><[hidden email]<mailto:[hidden email]>>
>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>To: Multiple recipients of list
>><[hidden email]<mailto:[hidden email]>>
>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>(UNCLASSIFIED)
>>
>>CCE is intended to be a human-readable format, not a machine readable
>>format. For that reason, I think it will be difficult if not infeasible
>to
>>discern CCE metadata in a programmatic way.
>>
>>Relevant snippet for context:
>><asr:metadata>
>><asrm:cce_metadata>
>><asrm:param_state>disabled</asrm:param_state>
>><asrm:param_setting param="roles">
>><asrm:setting>admin</asrm:setting>
>><asrm:setting>user</asrm:setting>
>></asrm:param_setting>
>></asrm:cce_metadata>
>></asr:metadata>
>>I think it will be difficult to fill the CCE param_state/param_setting
>for
>>the following reasons:
>>1) There is not a machine-readable mapping from CCE to CCE parameters
>>2) There is not a machine-readable mapping from CCE parameters to
>actual
>>values (IE, enabled=0, disabled=1, etc)
>>3) There is not a machine-readable mapping from CCE to method for
>>collecting
>>the value (technical mechanism)
>>
>>I think if you had the data to communicate, this structure would
>>accommodate
>>that data effectively. I'm not sure how we will actually get the data
>to
>>populate this structure.
>>
>>-Mark
>>
>>-----Original Message-----
>>From: [hidden email]<mailto:[hidden email]>
>>[mailto:[hidden email]] On Behalf Of WOLFKIEL,
>>JOSEPH L CIV DISA PEO-MA
>>Sent: Thursday, August 11, 2011 10:21 AM
>>To: Multiple recipients of list
>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>(UNCLASSIFIED)
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>>
>>I can't think of a better alternative.  Not sure how well we will be
>able
>>to
>>use this, but it appears to meet the need.  I'm worried about the lack
>of
>>structure.  Can we specify schemas for the known types of metadata (the
>>CCE,
>>specifically)?  I'm also concerned that the CCE structure doesn't
>really
>>help a tool automate the translation of checks into structured results.
>>
>>Looking at the schemas & documents themselves, I can't figure out why
>>you've
>>structured the documents the way you have.  If all idents in a report
>are
>>in
>>the same system, you should only have to specify the system once at the
>>beginning, it doesn't make sense to re-specify the system for each
>result
>>value set.  For results against a common ident, the results should be
>>subordinate elements with relevant group-by attributes.
>>
>>Joseph L. Wolfkiel
>>Engineering Group Lead
>>DISA PEO MA/IA52
>>[phone]
>>[hidden email]<mailto:[hidden email]>
>>
>>
>>-----Original Message-----
>>From: [hidden email]<mailto:[hidden email]>
>>[mailto:[hidden email]] On Behalf Of
>>Halbardier, Adam
>>Sent: Monday, August 08, 2011 1:46 PM
>>To: Multiple recipients of list
>>Subject: Follow-up from Last Call about Capturing CCE Info
>>
>>All,
>>
>>
>>On the last call we discussed the difficulty with reporting against
>CCEs
>>separate from the XCCDF benchmark and profile that checked the CCE.  I
>>took
>>an action to look at CCE and try to come up with a mechanism that could
>>possibly support such a case.  Attached is a possible solution.
>>Basically,
>>I added a "metadata" construct to the result element that can capture
>>arbitrary metadata about the setting of an ident.  For simpler idents,
>we
>>just capture the relevant information as parameters on the result (see
>the
>>CPE example).  For the CCE example, we can use the metadata element to
>>capture the CCE settings.  I attached an extension schema for the CCE
>>metadata.  Basically, a CCE has one or more parameters.  Scanning
>through
>>the CCE spreadsheets, I think there are two categories of parameters.
>One
>>category is what I'm calling "state" parameters.  Those are parameters
>>that
>>just have a value, without a name associated with the parameter (e.g.,
>>"enabled/disabled").  For the first !
>>category, the name of the parameter is the setting.  The second
>category
>>of
>>parameters is a named parameter that has a value, or list of values,
>>associated with it (e.g., user roles).  In this case, the parameter
>needs
>>to
>>be identified, along with the value or list of values for the instance
>of
>>the CCE.  The second category I called "setting param".
>>
>>
>>A CCE metadata construct can have one or more of each of the two types
>of
>>parameters.  The parameters MUST be provided in the same order as
>>documented
>>in the CCE.  The one potential disconnect here is that the values for
>>"setting params" isn't enumerated (and I don't think it can be), so
>that
>>could lead to data disconnects, but it might be a limitation we just
>have
>>to
>>live with in the near-term.  Please provide thought/feedback on this
>>approach, and if you think it will solve the current needs.
>>
>>
>>-Adam
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>>

[Mann, Dave]

Kent and the rest of the working group...

I really don't want to shut down discussion on this prematurely and would like to explicitly ask you to talk more about the specific use cases you would like to see supported by greater availability of machine readable content related to CCE entries.  Who do you envision creating the content?  Who will be consuming it?  What specifically will they be using it for?

I believe you are articulating a very real and pressing need in the larger configuration management industry and we're happy if the CCE Working Group list can help sort through the issues and provide better industry consensus on the matter.

In the end though, I think Jim Ronayne has accurately summarized CCE's traditional posture on such questions.  Here is my slight expansion on what I think the key points are:

1) Like CVE, CCEs were envisioned to help human analysts to correlate configuration information faster and more accurately - not to directly facilitate machine reasoning.  CCE was founded on 5 documented use cases as discussed in section 4 of the CCE overview paper [1].  In all 5 of the scenarios, the correlation is done by humans, even the 4th use case in which results from multiple audit tools are integrated.

2) If there is a clear and compelling need for machine processable information regarding configuration controls that is not being met by other current efforts [2], the following questions should be worked through:
+ What use cases should it support?
+ Who will create the content?
+ Who will be the guarantor of the quality of that content?
+ Should this be a government funded effort, "open source" or a commercial venture?

We're happy to have that discussion unfold here on this list, even if the end result isn't (and shouldn't be) a part of CCE.

3) Since the issue of CCE's future has been raised, my sense is that the important success goals for CCE's near to mid-term progress include:
+ Broader coverage of security guides and audit tool issues by CCE.
+ A content management and provisioning system capable of scaling to this scope
+ A formalized adoption program (similar to CVE's) that defines industry best practices for the inclusion of CCE ids into configuration management tools and services.
+ More ubiquitous usage of CCE ids in configuration management tools and services.


Just to reiterate point 2)... Please feel free to continue the discussion here.  It's an important issue and needs to be discussed.  


[1] - http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_2008.pdf

[2] - If OVAL is sufficient to meet the use cases (unknowable till the use cases are defined), we note that both NIST SCAP/FDCC and MITRE's OVAL Repository provide sets of machine processable checks.  The first is funded by the US Government and the latter is more of an open source effort (and traditionally, more focused on vulnerabilities than configuration controls).

-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:[hidden email] | cell:781.424.6003
==================================================================

>-----Original Message-----
>From: [hidden email] [mailto:owner-cce-
>[hidden email]] On Behalf Of
>[hidden email]
>Sent: Thursday, August 11, 2011 11:28 AM
>To: cce-working-group-list
>Subject: Capturing CCE Info
>
>This is a discussion occurring on the asset-dev working group that really
>needs to be addressed here.
>
>This effort has been one of maturing and evolving.  We struggled with the
>right level to assign CCEs and got past that hurdle.  We moved from v4 to v5
>to add the Luhn check digit.  Now we need to make it   usable for other
>efforts to really use it appropriately.
>
>Thoughts on making this useful from a programmatic perspective for other
>efforts to benefit from?
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee, Inc.
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: [phone]
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>From: Kent Landfield
><[hidden email]<mailto:[hidden email]>>
>Date: Thu, 11 Aug 2011 10:15:53 -0500
>To: "[hidden email]<mailto:[hidden email]>" <asset-
>[hidden email]<mailto:[hidden email]>>
>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>This is something that has to be address in CCE.  I do not agree that it was
>intended to be a human-readable format for the long term. That is where is
>stands today because of inadequacies in how we deal with a CCE entry that
>need to be further specified, but for the sake of it's usability and viability, it
>needs to be machine readable.
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee, Inc.
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: [phone]
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>From: "Davidson II, Mark S"
><[hidden email]<mailto:[hidden email]>>
>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>[hidden email]<mailto:[hidden email]>>
>Date: Thu, 11 Aug 2011 09:52:00 -0500
>To: Multiple recipients of list <[hidden email]<mailto:asset-
>[hidden email]>>
>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>CCE is intended to be a human-readable format, not a machine readable
>format. For that reason, I think it will be difficult if not infeasible to
>discern CCE metadata in a programmatic way.
>
>Relevant snippet for context:
><asr:metadata>
><asrm:cce_metadata>
><asrm:param_state>disabled</asrm:param_state>
><asrm:param_setting param="roles">
><asrm:setting>admin</asrm:setting>
><asrm:setting>user</asrm:setting>
></asrm:param_setting>
></asrm:cce_metadata>
></asr:metadata>
>I think it will be difficult to fill the CCE param_state/param_setting for
>the following reasons:
>1) There is not a machine-readable mapping from CCE to CCE parameters
>2) There is not a machine-readable mapping from CCE parameters to actual
>values (IE, enabled=0, disabled=1, etc)
>3) There is not a machine-readable mapping from CCE to method for
>collecting
>the value (technical mechanism)
>
>I think if you had the data to communicate, this structure would
>accommodate
>that data effectively. I'm not sure how we will actually get the data to
>populate this structure.
>
>-Mark
>
>-----Original Message-----
>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>[hidden email]] On Behalf Of WOLFKIEL,
>JOSEPH L CIV DISA PEO-MA
>Sent: Thursday, August 11, 2011 10:21 AM
>To: Multiple recipients of list
>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>(UNCLASSIFIED)
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>I can't think of a better alternative.  Not sure how well we will be able to
>use this, but it appears to meet the need.  I'm worried about the lack of
>structure.  Can we specify schemas for the known types of metadata (the CCE,
>specifically)?  I'm also concerned that the CCE structure doesn't really
>help a tool automate the translation of checks into structured results.
>
>Looking at the schemas & documents themselves, I can't figure out why
>you've
>structured the documents the way you have.  If all idents in a report are in
>the same system, you should only have to specify the system once at the
>beginning, it doesn't make sense to re-specify the system for each result
>value set.  For results against a common ident, the results should be
>subordinate elements with relevant group-by attributes.
>
>Joseph L. Wolfkiel
>Engineering Group Lead
>DISA PEO MA/IA52
>[phone]
>[hidden email]<mailto:[hidden email]>
>
>
>-----Original Message-----
>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>[hidden email]] On Behalf Of
>Halbardier, Adam
>Sent: Monday, August 08, 2011 1:46 PM
>To: Multiple recipients of list
>Subject: Follow-up from Last Call about Capturing CCE Info
>
>All,
>
>
>On the last call we discussed the difficulty with reporting against CCEs
>separate from the XCCDF benchmark and profile that checked the CCE.  I took
>an action to look at CCE and try to come up with a mechanism that could
>possibly support such a case.  Attached is a possible solution.  Basically,
>I added a "metadata" construct to the result element that can capture
>arbitrary metadata about the setting of an ident.  For simpler idents, we
>just capture the relevant information as parameters on the result (see the
>CPE example).  For the CCE example, we can use the metadata element to
>capture the CCE settings.  I attached an extension schema for the CCE
>metadata.  Basically, a CCE has one or more parameters.  Scanning through
>the CCE spreadsheets, I think there are two categories of parameters.  One
>category is what I'm calling "state" parameters.  Those are parameters that
>just have a value, without a name associated with the parameter (e.g.,
>"enabled/disabled").  For the first !
>category, the name of the parameter is the setting.  The second category of
>parameters is a named parameter that has a value, or list of values,
>associated with it (e.g., user roles).  In this case, the parameter needs to
>be identified, along with the value or list of values for the instance of
>the CCE.  The second category I called "setting param".
>
>
>A CCE metadata construct can have one or more of each of the two types of
>parameters.  The parameters MUST be provided in the same order as
>documented
>in the CCE.  The one potential disconnect here is that the values for
>"setting params" isn't enumerated (and I don't think it can be), so that
>could lead to data disconnects, but it might be a limitation we just have to
>live with in the near-term.  Please provide thought/feedback on this
>approach, and if you think it will solve the current needs.
>
>
>-Adam
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>Classification:  UNCLASSIFIED
>Caveats: NONE

[Adam Montville]

On 8/17/11 9:11 AM, "Mann, Dave" <[hidden email]> wrote:

>Kent and the rest of the working group...
>
>I really don't want to shut down discussion on this prematurely and would
>like to explicitly ask you to talk more about the specific use cases you
>would like to see supported by greater availability of machine readable
>content related to CCE entries.  Who do you envision creating the
>content?  Who will be consuming it?  What specifically will they be using
>it for?
>
>I believe you are articulating a very real and pressing need in the
>larger configuration management industry and we're happy if the CCE
>Working Group list can help sort through the issues and provide better
>industry consensus on the matter.
>
>In the end though, I think Jim Ronayne has accurately summarized CCE's
>traditional posture on such questions.  Here is my slight expansion on
>what I think the key points are:
>
>1) Like CVE, CCEs were envisioned to help human analysts to correlate
>configuration information faster and more accurately - not to directly
>facilitate machine reasoning.

At the time, helping human analysts correlate was the requirement.  I
believe now this has changed somewhat.  I would like to see the industry
move in a direction that permits very complicated correlations in an
automated manner.  As we mature beyond the C&A-motivated capabilities of
asset, configuration, and vulnerability management into supporting
specific security processes (I.e. Event correlation), we are going to be
serving much different needs.

>CCE was founded on 5 documented use cases as discussed in section 4 of
>the CCE overview paper [1].  In all 5 of the scenarios, the correlation
>is done by humans, even the 4th use case in which results from multiple
>audit tools are integrated.

This is an excellent point.  I can see a future, however, where more use
cases are added, based on the inclusion of other processes.  Consider a
SIEM tool that detects five failed logon attempts over an hour's time
followed by a good logon.  Traditionally, we would rely on a human to go
figure out whether that incident is benign.  With configuration data,
however, we could bolster that correlation to trigger only when particular
configuration items are set in a particular way, if a configuration item
subsequently changed, and so on.

This is a problem not just limited to CCE, I think.  I'd also like to see
things like: Tell me whether that user recently changed their password,
because if they did, then the probability that this incident is benign
just went up.

>
>2) If there is a clear and compelling need for machine processable
>information regarding configuration controls that is not being met by
>other current efforts [2], the following questions should be worked
>through:
>+ What use cases should it support?

This is probably the first question to answer, but I assert that to answer
this question properly we need to identify the processes we would intend
to support.  This is something that seems to be "common knowledge" in the
community, but that is rarely called out explicitly.

>+ Who will create the content?
>+ Who will be the guarantor of the quality of that content?
>+ Should this be a government funded effort, "open source" or a
>commercial venture?
>
>We're happy to have that discussion unfold here on this list, even if the
>end result isn't (and shouldn't be) a part of CCE.
>
>3) Since the issue of CCE's future has been raised, my sense is that the
>important success goals for CCE's near to mid-term progress include:
>+ Broader coverage of security guides and audit tool issues by CCE.

I'm wondering if this isn't too narrow a focus.  This relegates CCE to
security-specific settings, and it's clear that this industry is coming to
the realization that security-specific processes really support IT
processes, and that IT processes encompass more than security-specific
settings.  This will become especially true as we mature beyond the
process domain served by SCAP.

>+ A content management and provisioning system capable of scaling to this
>scope
>+ A formalized adoption program (similar to CVE's) that defines industry
>best practices for the inclusion of CCE ids into configuration management
>tools and services.
>+ More ubiquitous usage of CCE ids in configuration management tools and
>services.
>
>
>Just to reiterate point 2)... Please feel free to continue the discussion
>here.  It's an important issue and needs to be discussed.

This is good.  I don't know if CCE is the right place for what we think we
need at this point, but it's certainly related.

>
>
>[1] -
>http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_2008.p
>df
>
>[2] - If OVAL is sufficient to meet the use cases (unknowable till the
>use cases are defined), we note that both NIST SCAP/FDCC and MITRE's OVAL
>Repository provide sets of machine processable checks.  The first is
>funded by the US Government and the latter is more of an open source
>effort (and traditionally, more focused on vulnerabilities than
>configuration controls).
>
>-Dave
>==================================================================
>David Mann | Principal Infosec Scientist | The MITRE Corporation
>------------------------------------------------------------------
>e-mail:[hidden email] | cell:781.424.6003
>==================================================================
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:owner-cce-
>>[hidden email]] On Behalf Of
>>[hidden email]
>>Sent: Thursday, August 11, 2011 11:28 AM
>>To: cce-working-group-list
>>Subject: Capturing CCE Info
>>
>>This is a discussion occurring on the asset-dev working group that really
>>needs to be addressed here.
>>
>>This effort has been one of maturing and evolving.  We struggled with the
>>right level to assign CCEs and got past that hurdle.  We moved from v4
>>to v5
>>to add the Luhn check digit.  Now we need to make it   usable for other
>>efforts to really use it appropriately.
>>
>>Thoughts on making this useful from a programmatic perspective for other
>>efforts to benefit from?
>>
>>Kent Landfield
>>Director Content Strategy, Architecture and Standards
>>
>>McAfee, Inc.
>>5000 Headquarters Dr.
>>Plano, Texas 75024
>>
>>Direct: +1.972.963.7096
>>Mobile: [phone]
>>Web: www.mcafee.com<http://www.mcafee.com/>
>>
>>From: Kent Landfield
>><[hidden email]<mailto:[hidden email]>>
>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>To: "[hidden email]<mailto:[hidden email]>" <asset-
>>[hidden email]<mailto:[hidden email]>>
>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>(UNCLASSIFIED)
>>
>>This is something that has to be address in CCE.  I do not agree that it
>>was
>>intended to be a human-readable format for the long term. That is where
>>is
>>stands today because of inadequacies in how we deal with a CCE entry that
>>need to be further specified, but for the sake of it's usability and
>>viability, it
>>needs to be machine readable.
>>
>>Kent Landfield
>>Director Content Strategy, Architecture and Standards
>>
>>McAfee, Inc.
>>5000 Headquarters Dr.
>>Plano, Texas 75024
>>
>>Direct: +1.972.963.7096
>>Mobile: [phone]
>>Web: www.mcafee.com<http://www.mcafee.com/>
>>
>>From: "Davidson II, Mark S"
>><[hidden email]<mailto:[hidden email]>>
>>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>>[hidden email]<mailto:[hidden email]>>
>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>To: Multiple recipients of list <[hidden email]<mailto:asset-
>>[hidden email]>>
>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>(UNCLASSIFIED)
>>
>>CCE is intended to be a human-readable format, not a machine readable
>>format. For that reason, I think it will be difficult if not infeasible
>>to
>>discern CCE metadata in a programmatic way.
>>
>>Relevant snippet for context:
>><asr:metadata>
>><asrm:cce_metadata>
>><asrm:param_state>disabled</asrm:param_state>
>><asrm:param_setting param="roles">
>><asrm:setting>admin</asrm:setting>
>><asrm:setting>user</asrm:setting>
>></asrm:param_setting>
>></asrm:cce_metadata>
>></asr:metadata>
>>I think it will be difficult to fill the CCE param_state/param_setting
>>for
>>the following reasons:
>>1) There is not a machine-readable mapping from CCE to CCE parameters
>>2) There is not a machine-readable mapping from CCE parameters to actual
>>values (IE, enabled=0, disabled=1, etc)
>>3) There is not a machine-readable mapping from CCE to method for
>>collecting
>>the value (technical mechanism)
>>
>>I think if you had the data to communicate, this structure would
>>accommodate
>>that data effectively. I'm not sure how we will actually get the data to
>>populate this structure.
>>
>>-Mark
>>
>>-----Original Message-----
>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>[hidden email]] On Behalf Of WOLFKIEL,
>>JOSEPH L CIV DISA PEO-MA
>>Sent: Thursday, August 11, 2011 10:21 AM
>>To: Multiple recipients of list
>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>(UNCLASSIFIED)
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>>
>>I can't think of a better alternative.  Not sure how well we will be
>>able to
>>use this, but it appears to meet the need.  I'm worried about the lack of
>>structure.  Can we specify schemas for the known types of metadata (the
>>CCE,
>>specifically)?  I'm also concerned that the CCE structure doesn't really
>>help a tool automate the translation of checks into structured results.
>>
>>Looking at the schemas & documents themselves, I can't figure out why
>>you've
>>structured the documents the way you have.  If all idents in a report
>>are in
>>the same system, you should only have to specify the system once at the
>>beginning, it doesn't make sense to re-specify the system for each result
>>value set.  For results against a common ident, the results should be
>>subordinate elements with relevant group-by attributes.
>>
>>Joseph L. Wolfkiel
>>Engineering Group Lead
>>DISA PEO MA/IA52
>>[phone]
>>[hidden email]<mailto:[hidden email]>
>>
>>
>>-----Original Message-----
>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>[hidden email]] On Behalf Of
>>Halbardier, Adam
>>Sent: Monday, August 08, 2011 1:46 PM
>>To: Multiple recipients of list
>>Subject: Follow-up from Last Call about Capturing CCE Info
>>
>>All,
>>
>>
>>On the last call we discussed the difficulty with reporting against CCEs
>>separate from the XCCDF benchmark and profile that checked the CCE.  I
>>took
>>an action to look at CCE and try to come up with a mechanism that could
>>possibly support such a case.  Attached is a possible solution.
>>Basically,
>>I added a "metadata" construct to the result element that can capture
>>arbitrary metadata about the setting of an ident.  For simpler idents, we
>>just capture the relevant information as parameters on the result (see
>>the
>>CPE example).  For the CCE example, we can use the metadata element to
>>capture the CCE settings.  I attached an extension schema for the CCE
>>metadata.  Basically, a CCE has one or more parameters.  Scanning through
>>the CCE spreadsheets, I think there are two categories of parameters.
>>One
>>category is what I'm calling "state" parameters.  Those are parameters
>>that
>>just have a value, without a name associated with the parameter (e.g.,
>>"enabled/disabled").  For the first !
>>category, the name of the parameter is the setting.  The second category
>>of
>>parameters is a named parameter that has a value, or list of values,
>>associated with it (e.g., user roles).  In this case, the parameter
>>needs to
>>be identified, along with the value or list of values for the instance of
>>the CCE.  The second category I called "setting param".
>>
>>
>>A CCE metadata construct can have one or more of each of the two types of
>>parameters.  The parameters MUST be provided in the same order as
>>documented
>>in the CCE.  The one potential disconnect here is that the values for
>>"setting params" isn't enumerated (and I don't think it can be), so that
>>could lead to data disconnects, but it might be a limitation we just
>>have to
>>live with in the near-term.  Please provide thought/feedback on this
>>approach, and if you think it will solve the current needs.
>>
>>
>>-Adam
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>>
>>Classification:  UNCLASSIFIED
>>Caveats: NONE
>

[Mann, Dave]

>From: Adam Montville [mailto:[hidden email]]
>At the time, helping human analysts correlate was the requirement.  I
>believe now this has changed somewhat.  I would like to see the industry
>move in a direction that permits very complicated correlations in an
>automated manner.  As we mature beyond the C&A-motivated capabilities of
>asset, configuration, and vulnerability management into supporting
>specific security processes (I.e. Event correlation), we are going to be
>serving much different needs.

I can totally understand this desire and aspiration.

My sense is that we (the configuration audit/management) community are facing a very thorny problem though - one whose economic and human process problems are just as hard as the technical ones and the technical ones are way hard.

The core issue as I see it is how do you instrument a platform and then generate, expose and share executable content against that instrumentation in a way that is a) economically feasible and b) meaningful to the configuration audit community?

Languages (e.g. like OVAL) are certainly needed but they aren't sufficient.  Check logic needs to be written, or generated.   Some suggest that OS/application vendors should generate this content but others have noted the lack of economic incentives.

To further complicate this, our use case analysis (both for CCE and other related efforts) has repeatedly and consistently shown that software vendors think of "configuration issues" in very different terms than the configuration audit/management community does.  So, there's the strong possibility for the "be careful what you wish for" problem.  Machine consumable content that is auto-generated by a process that is centered more on feature & code-base management may not be useful for configuration audit.

Another consideration... I don't see large scale automated configuration audit content provisioning happening until the content itself is largely auto-generated from other data stores.

As many of you know, I'm a nut about vintage bicycles.  I ride a 1979 Trek.  It was handmade in a barn in Madison, WI and many of the early Trek workers went on to notable careers as custom hand-made bike builders.  In fact, they had to find other work because by 1989, Trek bikes were pretty much all produced by precision robotics.  As much of a fan of hand-made bikes as I am, Trek's move to automation allowed them to become an industry giant.

I think configuration content at the level you're talking about will need to be auto-created, at least to some degree.


Dave Mann wrote:
>>3) Since the issue of CCE's future has been raised, my sense is that the
>>important success goals for CCE's near to mid-term progress include:
>>+ Broader coverage of security guides and audit tool issues by CCE.

Adam wrote:
>I'm wondering if this isn't too narrow a focus.  This relegates CCE to
>security-specific settings, and it's clear that this industry is coming to
>the realization that security-specific processes really support IT
>processes, and that IT processes encompass more than security-specific
>settings.

In terms of vision, it is too narrow and that has been CCE's position since the beginning.

But, in terms of current realities it remains something of a stretch goal for us.  We aren't close to hitting that goal yet.

Even if we drop the hopes for machine readable content related to CCEs and just stick with CCE's as currently defined, broadening the scope beyond what is captured in security guides and config audit tools will require that we auto-generate CCE data.  This turns out to be pretty hard.

As many of you know, Microsoft has been working with the CCE team to auto-generate CCE candidates.  We've had some wonderful initial successes along with the expected hiccups.  IMO, they're to be commended for working on this as hard as they have. They are certainly well out in front of anybody else in this regard.

One of the issues that we've encountered (and I must emphasize this, we've seen this with every single OS/App vendor we've worked with) is that their internal data is fundamentally different from what is codified in CCE. There are significant tensions around level of abstraction issues for instance.  Software manufacturing is different from configuration management and this is to be expected and I in no way fault Microsoft or any other software vendor for it.

So, let me toss out a challenge to my friends in the configuration audit/management space?

Would your company be willing to work with us to attempt to auto-generate CCE candidates from your internal configuration audit/management repositories?


-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:[hidden email] | cell:781.424.6003
==================================================================

>
>>CCE was founded on 5 documented use cases as discussed in section 4 of
>>the CCE overview paper [1].  In all 5 of the scenarios, the correlation
>>is done by humans, even the 4th use case in which results from multiple
>>audit tools are integrated.
>
>This is an excellent point.  I can see a future, however, where more use
>cases are added, based on the inclusion of other processes.  Consider a
>SIEM tool that detects five failed logon attempts over an hour's time
>followed by a good logon.  Traditionally, we would rely on a human to go
>figure out whether that incident is benign.  With configuration data,
>however, we could bolster that correlation to trigger only when particular
>configuration items are set in a particular way, if a configuration item
>subsequently changed, and so on.
>
>This is a problem not just limited to CCE, I think.  I'd also like to see
>things like: Tell me whether that user recently changed their password,
>because if they did, then the probability that this incident is benign
>just went up.
>
>>
>>2) If there is a clear and compelling need for machine processable
>>information regarding configuration controls that is not being met by
>>other current efforts [2], the following questions should be worked
>>through:
>>+ What use cases should it support?
>
>This is probably the first question to answer, but I assert that to answer
>this question properly we need to identify the processes we would intend
>to support.  This is something that seems to be "common knowledge" in the
>community, but that is rarely called out explicitly.
>
>>+ Who will create the content?
>>+ Who will be the guarantor of the quality of that content?
>>+ Should this be a government funded effort, "open source" or a
>>commercial venture?
>>
>>We're happy to have that discussion unfold here on this list, even if the
>>end result isn't (and shouldn't be) a part of CCE.
>>
>
>>+ A content management and provisioning system capable of scaling to this
>>scope
>>+ A formalized adoption program (similar to CVE's) that defines industry
>>best practices for the inclusion of CCE ids into configuration management
>>tools and services.
>>+ More ubiquitous usage of CCE ids in configuration management tools and
>>services.
>>
>>
>>Just to reiterate point 2)... Please feel free to continue the discussion
>>here.  It's an important issue and needs to be discussed.
>
>This is good.  I don't know if CCE is the right place for what we think we
>need at this point, but it's certainly related.
>
>>
>>
>>[1] -
>>http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_2
>008.p
>>df
>>
>>[2] - If OVAL is sufficient to meet the use cases (unknowable till the
>>use cases are defined), we note that both NIST SCAP/FDCC and MITRE's
>OVAL
>>Repository provide sets of machine processable checks.  The first is
>>funded by the US Government and the latter is more of an open source
>>effort (and traditionally, more focused on vulnerabilities than
>>configuration controls).
>>
>>-Dave
>>==================================================================
>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>------------------------------------------------------------------
>>e-mail:[hidden email] | cell:781.424.6003
>>==================================================================
>>
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:owner-cce-
>>>[hidden email]] On Behalf Of
>>>[hidden email]
>>>Sent: Thursday, August 11, 2011 11:28 AM
>>>To: cce-working-group-list
>>>Subject: Capturing CCE Info
>>>
>>>This is a discussion occurring on the asset-dev working group that really
>>>needs to be addressed here.
>>>
>>>This effort has been one of maturing and evolving.  We struggled with the
>>>right level to assign CCEs and got past that hurdle.  We moved from v4
>>>to v5
>>>to add the Luhn check digit.  Now we need to make it   usable for other
>>>efforts to really use it appropriately.
>>>
>>>Thoughts on making this useful from a programmatic perspective for other
>>>efforts to benefit from?
>>>
>>>Kent Landfield
>>>Director Content Strategy, Architecture and Standards
>>>
>>>McAfee, Inc.
>>>5000 Headquarters Dr.
>>>Plano, Texas 75024
>>>
>>>Direct: +1.972.963.7096
>>>Mobile: [phone]
>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>
>>>From: Kent Landfield
>>><[hidden email]<mailto:[hidden email]>>
>>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>>To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>[hidden email]<mailto:[hidden email]>>
>>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>>(UNCLASSIFIED)
>>>
>>>This is something that has to be address in CCE.  I do not agree that it
>>>was
>>>intended to be a human-readable format for the long term. That is where
>>>is
>>>stands today because of inadequacies in how we deal with a CCE entry that
>>>need to be further specified, but for the sake of it's usability and
>>>viability, it
>>>needs to be machine readable.
>>>
>>>Kent Landfield
>>>Director Content Strategy, Architecture and Standards
>>>
>>>McAfee, Inc.
>>>5000 Headquarters Dr.
>>>Plano, Texas 75024
>>>
>>>Direct: +1.972.963.7096
>>>Mobile: [phone]
>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>
>>>From: "Davidson II, Mark S"
>>><[hidden email]<mailto:[hidden email]>>
>>>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>[hidden email]<mailto:[hidden email]>>
>>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>>To: Multiple recipients of list <[hidden email]<mailto:asset-
>>>[hidden email]>>
>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>(UNCLASSIFIED)
>>>
>>>CCE is intended to be a human-readable format, not a machine readable
>>>format. For that reason, I think it will be difficult if not infeasible
>>>to
>>>discern CCE metadata in a programmatic way.
>>>
>>>Relevant snippet for context:
>>><asr:metadata>
>>><asrm:cce_metadata>
>>><asrm:param_state>disabled</asrm:param_state>
>>><asrm:param_setting param="roles">
>>><asrm:setting>admin</asrm:setting>
>>><asrm:setting>user</asrm:setting>
>>></asrm:param_setting>
>>></asrm:cce_metadata>
>>></asr:metadata>
>>>I think it will be difficult to fill the CCE param_state/param_setting
>>>for
>>>the following reasons:
>>>1) There is not a machine-readable mapping from CCE to CCE parameters
>>>2) There is not a machine-readable mapping from CCE parameters to actual
>>>values (IE, enabled=0, disabled=1, etc)
>>>3) There is not a machine-readable mapping from CCE to method for
>>>collecting
>>>the value (technical mechanism)
>>>
>>>I think if you had the data to communicate, this structure would
>>>accommodate
>>>that data effectively. I'm not sure how we will actually get the data to
>>>populate this structure.
>>>
>>>-Mark
>>>
>>>-----Original Message-----
>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>[hidden email]] On Behalf Of WOLFKIEL,
>>>JOSEPH L CIV DISA PEO-MA
>>>Sent: Thursday, August 11, 2011 10:21 AM
>>>To: Multiple recipients of list
>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>(UNCLASSIFIED)
>>>
>>>Classification:  UNCLASSIFIED
>>>Caveats: NONE
>>>
>>>Classification:  UNCLASSIFIED
>>>Caveats: NONE
>>>
>>>I can't think of a better alternative.  Not sure how well we will be
>>>able to
>>>use this, but it appears to meet the need.  I'm worried about the lack of
>>>structure.  Can we specify schemas for the known types of metadata (the
>>>CCE,
>>>specifically)?  I'm also concerned that the CCE structure doesn't really
>>>help a tool automate the translation of checks into structured results.
>>>
>>>Looking at the schemas & documents themselves, I can't figure out why
>>>you've
>>>structured the documents the way you have.  If all idents in a report
>>>are in
>>>the same system, you should only have to specify the system once at the
>>>beginning, it doesn't make sense to re-specify the system for each result
>>>value set.  For results against a common ident, the results should be
>>>subordinate elements with relevant group-by attributes.
>>>
>>>Joseph L. Wolfkiel
>>>Engineering Group Lead
>>>DISA PEO MA/IA52
>>>[phone]
>>>[hidden email]<mailto:[hidden email]>
>>>
>>>
>>>-----Original Message-----
>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>[hidden email]] On Behalf Of
>>>Halbardier, Adam
>>>Sent: Monday, August 08, 2011 1:46 PM
>>>To: Multiple recipients of list
>>>Subject: Follow-up from Last Call about Capturing CCE Info
>>>
>>>All,
>>>
>>>
>>>On the last call we discussed the difficulty with reporting against CCEs
>>>separate from the XCCDF benchmark and profile that checked the CCE.  I
>>>took
>>>an action to look at CCE and try to come up with a mechanism that could
>>>possibly support such a case.  Attached is a possible solution.
>>>Basically,
>>>I added a "metadata" construct to the result element that can capture
>>>arbitrary metadata about the setting of an ident.  For simpler idents, we
>>>just capture the relevant information as parameters on the result (see
>>>the
>>>CPE example).  For the CCE example, we can use the metadata element to
>>>capture the CCE settings.  I attached an extension schema for the CCE
>>>metadata.  Basically, a CCE has one or more parameters.  Scanning through
>>>the CCE spreadsheets, I think there are two categories of parameters.
>>>One
>>>category is what I'm calling "state" parameters.  Those are parameters
>>>that
>>>just have a value, without a name associated with the parameter (e.g.,
>>>"enabled/disabled").  For the first !
>>>category, the name of the parameter is the setting.  The second category
>>>of
>>>parameters is a named parameter that has a value, or list of values,
>>>associated with it (e.g., user roles).  In this case, the parameter
>>>needs to
>>>be identified, along with the value or list of values for the instance of
>>>the CCE.  The second category I called "setting param".
>>>
>>>
>>>A CCE metadata construct can have one or more of each of the two types of
>>>parameters.  The parameters MUST be provided in the same order as
>>>documented
>>>in the CCE.  The one potential disconnect here is that the values for
>>>"setting params" isn't enumerated (and I don't think it can be), so that
>>>could lead to data disconnects, but it might be a limitation we just
>>>have to
>>>live with in the near-term.  Please provide thought/feedback on this
>>>approach, and if you think it will solve the current needs.
>>>
>>>
>>>-Adam
>>>
>>>Classification:  UNCLASSIFIED
>>>Caveats: NONE
>>>
>>>Classification:  UNCLASSIFIED
>>>Caveats: NONE
>>
>

[Adam Montville]

On 8/19/11 1:07 PM, "Mann, Dave" <[hidden email]> wrote:

>>From: Adam Montville [mailto:[hidden email]]
>>At the time, helping human analysts correlate was the requirement.  I
>>believe now this has changed somewhat.  I would like to see the industry
>>move in a direction that permits very complicated correlations in an
>>automated manner.  As we mature beyond the C&A-motivated capabilities of
>>asset, configuration, and vulnerability management into supporting
>>specific security processes (I.e. Event correlation), we are going to be
>>serving much different needs.
>
>I can totally understand this desire and aspiration.
>
>My sense is that we (the configuration audit/management) community are
>facing a very thorny problem though - one whose economic and human
>process problems are just as hard as the technical ones and the technical
>ones are way hard.
>
>The core issue as I see it is how do you instrument a platform and then
>generate, expose and share executable content against that
>instrumentation in a way that is a) economically feasible and b)
>meaningful to the configuration audit community?

I would really like to see us expand from this limitation to the
configuration audit community. Incident handlers, for example, may also
find CCE useful.

>
>Languages (e.g. like OVAL) are certainly needed but they aren't
>sufficient.  Check logic needs to be written, or generated.   Some
>suggest that OS/application vendors should generate this content but
>others have noted the lack of economic incentives.
>
>To further complicate this, our use case analysis (both for CCE and other
>related efforts) has repeatedly and consistently shown that software
>vendors think of "configuration issues" in very different terms than the
>configuration audit/management community does.  So, there's the strong
>possibility for the "be careful what you wish for" problem.  Machine
>consumable content that is auto-generated by a process that is centered
>more on feature & code-base management may not be useful for
>configuration audit.

Yes, we should be careful what we wish for, but right now I feel that
we're at a point of flushing out some important semantic differences.
Consider a world in which CCE, the specification, is used outside just the
security context.  Would we still call it CCE?

Also, my argument here is that, especially for incident response
capabilities, understanding configuration issues from the software
vendors' point of view is, perhaps, as important as viewing configuration
issues in the security context (in fact, when investigating an incident,
aren't all "configuration issues" security-related?).

>
>Another consideration... I don't see large scale automated configuration
>audit content provisioning happening until the content itself is largely
>auto-generated from other data stores.

This is an important point to make and to be heard.

>
>As many of you know, I'm a nut about vintage bicycles.  I ride a 1979
>Trek.  It was handmade in a barn in Madison, WI and many of the early
>Trek workers went on to notable careers as custom hand-made bike
>builders.  In fact, they had to find other work because by 1989, Trek
>bikes were pretty much all produced by precision robotics.  As much of a
>fan of hand-made bikes as I am, Trek's move to automation allowed them to
>become an industry giant.
>
>I think configuration content at the level you're talking about will need
>to be auto-created, at least to some degree.

I agree.  We're at the point where we ought to be considering how this can
happen.

>
>
>Dave Mann wrote:
>>>3) Since the issue of CCE's future has been raised, my sense is that the
>>>important success goals for CCE's near to mid-term progress include:
>>>+ Broader coverage of security guides and audit tool issues by CCE.
>
>Adam wrote:
>>I'm wondering if this isn't too narrow a focus.  This relegates CCE to
>>security-specific settings, and it's clear that this industry is coming
>>to
>>the realization that security-specific processes really support IT
>>processes, and that IT processes encompass more than security-specific
>>settings.
>
>In terms of vision, it is too narrow and that has been CCE's position
>since the beginning.
>
>But, in terms of current realities it remains something of a stretch goal
>for us.  We aren't close to hitting that goal yet.
>
>Even if we drop the hopes for machine readable content related to CCEs
>and just stick with CCE's as currently defined, broadening the scope
>beyond what is captured in security guides and config audit tools will
>require that we auto-generate CCE data.  This turns out to be pretty hard.
>
>As many of you know, Microsoft has been working with the CCE team to
>auto-generate CCE candidates.  We've had some wonderful initial successes
>along with the expected hiccups.  IMO, they're to be commended for
>working on this as hard as they have. They are certainly well out in
>front of anybody else in this regard.

I didn't realize this is ongoing work.  Happy to hear it.

>
>One of the issues that we've encountered (and I must emphasize this,
>we've seen this with every single OS/App vendor we've worked with) is
>that their internal data is fundamentally different from what is codified
>in CCE. There are significant tensions around level of abstraction issues
>for instance.  Software manufacturing is different from configuration
>management and this is to be expected and I in no way fault Microsoft or
>any other software vendor for it.

So, perhaps this is another point of evidence to substantiate an assertion
that we're at a place where we need to consider the two as separate, but
related definitions.  I'm not sure of the "right" answer - there are
likely many ways to figure this out.

>
>So, let me toss out a challenge to my friends in the configuration
>audit/management space?
>
>Would your company be willing to work with us to attempt to auto-generate
>CCE candidates from your internal configuration audit/management
>repositories?

I hope the answer is yes from many.

>
>
>-Dave
>==================================================================
>David Mann | Principal Infosec Scientist | The MITRE Corporation
>------------------------------------------------------------------
>e-mail:[hidden email] | cell:781.424.6003
>==================================================================
>
>
>
>>
>>>CCE was founded on 5 documented use cases as discussed in section 4 of
>>>the CCE overview paper [1].  In all 5 of the scenarios, the correlation
>>>is done by humans, even the 4th use case in which results from multiple
>>>audit tools are integrated.
>>
>>This is an excellent point.  I can see a future, however, where more use
>>cases are added, based on the inclusion of other processes.  Consider a
>>SIEM tool that detects five failed logon attempts over an hour's time
>>followed by a good logon.  Traditionally, we would rely on a human to go
>>figure out whether that incident is benign.  With configuration data,
>>however, we could bolster that correlation to trigger only when
>>particular
>>configuration items are set in a particular way, if a configuration item
>>subsequently changed, and so on.
>>
>>This is a problem not just limited to CCE, I think.  I'd also like to see
>>things like: Tell me whether that user recently changed their password,
>>because if they did, then the probability that this incident is benign
>>just went up.
>>
>>>
>>>2) If there is a clear and compelling need for machine processable
>>>information regarding configuration controls that is not being met by
>>>other current efforts [2], the following questions should be worked
>>>through:
>>>+ What use cases should it support?
>>
>>This is probably the first question to answer, but I assert that to
>>answer
>>this question properly we need to identify the processes we would intend
>>to support.  This is something that seems to be "common knowledge" in the
>>community, but that is rarely called out explicitly.
>>
>>>+ Who will create the content?
>>>+ Who will be the guarantor of the quality of that content?
>>>+ Should this be a government funded effort, "open source" or a
>>>commercial venture?
>>>
>>>We're happy to have that discussion unfold here on this list, even if
>>>the
>>>end result isn't (and shouldn't be) a part of CCE.
>>>
>>
>>>+ A content management and provisioning system capable of scaling to
>>>this
>>>scope
>>>+ A formalized adoption program (similar to CVE's) that defines industry
>>>best practices for the inclusion of CCE ids into configuration
>>>management
>>>tools and services.
>>>+ More ubiquitous usage of CCE ids in configuration management tools and
>>>services.
>>>
>>>
>>>Just to reiterate point 2)... Please feel free to continue the
>>>discussion
>>>here.  It's an important issue and needs to be discussed.
>>
>>This is good.  I don't know if CCE is the right place for what we think
>>we
>>need at this point, but it's certainly related.
>>
>>>
>>>
>>>[1] -
>>>http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_2
>>008.p
>>>df
>>>
>>>[2] - If OVAL is sufficient to meet the use cases (unknowable till the
>>>use cases are defined), we note that both NIST SCAP/FDCC and MITRE's
>>OVAL
>>>Repository provide sets of machine processable checks.  The first is
>>>funded by the US Government and the latter is more of an open source
>>>effort (and traditionally, more focused on vulnerabilities than
>>>configuration controls).
>>>
>>>-Dave
>>>==================================================================
>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>------------------------------------------------------------------
>>>e-mail:[hidden email] | cell:781.424.6003
>>>==================================================================
>>>
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:owner-cce-
>>>>[hidden email]] On Behalf Of
>>>>[hidden email]
>>>>Sent: Thursday, August 11, 2011 11:28 AM
>>>>To: cce-working-group-list
>>>>Subject: Capturing CCE Info
>>>>
>>>>This is a discussion occurring on the asset-dev working group that
>>>>really
>>>>needs to be addressed here.
>>>>
>>>>This effort has been one of maturing and evolving.  We struggled with
>>>>the
>>>>right level to assign CCEs and got past that hurdle.  We moved from v4
>>>>to v5
>>>>to add the Luhn check digit.  Now we need to make it   usable for other
>>>>efforts to really use it appropriately.
>>>>
>>>>Thoughts on making this useful from a programmatic perspective for
>>>>other
>>>>efforts to benefit from?
>>>>
>>>>Kent Landfield
>>>>Director Content Strategy, Architecture and Standards
>>>>
>>>>McAfee, Inc.
>>>>5000 Headquarters Dr.
>>>>Plano, Texas 75024
>>>>
>>>>Direct: +1.972.963.7096
>>>>Mobile: [phone]
>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>
>>>>From: Kent Landfield
>>>><[hidden email]<mailto:[hidden email]>>
>>>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>>>To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>[hidden email]<mailto:[hidden email]>>
>>>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>>>(UNCLASSIFIED)
>>>>
>>>>This is something that has to be address in CCE.  I do not agree that
>>>>it
>>>>was
>>>>intended to be a human-readable format for the long term. That is where
>>>>is
>>>>stands today because of inadequacies in how we deal with a CCE entry
>>>>that
>>>>need to be further specified, but for the sake of it's usability and
>>>>viability, it
>>>>needs to be machine readable.
>>>>
>>>>Kent Landfield
>>>>Director Content Strategy, Architecture and Standards
>>>>
>>>>McAfee, Inc.
>>>>5000 Headquarters Dr.
>>>>Plano, Texas 75024
>>>>
>>>>Direct: +1.972.963.7096
>>>>Mobile: [phone]
>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>
>>>>From: "Davidson II, Mark S"
>>>><[hidden email]<mailto:[hidden email]>>
>>>>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>[hidden email]<mailto:[hidden email]>>
>>>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>>>To: Multiple recipients of list <[hidden email]<mailto:asset-
>>>>[hidden email]>>
>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>(UNCLASSIFIED)
>>>>
>>>>CCE is intended to be a human-readable format, not a machine readable
>>>>format. For that reason, I think it will be difficult if not infeasible
>>>>to
>>>>discern CCE metadata in a programmatic way.
>>>>
>>>>Relevant snippet for context:
>>>><asr:metadata>
>>>><asrm:cce_metadata>
>>>><asrm:param_state>disabled</asrm:param_state>
>>>><asrm:param_setting param="roles">
>>>><asrm:setting>admin</asrm:setting>
>>>><asrm:setting>user</asrm:setting>
>>>></asrm:param_setting>
>>>></asrm:cce_metadata>
>>>></asr:metadata>
>>>>I think it will be difficult to fill the CCE param_state/param_setting
>>>>for
>>>>the following reasons:
>>>>1) There is not a machine-readable mapping from CCE to CCE parameters
>>>>2) There is not a machine-readable mapping from CCE parameters to
>>>>actual
>>>>values (IE, enabled=0, disabled=1, etc)
>>>>3) There is not a machine-readable mapping from CCE to method for
>>>>collecting
>>>>the value (technical mechanism)
>>>>
>>>>I think if you had the data to communicate, this structure would
>>>>accommodate
>>>>that data effectively. I'm not sure how we will actually get the data
>>>>to
>>>>populate this structure.
>>>>
>>>>-Mark
>>>>
>>>>-----Original Message-----
>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>[hidden email]] On Behalf Of WOLFKIEL,
>>>>JOSEPH L CIV DISA PEO-MA
>>>>Sent: Thursday, August 11, 2011 10:21 AM
>>>>To: Multiple recipients of list
>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>(UNCLASSIFIED)
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>>
>>>>I can't think of a better alternative.  Not sure how well we will be
>>>>able to
>>>>use this, but it appears to meet the need.  I'm worried about the lack
>>>>of
>>>>structure.  Can we specify schemas for the known types of metadata (the
>>>>CCE,
>>>>specifically)?  I'm also concerned that the CCE structure doesn't
>>>>really
>>>>help a tool automate the translation of checks into structured results.
>>>>
>>>>Looking at the schemas & documents themselves, I can't figure out why
>>>>you've
>>>>structured the documents the way you have.  If all idents in a report
>>>>are in
>>>>the same system, you should only have to specify the system once at the
>>>>beginning, it doesn't make sense to re-specify the system for each
>>>>result
>>>>value set.  For results against a common ident, the results should be
>>>>subordinate elements with relevant group-by attributes.
>>>>
>>>>Joseph L. Wolfkiel
>>>>Engineering Group Lead
>>>>DISA PEO MA/IA52
>>>>[phone]
>>>>[hidden email]<mailto:[hidden email]>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>[hidden email]] On Behalf Of
>>>>Halbardier, Adam
>>>>Sent: Monday, August 08, 2011 1:46 PM
>>>>To: Multiple recipients of list
>>>>Subject: Follow-up from Last Call about Capturing CCE Info
>>>>
>>>>All,
>>>>
>>>>
>>>>On the last call we discussed the difficulty with reporting against
>>>>CCEs
>>>>separate from the XCCDF benchmark and profile that checked the CCE.  I
>>>>took
>>>>an action to look at CCE and try to come up with a mechanism that could
>>>>possibly support such a case.  Attached is a possible solution.
>>>>Basically,
>>>>I added a "metadata" construct to the result element that can capture
>>>>arbitrary metadata about the setting of an ident.  For simpler idents,
>>>>we
>>>>just capture the relevant information as parameters on the result (see
>>>>the
>>>>CPE example).  For the CCE example, we can use the metadata element to
>>>>capture the CCE settings.  I attached an extension schema for the CCE
>>>>metadata.  Basically, a CCE has one or more parameters.  Scanning
>>>>through
>>>>the CCE spreadsheets, I think there are two categories of parameters.
>>>>One
>>>>category is what I'm calling "state" parameters.  Those are parameters
>>>>that
>>>>just have a value, without a name associated with the parameter (e.g.,
>>>>"enabled/disabled").  For the first !
>>>>category, the name of the parameter is the setting.  The second
>>>>category
>>>>of
>>>>parameters is a named parameter that has a value, or list of values,
>>>>associated with it (e.g., user roles).  In this case, the parameter
>>>>needs to
>>>>be identified, along with the value or list of values for the instance
>>>>of
>>>>the CCE.  The second category I called "setting param".
>>>>
>>>>
>>>>A CCE metadata construct can have one or more of each of the two types
>>>>of
>>>>parameters.  The parameters MUST be provided in the same order as
>>>>documented
>>>>in the CCE.  The one potential disconnect here is that the values for
>>>>"setting params" isn't enumerated (and I don't think it can be), so
>>>>that
>>>>could lead to data disconnects, but it might be a limitation we just
>>>>have to
>>>>live with in the near-term.  Please provide thought/feedback on this
>>>>approach, and if you think it will solve the current needs.
>>>>
>>>>
>>>>-Adam
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>
>>
>

[Tim Keanini]

At the core of this discussion is simply the question: How does a CCE
come in to being?  
This is ontogenesis.  http://en.wikipedia.org/wiki/Ontogeny
It is the only way to get complex systems to stabilize.  

Picture a control panel with two knobs: one labeled social, the other
labeled technical :-)
As we turn up the technical knob and are success, we may wash out some
of the inconsistency and slowness with the social but never will the
social ever reach zero unless we are dealing with a world model that is
too complex for human understanding all together.  
With CCE, we are dealing with a parameters space far more vast than we
care or even should care about understanding so it then becomes a game
of being able to make socially stable those "parameters of interest" so
that we can automate our ability to witness them.    This is what the
checklist programs have done so far.  Mind you, sometimes this social
understanding cannot be made stable and if this is true, the benefits of
the technical will be limited to fragmented communities as they have
been for years now.

Yes, I have had too much coffee this morning.
--tk

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Adam
Montville
Sent: Monday, August 22, 2011 8:31 AM
To: Mann, Dave; [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info

On 8/19/11 1:07 PM, "Mann, Dave" <[hidden email]> wrote:

>>From: Adam Montville [mailto:[hidden email]] At the time,
>>helping human analysts correlate was the requirement.  I believe now
>>this has changed somewhat.  I would like to see the industry move in a

>>direction that permits very complicated correlations in an automated
>>manner.  As we mature beyond the C&A-motivated capabilities of asset,
>>configuration, and vulnerability management into supporting specific
>>security processes (I.e. Event correlation), we are going to be
>>serving much different needs.
>
>I can totally understand this desire and aspiration.
>
>My sense is that we (the configuration audit/management) community are
>facing a very thorny problem though - one whose economic and human
>process problems are just as hard as the technical ones and the
>technical ones are way hard.
>
>The core issue as I see it is how do you instrument a platform and then

>generate, expose and share executable content against that
>instrumentation in a way that is a) economically feasible and b)
>meaningful to the configuration audit community?

I would really like to see us expand from this limitation to the
configuration audit community. Incident handlers, for example, may also
find CCE useful.

>
>Languages (e.g. like OVAL) are certainly needed but they aren't
>sufficient.  Check logic needs to be written, or generated.   Some
>suggest that OS/application vendors should generate this content but
>others have noted the lack of economic incentives.
>
>To further complicate this, our use case analysis (both for CCE and
>other related efforts) has repeatedly and consistently shown that
>software vendors think of "configuration issues" in very different
>terms than the configuration audit/management community does.  So,
>there's the strong possibility for the "be careful what you wish for"
>problem.  Machine consumable content that is auto-generated by a
>process that is centered more on feature & code-base management may not

>be useful for configuration audit.

Yes, we should be careful what we wish for, but right now I feel that
we're at a point of flushing out some important semantic differences.
Consider a world in which CCE, the specification, is used outside just
the security context.  Would we still call it CCE?

Also, my argument here is that, especially for incident response
capabilities, understanding configuration issues from the software
vendors' point of view is, perhaps, as important as viewing
configuration issues in the security context (in fact, when
investigating an incident, aren't all "configuration issues"
security-related?).

>
>Another consideration... I don't see large scale automated
>configuration audit content provisioning happening until the content
>itself is largely auto-generated from other data stores.

This is an important point to make and to be heard.

>
>As many of you know, I'm a nut about vintage bicycles.  I ride a 1979
>Trek.  It was handmade in a barn in Madison, WI and many of the early
>Trek workers went on to notable careers as custom hand-made bike
>builders.  In fact, they had to find other work because by 1989, Trek
>bikes were pretty much all produced by precision robotics.  As much of
>a fan of hand-made bikes as I am, Trek's move to automation allowed
>them to become an industry giant.
>
>I think configuration content at the level you're talking about will
>need to be auto-created, at least to some degree.

I agree.  We're at the point where we ought to be considering how this
can happen.

>
>
>Dave Mann wrote:
>>>3) Since the issue of CCE's future has been raised, my sense is that
>>>the important success goals for CCE's near to mid-term progress
include:
>>>+ Broader coverage of security guides and audit tool issues by CCE.
>
>Adam wrote:
>>I'm wondering if this isn't too narrow a focus.  This relegates CCE to

>>security-specific settings, and it's clear that this industry is
>>coming to the realization that security-specific processes really
>>support IT processes, and that IT processes encompass more than
>>security-specific settings.
>
>In terms of vision, it is too narrow and that has been CCE's position
>since the beginning.
>
>But, in terms of current realities it remains something of a stretch
>goal for us.  We aren't close to hitting that goal yet.
>
>Even if we drop the hopes for machine readable content related to CCEs
>and just stick with CCE's as currently defined, broadening the scope
>beyond what is captured in security guides and config audit tools will
>require that we auto-generate CCE data.  This turns out to be pretty

hard.
>
>As many of you know, Microsoft has been working with the CCE team to
>auto-generate CCE candidates.  We've had some wonderful initial
>successes along with the expected hiccups.  IMO, they're to be
>commended for working on this as hard as they have. They are certainly
>well out in front of anybody else in this regard.

I didn't realize this is ongoing work.  Happy to hear it.

>
>One of the issues that we've encountered (and I must emphasize this,
>we've seen this with every single OS/App vendor we've worked with) is
>that their internal data is fundamentally different from what is
>codified in CCE. There are significant tensions around level of
>abstraction issues for instance.  Software manufacturing is different
>from configuration management and this is to be expected and I in no
>way fault Microsoft or any other software vendor for it.

So, perhaps this is another point of evidence to substantiate an
assertion that we're at a place where we need to consider the two as
separate, but related definitions.  I'm not sure of the "right" answer -
there are likely many ways to figure this out.

>
>So, let me toss out a challenge to my friends in the configuration
>audit/management space?
>
>Would your company be willing to work with us to attempt to
>auto-generate CCE candidates from your internal configuration
>audit/management repositories?

I hope the answer is yes from many.

>
>
>-Dave
>==================================================================
>David Mann | Principal Infosec Scientist | The MITRE Corporation
>------------------------------------------------------------------
>e-mail:[hidden email] | cell:781.424.6003
>==================================================================
>
>
>
>>
>>>CCE was founded on 5 documented use cases as discussed in section 4
>>>of the CCE overview paper [1].  In all 5 of the scenarios, the
>>>correlation is done by humans, even the 4th use case in which results

>>>from multiple audit tools are integrated.
>>
>>This is an excellent point.  I can see a future, however, where more
>>use cases are added, based on the inclusion of other processes.  
>>Consider a SIEM tool that detects five failed logon attempts over an
>>hour's time followed by a good logon.  Traditionally, we would rely on

>>a human to go figure out whether that incident is benign.  With
>>configuration data, however, we could bolster that correlation to
>>trigger only when particular configuration items are set in a
>>particular way, if a configuration item subsequently changed, and so
>>on.
>>
>>This is a problem not just limited to CCE, I think.  I'd also like to
>>see things like: Tell me whether that user recently changed their
>>password, because if they did, then the probability that this incident

>>is benign just went up.
>>
>>>
>>>2) If there is a clear and compelling need for machine processable
>>>information regarding configuration controls that is not being met by

>>>other current efforts [2], the following questions should be worked
>>>through:
>>>+ What use cases should it support?
>>
>>This is probably the first question to answer, but I assert that to
>>answer this question properly we need to identify the processes we
>>would intend to support.  This is something that seems to be "common
>>knowledge" in the community, but that is rarely called out explicitly.
>>
>>>+ Who will create the content?
>>>+ Who will be the guarantor of the quality of that content?
>>>+ Should this be a government funded effort, "open source" or a
>>>commercial venture?
>>>
>>>We're happy to have that discussion unfold here on this list, even if

>>>the end result isn't (and shouldn't be) a part of CCE.
>>>
>>
>>>+ A content management and provisioning system capable of scaling to
>>>this
>>>scope
>>>+ A formalized adoption program (similar to CVE's) that defines
>>>+ industry
>>>best practices for the inclusion of CCE ids into configuration
>>>management tools and services.
>>>+ More ubiquitous usage of CCE ids in configuration management tools
>>>+ and
>>>services.
>>>
>>>
>>>Just to reiterate point 2)... Please feel free to continue the
>>>discussion here.  It's an important issue and needs to be discussed.
>>
>>This is good.  I don't know if CCE is the right place for what we
>>think we need at this point, but it's certainly related.
>>
>>>
>>>
>>>[1] -
>>>http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_2
>>008.p
>>>df
>>>
>>>[2] - If OVAL is sufficient to meet the use cases (unknowable till
>>>the use cases are defined), we note that both NIST SCAP/FDCC and
>>>MITRE's
>>OVAL
>>>Repository provide sets of machine processable checks.  The first is
>>>funded by the US Government and the latter is more of an open source
>>>effort (and traditionally, more focused on vulnerabilities than
>>>configuration controls).
>>>
>>>-Dave
>>>==================================================================
>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>------------------------------------------------------------------
>>>e-mail:[hidden email] | cell:781.424.6003
>>>==================================================================
>>>
>>>
>>>>-----Original Message-----
>>>>From: [hidden email]
>>>>[mailto:owner-cce- [hidden email]] On Behalf Of
>>>>[hidden email]
>>>>Sent: Thursday, August 11, 2011 11:28 AM
>>>>To: cce-working-group-list
>>>>Subject: Capturing CCE Info
>>>>
>>>>This is a discussion occurring on the asset-dev working group that
>>>>really needs to be addressed here.
>>>>
>>>>This effort has been one of maturing and evolving.  We struggled
>>>>with the right level to assign CCEs and got past that hurdle.  We
>>>>moved from v4 to v5
>>>>to add the Luhn check digit.  Now we need to make it   usable for

other

>>>>efforts to really use it appropriately.
>>>>
>>>>Thoughts on making this useful from a programmatic perspective for
>>>>other efforts to benefit from?
>>>>
>>>>Kent Landfield
>>>>Director Content Strategy, Architecture and Standards
>>>>
>>>>McAfee, Inc.
>>>>5000 Headquarters Dr.
>>>>Plano, Texas 75024
>>>>
>>>>Direct: +1.972.963.7096
>>>>Mobile: [phone]
>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>
>>>>From: Kent Landfield
>>>><[hidden email]<mailto:[hidden email]>>
>>>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>>>To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>[hidden email]<mailto:[hidden email]>>
>>>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>>>(UNCLASSIFIED)
>>>>
>>>>This is something that has to be address in CCE.  I do not agree
>>>>that it was intended to be a human-readable format for the long
>>>>term. That is where is stands today because of inadequacies in how
>>>>we deal with a CCE entry that need to be further specified, but for
>>>>the sake of it's usability and viability, it needs to be machine
>>>>readable.
>>>>
>>>>Kent Landfield
>>>>Director Content Strategy, Architecture and Standards
>>>>
>>>>McAfee, Inc.
>>>>5000 Headquarters Dr.
>>>>Plano, Texas 75024
>>>>
>>>>Direct: +1.972.963.7096
>>>>Mobile: [phone]
>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>
>>>>From: "Davidson II, Mark S"
>>>><[hidden email]<mailto:[hidden email]>>
>>>>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>[hidden email]<mailto:[hidden email]>>
>>>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>>>To: Multiple recipients of list <[hidden email]<mailto:asset-
>>>>[hidden email]>>
>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>(UNCLASSIFIED)
>>>>
>>>>CCE is intended to be a human-readable format, not a machine
>>>>readable format. For that reason, I think it will be difficult if
>>>>not infeasible to discern CCE metadata in a programmatic way.
>>>>
>>>>Relevant snippet for context:
>>>><asr:metadata>
>>>><asrm:cce_metadata>
>>>><asrm:param_state>disabled</asrm:param_state>
>>>><asrm:param_setting param="roles">
>>>><asrm:setting>admin</asrm:setting>
>>>><asrm:setting>user</asrm:setting>
>>>></asrm:param_setting>
>>>></asrm:cce_metadata>
>>>></asr:metadata>
>>>>I think it will be difficult to fill the CCE
>>>>param_state/param_setting for the following reasons:
>>>>1) There is not a machine-readable mapping from CCE to CCE
>>>>parameters
>>>>2) There is not a machine-readable mapping from CCE parameters to
>>>>actual values (IE, enabled=0, disabled=1, etc)
>>>>3) There is not a machine-readable mapping from CCE to method for
>>>>collecting the value (technical mechanism)
>>>>
>>>>I think if you had the data to communicate, this structure would
>>>>accommodate that data effectively. I'm not sure how we will actually

>>>>get the data to populate this structure.
>>>>
>>>>-Mark
>>>>
>>>>-----Original Message-----
>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>[hidden email]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
>>>>Sent: Thursday, August 11, 2011 10:21 AM
>>>>To: Multiple recipients of list
>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>(UNCLASSIFIED)
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>>
>>>>I can't think of a better alternative.  Not sure how well we will be

>>>>able to use this, but it appears to meet the need.  I'm worried
>>>>about the lack of structure.  Can we specify schemas for the known
>>>>types of metadata (the CCE, specifically)?  I'm also concerned that
>>>>the CCE structure doesn't really help a tool automate the
>>>>translation of checks into structured results.
>>>>
>>>>Looking at the schemas & documents themselves, I can't figure out
>>>>why you've structured the documents the way you have.  If all idents

>>>>in a report are in the same system, you should only have to specify
>>>>the system once at the beginning, it doesn't make sense to
>>>>re-specify the system for each result value set.  For results
>>>>against a common ident, the results should be subordinate elements
>>>>with relevant group-by attributes.
>>>>
>>>>Joseph L. Wolfkiel
>>>>Engineering Group Lead
>>>>DISA PEO MA/IA52
>>>>[phone]
>>>>[hidden email]<mailto:[hidden email]>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>[hidden email]] On Behalf Of Halbardier, Adam
>>>>Sent: Monday, August 08, 2011 1:46 PM
>>>>To: Multiple recipients of list
>>>>Subject: Follow-up from Last Call about Capturing CCE Info
>>>>
>>>>All,
>>>>
>>>>
>>>>On the last call we discussed the difficulty with reporting against
>>>>CCEs separate from the XCCDF benchmark and profile that checked the
>>>>CCE.  I took an action to look at CCE and try to come up with a
>>>>mechanism that could possibly support such a case.  Attached is a
>>>>possible solution.
>>>>Basically,
>>>>I added a "metadata" construct to the result element that can
>>>>capture arbitrary metadata about the setting of an ident.  For
>>>>simpler idents, we just capture the relevant information as
>>>>parameters on the result (see the CPE example).  For the CCE
>>>>example, we can use the metadata element to capture the CCE
>>>>settings.  I attached an extension schema for the CCE metadata.  
>>>>Basically, a CCE has one or more parameters.  Scanning through the
>>>>CCE spreadsheets, I think there are two categories of parameters.
>>>>One
>>>>category is what I'm calling "state" parameters.  Those are
>>>>parameters that just have a value, without a name associated with
>>>>the parameter (e.g., "enabled/disabled").  For the first !
>>>>category, the name of the parameter is the setting.  The second
>>>>category of parameters is a named parameter that has a value, or
>>>>list of values, associated with it (e.g., user roles).  In this
>>>>case, the parameter needs to be identified, along with the value or
>>>>list of values for the instance of the CCE.  The second category I
>>>>called "setting param".
>>>>
>>>>
>>>>A CCE metadata construct can have one or more of each of the two
>>>>types of parameters.  The parameters MUST be provided in the same
>>>>order as documented in the CCE.  The one potential disconnect here
>>>>is that the values for "setting params" isn't enumerated (and I
>>>>don't think it can be), so that could lead to data disconnects, but
>>>>it might be a limitation we just have to live with in the near-term.

>>>>Please provide thought/feedback on this approach, and if you think
>>>>it will solve the current needs.
>>>>
>>>>
>>>>-Adam
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>>
>>>>Classification:  UNCLASSIFIED
>>>>Caveats: NONE
>>>
>>
>

[Adam Montville]

On 8/22/11 7:50 AM, "Tim Keanini" <[hidden email]> wrote:

>At the core of this discussion is simply the question: How does a CCE
>come in to being?
>This is ontogenesis.  http://en.wikipedia.org/wiki/Ontogeny
>It is the only way to get complex systems to stabilize.

Insightful as usual.

>
>Picture a control panel with two knobs: one labeled social, the other
>labeled technical :-)
>As we turn up the technical knob and are success, we may wash out some
>of the inconsistency and slowness with the social but never will the
>social ever reach zero unless we are dealing with a world model that is
>too complex for human understanding all together.

Agree.

>With CCE, we are dealing with a parameters space far more vast than we
>care or even should care about understanding so it then becomes a game
>of being able to make socially stable those "parameters of interest" so
>that we can automate our ability to witness them.

The "parameters of interest" will change over time.

>This is what the
>checklist programs have done so far.  Mind you, sometimes this social
>understanding cannot be made stable and if this is true, the benefits of
>the technical will be limited to fragmented communities as they have
>been for years now.

Is this statement suggesting that reaching a stable vocabulary between our
domains is not possible?  It seems that stabilization is a necessary
condition for effective automation.

>
>
>Yes, I have had too much coffee this morning.

Never.

>
>--tk
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Adam
>Montville
>Sent: Monday, August 22, 2011 8:31 AM
>To: Mann, Dave; [hidden email]
>Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info
>
>On 8/19/11 1:07 PM, "Mann, Dave" <[hidden email]> wrote:
>
>>>From: Adam Montville [mailto:[hidden email]] At the time,
>>>helping human analysts correlate was the requirement.  I believe now
>>>this has changed somewhat.  I would like to see the industry move in a
>
>>>direction that permits very complicated correlations in an automated
>>>manner.  As we mature beyond the C&A-motivated capabilities of asset,
>>>configuration, and vulnerability management into supporting specific
>>>security processes (I.e. Event correlation), we are going to be
>>>serving much different needs.
>>
>>I can totally understand this desire and aspiration.
>>
>>My sense is that we (the configuration audit/management) community are
>>facing a very thorny problem though - one whose economic and human
>>process problems are just as hard as the technical ones and the
>>technical ones are way hard.
>>
>>The core issue as I see it is how do you instrument a platform and then
>
>>generate, expose and share executable content against that
>>instrumentation in a way that is a) economically feasible and b)
>>meaningful to the configuration audit community?
>
>I would really like to see us expand from this limitation to the
>configuration audit community. Incident handlers, for example, may also
>find CCE useful.
>
>>
>>Languages (e.g. like OVAL) are certainly needed but they aren't
>>sufficient.  Check logic needs to be written, or generated.   Some
>>suggest that OS/application vendors should generate this content but
>>others have noted the lack of economic incentives.
>>
>>To further complicate this, our use case analysis (both for CCE and
>>other related efforts) has repeatedly and consistently shown that
>>software vendors think of "configuration issues" in very different
>>terms than the configuration audit/management community does.  So,
>>there's the strong possibility for the "be careful what you wish for"
>>problem.  Machine consumable content that is auto-generated by a
>>process that is centered more on feature & code-base management may not
>
>>be useful for configuration audit.
>
>Yes, we should be careful what we wish for, but right now I feel that
>we're at a point of flushing out some important semantic differences.
>Consider a world in which CCE, the specification, is used outside just
>the security context.  Would we still call it CCE?
>
>Also, my argument here is that, especially for incident response
>capabilities, understanding configuration issues from the software
>vendors' point of view is, perhaps, as important as viewing
>configuration issues in the security context (in fact, when
>investigating an incident, aren't all "configuration issues"
>security-related?).
>
>>
>>Another consideration... I don't see large scale automated
>>configuration audit content provisioning happening until the content
>>itself is largely auto-generated from other data stores.
>
>This is an important point to make and to be heard.
>
>>
>>As many of you know, I'm a nut about vintage bicycles.  I ride a 1979
>>Trek.  It was handmade in a barn in Madison, WI and many of the early
>>Trek workers went on to notable careers as custom hand-made bike
>>builders.  In fact, they had to find other work because by 1989, Trek
>>bikes were pretty much all produced by precision robotics.  As much of
>>a fan of hand-made bikes as I am, Trek's move to automation allowed
>>them to become an industry giant.
>>
>>I think configuration content at the level you're talking about will
>>need to be auto-created, at least to some degree.
>
>I agree.  We're at the point where we ought to be considering how this
>can happen.
>
>>
>>
>>Dave Mann wrote:
>>>>3) Since the issue of CCE's future has been raised, my sense is that
>>>>the important success goals for CCE's near to mid-term progress
>include:
>>>>+ Broader coverage of security guides and audit tool issues by CCE.
>>
>>Adam wrote:
>>>I'm wondering if this isn't too narrow a focus.  This relegates CCE to
>
>>>security-specific settings, and it's clear that this industry is
>>>coming to the realization that security-specific processes really
>>>support IT processes, and that IT processes encompass more than
>>>security-specific settings.
>>
>>In terms of vision, it is too narrow and that has been CCE's position
>>since the beginning.
>>
>>But, in terms of current realities it remains something of a stretch
>>goal for us.  We aren't close to hitting that goal yet.
>>
>>Even if we drop the hopes for machine readable content related to CCEs
>>and just stick with CCE's as currently defined, broadening the scope
>>beyond what is captured in security guides and config audit tools will
>>require that we auto-generate CCE data.  This turns out to be pretty
>hard.
>>
>>As many of you know, Microsoft has been working with the CCE team to
>>auto-generate CCE candidates.  We've had some wonderful initial
>>successes along with the expected hiccups.  IMO, they're to be
>>commended for working on this as hard as they have. They are certainly
>>well out in front of anybody else in this regard.
>
>I didn't realize this is ongoing work.  Happy to hear it.
>
>>
>>One of the issues that we've encountered (and I must emphasize this,
>>we've seen this with every single OS/App vendor we've worked with) is
>>that their internal data is fundamentally different from what is
>>codified in CCE. There are significant tensions around level of
>>abstraction issues for instance.  Software manufacturing is different
>>from configuration management and this is to be expected and I in no
>>way fault Microsoft or any other software vendor for it.
>
>So, perhaps this is another point of evidence to substantiate an
>assertion that we're at a place where we need to consider the two as
>separate, but related definitions.  I'm not sure of the "right" answer -
>there are likely many ways to figure this out.
>
>>
>>So, let me toss out a challenge to my friends in the configuration
>>audit/management space?
>>
>>Would your company be willing to work with us to attempt to
>>auto-generate CCE candidates from your internal configuration
>>audit/management repositories?
>
>I hope the answer is yes from many.
>
>>
>>
>>-Dave
>>==================================================================
>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>------------------------------------------------------------------
>>e-mail:[hidden email] | cell:781.424.6003
>>==================================================================
>>
>>
>>
>>>
>>>>CCE was founded on 5 documented use cases as discussed in section 4
>>>>of the CCE overview paper [1].  In all 5 of the scenarios, the
>>>>correlation is done by humans, even the 4th use case in which results
>
>>>>from multiple audit tools are integrated.
>>>
>>>This is an excellent point.  I can see a future, however, where more
>>>use cases are added, based on the inclusion of other processes.
>>>Consider a SIEM tool that detects five failed logon attempts over an
>>>hour's time followed by a good logon.  Traditionally, we would rely on
>
>>>a human to go figure out whether that incident is benign.  With
>>>configuration data, however, we could bolster that correlation to
>>>trigger only when particular configuration items are set in a
>>>particular way, if a configuration item subsequently changed, and so
>>>on.
>>>
>>>This is a problem not just limited to CCE, I think.  I'd also like to
>>>see things like: Tell me whether that user recently changed their
>>>password, because if they did, then the probability that this incident
>
>>>is benign just went up.
>>>
>>>>
>>>>2) If there is a clear and compelling need for machine processable
>>>>information regarding configuration controls that is not being met by
>
>>>>other current efforts [2], the following questions should be worked
>>>>through:
>>>>+ What use cases should it support?
>>>
>>>This is probably the first question to answer, but I assert that to
>>>answer this question properly we need to identify the processes we
>>>would intend to support.  This is something that seems to be "common
>>>knowledge" in the community, but that is rarely called out explicitly.
>>>
>>>>+ Who will create the content?
>>>>+ Who will be the guarantor of the quality of that content?
>>>>+ Should this be a government funded effort, "open source" or a
>>>>commercial venture?
>>>>
>>>>We're happy to have that discussion unfold here on this list, even if
>
>>>>the end result isn't (and shouldn't be) a part of CCE.
>>>>
>>>
>>>>+ A content management and provisioning system capable of scaling to
>>>>this
>>>>scope
>>>>+ A formalized adoption program (similar to CVE's) that defines
>>>>+ industry
>>>>best practices for the inclusion of CCE ids into configuration
>>>>management tools and services.
>>>>+ More ubiquitous usage of CCE ids in configuration management tools
>>>>+ and
>>>>services.
>>>>
>>>>
>>>>Just to reiterate point 2)... Please feel free to continue the
>>>>discussion here.  It's an important issue and needs to be discussed.
>>>
>>>This is good.  I don't know if CCE is the right place for what we
>>>think we need at this point, but it's certainly related.
>>>
>>>>
>>>>
>>>>[1] -
>>>>http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_2
>>>008.p
>>>>df
>>>>
>>>>[2] - If OVAL is sufficient to meet the use cases (unknowable till
>>>>the use cases are defined), we note that both NIST SCAP/FDCC and
>>>>MITRE's
>>>OVAL
>>>>Repository provide sets of machine processable checks.  The first is
>>>>funded by the US Government and the latter is more of an open source
>>>>effort (and traditionally, more focused on vulnerabilities than
>>>>configuration controls).
>>>>
>>>>-Dave
>>>>==================================================================
>>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>>------------------------------------------------------------------
>>>>e-mail:[hidden email] | cell:781.424.6003
>>>>==================================================================
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]
>>>>>[mailto:owner-cce- [hidden email]] On Behalf Of
>>>>>[hidden email]
>>>>>Sent: Thursday, August 11, 2011 11:28 AM
>>>>>To: cce-working-group-list
>>>>>Subject: Capturing CCE Info
>>>>>
>>>>>This is a discussion occurring on the asset-dev working group that
>>>>>really needs to be addressed here.
>>>>>
>>>>>This effort has been one of maturing and evolving.  We struggled
>>>>>with the right level to assign CCEs and got past that hurdle.  We
>>>>>moved from v4 to v5
>>>>>to add the Luhn check digit.  Now we need to make it   usable for
>other
>>>>>efforts to really use it appropriately.
>>>>>
>>>>>Thoughts on making this useful from a programmatic perspective for
>>>>>other efforts to benefit from?
>>>>>
>>>>>Kent Landfield
>>>>>Director Content Strategy, Architecture and Standards
>>>>>
>>>>>McAfee, Inc.
>>>>>5000 Headquarters Dr.
>>>>>Plano, Texas 75024
>>>>>
>>>>>Direct: +1.972.963.7096
>>>>>Mobile: [phone]
>>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>>
>>>>>From: Kent Landfield
>>>>><[hidden email]<mailto:[hidden email]>>
>>>>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>>>>To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>>[hidden email]<mailto:[hidden email]>>
>>>>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>This is something that has to be address in CCE.  I do not agree
>>>>>that it was intended to be a human-readable format for the long
>>>>>term. That is where is stands today because of inadequacies in how
>>>>>we deal with a CCE entry that need to be further specified, but for
>>>>>the sake of it's usability and viability, it needs to be machine
>>>>>readable.
>>>>>
>>>>>Kent Landfield
>>>>>Director Content Strategy, Architecture and Standards
>>>>>
>>>>>McAfee, Inc.
>>>>>5000 Headquarters Dr.
>>>>>Plano, Texas 75024
>>>>>
>>>>>Direct: +1.972.963.7096
>>>>>Mobile: [phone]
>>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>>
>>>>>From: "Davidson II, Mark S"
>>>>><[hidden email]<mailto:[hidden email]>>
>>>>>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>>[hidden email]<mailto:[hidden email]>>
>>>>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>>>>To: Multiple recipients of list <[hidden email]<mailto:asset-
>>>>>[hidden email]>>
>>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>CCE is intended to be a human-readable format, not a machine
>>>>>readable format. For that reason, I think it will be difficult if
>>>>>not infeasible to discern CCE metadata in a programmatic way.
>>>>>
>>>>>Relevant snippet for context:
>>>>><asr:metadata>
>>>>><asrm:cce_metadata>
>>>>><asrm:param_state>disabled</asrm:param_state>
>>>>><asrm:param_setting param="roles">
>>>>><asrm:setting>admin</asrm:setting>
>>>>><asrm:setting>user</asrm:setting>
>>>>></asrm:param_setting>
>>>>></asrm:cce_metadata>
>>>>></asr:metadata>
>>>>>I think it will be difficult to fill the CCE
>>>>>param_state/param_setting for the following reasons:
>>>>>1) There is not a machine-readable mapping from CCE to CCE
>>>>>parameters
>>>>>2) There is not a machine-readable mapping from CCE parameters to
>>>>>actual values (IE, enabled=0, disabled=1, etc)
>>>>>3) There is not a machine-readable mapping from CCE to method for
>>>>>collecting the value (technical mechanism)
>>>>>
>>>>>I think if you had the data to communicate, this structure would
>>>>>accommodate that data effectively. I'm not sure how we will actually
>
>>>>>get the data to populate this structure.
>>>>>
>>>>>-Mark
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>>[hidden email]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
>>>>>Sent: Thursday, August 11, 2011 10:21 AM
>>>>>To: Multiple recipients of list
>>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>I can't think of a better alternative.  Not sure how well we will be
>
>>>>>able to use this, but it appears to meet the need.  I'm worried
>>>>>about the lack of structure.  Can we specify schemas for the known
>>>>>types of metadata (the CCE, specifically)?  I'm also concerned that
>>>>>the CCE structure doesn't really help a tool automate the
>>>>>translation of checks into structured results.
>>>>>
>>>>>Looking at the schemas & documents themselves, I can't figure out
>>>>>why you've structured the documents the way you have.  If all idents
>
>>>>>in a report are in the same system, you should only have to specify
>>>>>the system once at the beginning, it doesn't make sense to
>>>>>re-specify the system for each result value set.  For results
>>>>>against a common ident, the results should be subordinate elements
>>>>>with relevant group-by attributes.
>>>>>
>>>>>Joseph L. Wolfkiel
>>>>>Engineering Group Lead
>>>>>DISA PEO MA/IA52
>>>>>[phone]
>>>>>[hidden email]<mailto:[hidden email]>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>>[hidden email]] On Behalf Of Halbardier, Adam
>>>>>Sent: Monday, August 08, 2011 1:46 PM
>>>>>To: Multiple recipients of list
>>>>>Subject: Follow-up from Last Call about Capturing CCE Info
>>>>>
>>>>>All,
>>>>>
>>>>>
>>>>>On the last call we discussed the difficulty with reporting against
>>>>>CCEs separate from the XCCDF benchmark and profile that checked the
>>>>>CCE.  I took an action to look at CCE and try to come up with a
>>>>>mechanism that could possibly support such a case.  Attached is a
>>>>>possible solution.
>>>>>Basically,
>>>>>I added a "metadata" construct to the result element that can
>>>>>capture arbitrary metadata about the setting of an ident.  For
>>>>>simpler idents, we just capture the relevant information as
>>>>>parameters on the result (see the CPE example).  For the CCE
>>>>>example, we can use the metadata element to capture the CCE
>>>>>settings.  I attached an extension schema for the CCE metadata.
>>>>>Basically, a CCE has one or more parameters.  Scanning through the
>>>>>CCE spreadsheets, I think there are two categories of parameters.
>>>>>One
>>>>>category is what I'm calling "state" parameters.  Those are
>>>>>parameters that just have a value, without a name associated with
>>>>>the parameter (e.g., "enabled/disabled").  For the first !
>>>>>category, the name of the parameter is the setting.  The second
>>>>>category of parameters is a named parameter that has a value, or
>>>>>list of values, associated with it (e.g., user roles).  In this
>>>>>case, the parameter needs to be identified, along with the value or
>>>>>list of values for the instance of the CCE.  The second category I
>>>>>called "setting param".
>>>>>
>>>>>
>>>>>A CCE metadata construct can have one or more of each of the two
>>>>>types of parameters.  The parameters MUST be provided in the same
>>>>>order as documented in the CCE.  The one potential disconnect here
>>>>>is that the values for "setting params" isn't enumerated (and I
>>>>>don't think it can be), so that could lead to data disconnects, but
>>>>>it might be a limitation we just have to live with in the near-term.
>
>>>>>Please provide thought/feedback on this approach, and if you think
>>>>>it will solve the current needs.
>>>>>
>>>>>
>>>>>-Adam
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>
>>>
>>
>

[Tim Keanini]

The "parameters of interest" will change over time and that is why the
social processes must always be in place because the technology will not
know how to recalibrate.  

My statement below about communities stabilizing (or sometimes
fragmenting) is just to point out what we have today. I'm in no way
trying to trivialize the social complexity, I'm trying to do the
opposite and highlight how these social problems are really the first
step and not the last.  I've watched over the years as PCI changed the
understanding of a community (retail and leisure) , I've seen the same
happen with many other regulations whereby there is a common bad thing
(cost) that will happen (get fired, get fined, get shamed, etc).  

Indirectly, if we ask the question, if I don't do/apply/contribute-to
CCE:
- what (cost) bad thing will happen to me or my peers?
- what opportunity will be lost?
How we individually answer this question highlights how we all
understand CCE's progress over the years.

--tk

-----Original Message-----
From: Adam Montville [mailto:[hidden email]]
Sent: Monday, August 22, 2011 11:03 AM
To: Tim Keanini; Mann, Dave; [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info



On 8/22/11 7:50 AM, "Tim Keanini" <[hidden email]> wrote:

>At the core of this discussion is simply the question: How does a CCE
>come in to being?
>This is ontogenesis.  http://en.wikipedia.org/wiki/Ontogeny
>It is the only way to get complex systems to stabilize.

Insightful as usual.

>
>Picture a control panel with two knobs: one labeled social, the other
>labeled technical :-) As we turn up the technical knob and are success,

>we may wash out some of the inconsistency and slowness with the social
>but never will the social ever reach zero unless we are dealing with a
>world model that is too complex for human understanding all together.

Agree.

>With CCE, we are dealing with a parameters space far more vast than we
>care or even should care about understanding so it then becomes a game
>of being able to make socially stable those "parameters of interest" so

>that we can automate our ability to witness them.

The "parameters of interest" will change over time.

>This is what the
>checklist programs have done so far.  Mind you, sometimes this social
>understanding cannot be made stable and if this is true, the benefits
>of the technical will be limited to fragmented communities as they have

>been for years now.

Is this statement suggesting that reaching a stable vocabulary between
our domains is not possible?  It seems that stabilization is a necessary
condition for effective automation.

>
>
>Yes, I have had too much coffee this morning.

Never.

>
>--tk
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Adam

>Montville
>Sent: Monday, August 22, 2011 8:31 AM
>To: Mann, Dave; [hidden email]
>Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info
>
>On 8/19/11 1:07 PM, "Mann, Dave" <[hidden email]> wrote:
>
>>>From: Adam Montville [mailto:[hidden email]] At the time,
>>>helping human analysts correlate was the requirement.  I believe now
>>>this has changed somewhat.  I would like to see the industry move in
>>>a
>
>>>direction that permits very complicated correlations in an automated
>>>manner.  As we mature beyond the C&A-motivated capabilities of asset,

>>>configuration, and vulnerability management into supporting specific
>>>security processes (I.e. Event correlation), we are going to be
>>>serving much different needs.
>>
>>I can totally understand this desire and aspiration.
>>
>>My sense is that we (the configuration audit/management) community are

>>facing a very thorny problem though - one whose economic and human
>>process problems are just as hard as the technical ones and the
>>technical ones are way hard.
>>
>>The core issue as I see it is how do you instrument a platform and
>>then
>
>>generate, expose and share executable content against that
>>instrumentation in a way that is a) economically feasible and b)
>>meaningful to the configuration audit community?
>
>I would really like to see us expand from this limitation to the
>configuration audit community. Incident handlers, for example, may also

>find CCE useful.
>
>>
>>Languages (e.g. like OVAL) are certainly needed but they aren't
>>sufficient.  Check logic needs to be written, or generated.   Some
>>suggest that OS/application vendors should generate this content but
>>others have noted the lack of economic incentives.
>>
>>To further complicate this, our use case analysis (both for CCE and
>>other related efforts) has repeatedly and consistently shown that
>>software vendors think of "configuration issues" in very different
>>terms than the configuration audit/management community does.  So,
>>there's the strong possibility for the "be careful what you wish for"
>>problem.  Machine consumable content that is auto-generated by a
>>process that is centered more on feature & code-base management may
>>not
>
>>be useful for configuration audit.
>
>Yes, we should be careful what we wish for, but right now I feel that
>we're at a point of flushing out some important semantic differences.
>Consider a world in which CCE, the specification, is used outside just
>the security context.  Would we still call it CCE?
>
>Also, my argument here is that, especially for incident response
>capabilities, understanding configuration issues from the software
>vendors' point of view is, perhaps, as important as viewing
>configuration issues in the security context (in fact, when
>investigating an incident, aren't all "configuration issues"
>security-related?).
>
>>
>>Another consideration... I don't see large scale automated
>>configuration audit content provisioning happening until the content
>>itself is largely auto-generated from other data stores.
>
>This is an important point to make and to be heard.
>
>>
>>As many of you know, I'm a nut about vintage bicycles.  I ride a 1979
>>Trek.  It was handmade in a barn in Madison, WI and many of the early
>>Trek workers went on to notable careers as custom hand-made bike
>>builders.  In fact, they had to find other work because by 1989, Trek
>>bikes were pretty much all produced by precision robotics.  As much of

>>a fan of hand-made bikes as I am, Trek's move to automation allowed
>>them to become an industry giant.
>>
>>I think configuration content at the level you're talking about will
>>need to be auto-created, at least to some degree.
>
>I agree.  We're at the point where we ought to be considering how this
>can happen.
>
>>
>>
>>Dave Mann wrote:
>>>>3) Since the issue of CCE's future has been raised, my sense is that

>>>>the important success goals for CCE's near to mid-term progress
>include:
>>>>+ Broader coverage of security guides and audit tool issues by CCE.
>>
>>Adam wrote:
>>>I'm wondering if this isn't too narrow a focus.  This relegates CCE
>>>to
>
>>>security-specific settings, and it's clear that this industry is
>>>coming to the realization that security-specific processes really
>>>support IT processes, and that IT processes encompass more than
>>>security-specific settings.
>>
>>In terms of vision, it is too narrow and that has been CCE's position
>>since the beginning.
>>
>>But, in terms of current realities it remains something of a stretch
>>goal for us.  We aren't close to hitting that goal yet.
>>
>>Even if we drop the hopes for machine readable content related to CCEs

>>and just stick with CCE's as currently defined, broadening the scope
>>beyond what is captured in security guides and config audit tools will

>>require that we auto-generate CCE data.  This turns out to be pretty
>hard.
>>
>>As many of you know, Microsoft has been working with the CCE team to
>>auto-generate CCE candidates.  We've had some wonderful initial
>>successes along with the expected hiccups.  IMO, they're to be
>>commended for working on this as hard as they have. They are certainly

>>well out in front of anybody else in this regard.
>
>I didn't realize this is ongoing work.  Happy to hear it.
>
>>
>>One of the issues that we've encountered (and I must emphasize this,
>>we've seen this with every single OS/App vendor we've worked with) is
>>that their internal data is fundamentally different from what is
>>codified in CCE. There are significant tensions around level of
>>abstraction issues for instance.  Software manufacturing is different
>>from configuration management and this is to be expected and I in no
>>way fault Microsoft or any other software vendor for it.
>
>So, perhaps this is another point of evidence to substantiate an
>assertion that we're at a place where we need to consider the two as
>separate, but related definitions.  I'm not sure of the "right" answer
>- there are likely many ways to figure this out.
>
>>
>>So, let me toss out a challenge to my friends in the configuration
>>audit/management space?
>>
>>Would your company be willing to work with us to attempt to
>>auto-generate CCE candidates from your internal configuration
>>audit/management repositories?
>
>I hope the answer is yes from many.
>
>>
>>
>>-Dave
>>==================================================================
>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>------------------------------------------------------------------
>>e-mail:[hidden email] | cell:781.424.6003
>>==================================================================
>>
>>
>>
>>>
>>>>CCE was founded on 5 documented use cases as discussed in section 4
>>>>of the CCE overview paper [1].  In all 5 of the scenarios, the
>>>>correlation is done by humans, even the 4th use case in which
>>>>results
>
>>>>from multiple audit tools are integrated.
>>>
>>>This is an excellent point.  I can see a future, however, where more
>>>use cases are added, based on the inclusion of other processes.
>>>Consider a SIEM tool that detects five failed logon attempts over an
>>>hour's time followed by a good logon.  Traditionally, we would rely
>>>on
>
>>>a human to go figure out whether that incident is benign.  With
>>>configuration data, however, we could bolster that correlation to
>>>trigger only when particular configuration items are set in a
>>>particular way, if a configuration item subsequently changed, and so
>>>on.
>>>
>>>This is a problem not just limited to CCE, I think.  I'd also like to

>>>see things like: Tell me whether that user recently changed their
>>>password, because if they did, then the probability that this
>>>incident
>
>>>is benign just went up.
>>>
>>>>
>>>>2) If there is a clear and compelling need for machine processable
>>>>information regarding configuration controls that is not being met
>>>>by
>
>>>>other current efforts [2], the following questions should be worked
>>>>through:
>>>>+ What use cases should it support?
>>>
>>>This is probably the first question to answer, but I assert that to
>>>answer this question properly we need to identify the processes we
>>>would intend to support.  This is something that seems to be "common
>>>knowledge" in the community, but that is rarely called out

explicitly.

>>>
>>>>+ Who will create the content?
>>>>+ Who will be the guarantor of the quality of that content?
>>>>+ Should this be a government funded effort, "open source" or a
>>>>commercial venture?
>>>>
>>>>We're happy to have that discussion unfold here on this list, even
>>>>if
>
>>>>the end result isn't (and shouldn't be) a part of CCE.
>>>>
>>>
>>>>+ A content management and provisioning system capable of scaling to
>>>>this
>>>>scope
>>>>+ A formalized adoption program (similar to CVE's) that defines
>>>>+ industry
>>>>best practices for the inclusion of CCE ids into configuration
>>>>management tools and services.
>>>>+ More ubiquitous usage of CCE ids in configuration management tools

>>>>+ and
>>>>services.
>>>>
>>>>
>>>>Just to reiterate point 2)... Please feel free to continue the
>>>>discussion here.  It's an important issue and needs to be discussed.
>>>
>>>This is good.  I don't know if CCE is the right place for what we
>>>think we need at this point, but it's certainly related.
>>>
>>>>
>>>>
>>>>[1] -
>>>>http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_
>>>>2
>>>008.p
>>>>df
>>>>
>>>>[2] - If OVAL is sufficient to meet the use cases (unknowable till
>>>>the use cases are defined), we note that both NIST SCAP/FDCC and
>>>>MITRE's
>>>OVAL
>>>>Repository provide sets of machine processable checks.  The first is

>>>>funded by the US Government and the latter is more of an open source

>>>>effort (and traditionally, more focused on vulnerabilities than
>>>>configuration controls).
>>>>
>>>>-Dave
>>>>==================================================================
>>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>>------------------------------------------------------------------
>>>>e-mail:[hidden email] | cell:781.424.6003
>>>>==================================================================
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]
>>>>>[mailto:owner-cce- [hidden email]] On Behalf Of

>>>>>[hidden email]
>>>>>Sent: Thursday, August 11, 2011 11:28 AM
>>>>>To: cce-working-group-list
>>>>>Subject: Capturing CCE Info
>>>>>
>>>>>This is a discussion occurring on the asset-dev working group that
>>>>>really needs to be addressed here.
>>>>>
>>>>>This effort has been one of maturing and evolving.  We struggled
>>>>>with the right level to assign CCEs and got past that hurdle.  We
>>>>>moved from v4 to v5
>>>>>to add the Luhn check digit.  Now we need to make it   usable for
>other
>>>>>efforts to really use it appropriately.
>>>>>
>>>>>Thoughts on making this useful from a programmatic perspective for
>>>>>other efforts to benefit from?
>>>>>
>>>>>Kent Landfield
>>>>>Director Content Strategy, Architecture and Standards
>>>>>
>>>>>McAfee, Inc.
>>>>>5000 Headquarters Dr.
>>>>>Plano, Texas 75024
>>>>>
>>>>>Direct: +1.972.963.7096
>>>>>Mobile: [phone]
>>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>>
>>>>>From: Kent Landfield
>>>>><[hidden email]<mailto:[hidden email]>>
>>>>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>>>>To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>>[hidden email]<mailto:[hidden email]>>
>>>>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>This is something that has to be address in CCE.  I do not agree
>>>>>that it was intended to be a human-readable format for the long
>>>>>term. That is where is stands today because of inadequacies in how
>>>>>we deal with a CCE entry that need to be further specified, but for

>>>>>the sake of it's usability and viability, it needs to be machine
>>>>>readable.
>>>>>
>>>>>Kent Landfield
>>>>>Director Content Strategy, Architecture and Standards
>>>>>
>>>>>McAfee, Inc.
>>>>>5000 Headquarters Dr.
>>>>>Plano, Texas 75024
>>>>>
>>>>>Direct: +1.972.963.7096
>>>>>Mobile: [phone]
>>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>>
>>>>>From: "Davidson II, Mark S"
>>>>><[hidden email]<mailto:[hidden email]>>
>>>>>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>>[hidden email]<mailto:[hidden email]>>
>>>>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>>>>To: Multiple recipients of list <[hidden email]<mailto:asset-
>>>>>[hidden email]>>
>>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>CCE is intended to be a human-readable format, not a machine
>>>>>readable format. For that reason, I think it will be difficult if
>>>>>not infeasible to discern CCE metadata in a programmatic way.
>>>>>
>>>>>Relevant snippet for context:
>>>>><asr:metadata>
>>>>><asrm:cce_metadata>
>>>>><asrm:param_state>disabled</asrm:param_state>
>>>>><asrm:param_setting param="roles">
>>>>><asrm:setting>admin</asrm:setting>
>>>>><asrm:setting>user</asrm:setting>
>>>>></asrm:param_setting>
>>>>></asrm:cce_metadata>
>>>>></asr:metadata>
>>>>>I think it will be difficult to fill the CCE
>>>>>param_state/param_setting for the following reasons:
>>>>>1) There is not a machine-readable mapping from CCE to CCE
>>>>>parameters
>>>>>2) There is not a machine-readable mapping from CCE parameters to
>>>>>actual values (IE, enabled=0, disabled=1, etc)
>>>>>3) There is not a machine-readable mapping from CCE to method for
>>>>>collecting the value (technical mechanism)
>>>>>
>>>>>I think if you had the data to communicate, this structure would
>>>>>accommodate that data effectively. I'm not sure how we will
>>>>>actually
>
>>>>>get the data to populate this structure.
>>>>>
>>>>>-Mark
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>>[hidden email]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
>>>>>Sent: Thursday, August 11, 2011 10:21 AM
>>>>>To: Multiple recipients of list
>>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>I can't think of a better alternative.  Not sure how well we will
>>>>>be
>
>>>>>able to use this, but it appears to meet the need.  I'm worried
>>>>>about the lack of structure.  Can we specify schemas for the known
>>>>>types of metadata (the CCE, specifically)?  I'm also concerned that

>>>>>the CCE structure doesn't really help a tool automate the
>>>>>translation of checks into structured results.
>>>>>
>>>>>Looking at the schemas & documents themselves, I can't figure out
>>>>>why you've structured the documents the way you have.  If all
>>>>>idents
>
>>>>>in a report are in the same system, you should only have to specify

>>>>>the system once at the beginning, it doesn't make sense to
>>>>>re-specify the system for each result value set.  For results
>>>>>against a common ident, the results should be subordinate elements
>>>>>with relevant group-by attributes.
>>>>>
>>>>>Joseph L. Wolfkiel
>>>>>Engineering Group Lead
>>>>>DISA PEO MA/IA52
>>>>>[phone]
>>>>>[hidden email]<mailto:[hidden email]>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]<mailto:[hidden email]> [mailto:asset-
>>>>>[hidden email]] On Behalf Of Halbardier, Adam
>>>>>Sent: Monday, August 08, 2011 1:46 PM
>>>>>To: Multiple recipients of list
>>>>>Subject: Follow-up from Last Call about Capturing CCE Info
>>>>>
>>>>>All,
>>>>>
>>>>>
>>>>>On the last call we discussed the difficulty with reporting against

>>>>>CCEs separate from the XCCDF benchmark and profile that checked the

>>>>>CCE.  I took an action to look at CCE and try to come up with a
>>>>>mechanism that could possibly support such a case.  Attached is a
>>>>>possible solution.
>>>>>Basically,
>>>>>I added a "metadata" construct to the result element that can
>>>>>capture arbitrary metadata about the setting of an ident.  For
>>>>>simpler idents, we just capture the relevant information as
>>>>>parameters on the result (see the CPE example).  For the CCE
>>>>>example, we can use the metadata element to capture the CCE
>>>>>settings.  I attached an extension schema for the CCE metadata.
>>>>>Basically, a CCE has one or more parameters.  Scanning through the
>>>>>CCE spreadsheets, I think there are two categories of parameters.
>>>>>One
>>>>>category is what I'm calling "state" parameters.  Those are
>>>>>parameters that just have a value, without a name associated with
>>>>>the parameter (e.g., "enabled/disabled").  For the first !
>>>>>category, the name of the parameter is the setting.  The second
>>>>>category of parameters is a named parameter that has a value, or
>>>>>list of values, associated with it (e.g., user roles).  In this
>>>>>case, the parameter needs to be identified, along with the value or

>>>>>list of values for the instance of the CCE.  The second category I
>>>>>called "setting param".
>>>>>
>>>>>
>>>>>A CCE metadata construct can have one or more of each of the two
>>>>>types of parameters.  The parameters MUST be provided in the same
>>>>>order as documented in the CCE.  The one potential disconnect here
>>>>>is that the values for "setting params" isn't enumerated (and I
>>>>>don't think it can be), so that could lead to data disconnects, but

>>>>>it might be a limitation we just have to live with in the
near-term.

>
>>>>>Please provide thought/feedback on this approach, and if you think
>>>>>it will solve the current needs.
>>>>>
>>>>>
>>>>>-Adam
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>
>>>
>>
>

[Mike Murray-2]

I'm usually pretty quiet on here, but this brings up a really great point - one of the things that always seems most easily missed in the creation of standards is that, for the people who don't understand TK's cost equation below implicitly, there's going to be a hesitancy to buy in.  

I struggled with this back in the early days of CVE and OVAL - until we could create tangible costs for our vendor community to not buying in (and usually that came down to a few key customers saying "you will have CVE/OVAL compliance or you will not be our product), only the few forward thinkers who understood the additional benefit at a deep and cultural level within their organization (see Microsoft from earlier this thread) were willing to play.

Perhaps more out-reach to the potential customers as a way to assist in creating more of those tangible costs for opting-out of the game?  

I clearly haven't had enough coffee this morning...

On Mon, Aug 22, 2011 at 9:57 AM, Tim Keanini <[hidden email]> wrote:

The "parameters of interest" will change over time and that is why the
social processes must always be in place because the technology will not
know how to recalibrate.

My statement below about communities stabilizing (or sometimes
fragmenting) is just to point out what we have today. I'm in no way
trying to trivialize the social complexity, I'm trying to do the
opposite and highlight how these social problems are really the first
step and not the last.  I've watched over the years as PCI changed the
understanding of a community (retail and leisure) , I've seen the same
happen with many other regulations whereby there is a common bad thing
(cost) that will happen (get fired, get fined, get shamed, etc).

Indirectly, if we ask the question, if I don't do/apply/contribute-to
CCE:
- what (cost) bad thing will happen to me or my peers?
- what opportunity will be lost?
How we individually answer this question highlights how we all
understand CCE's progress over the years.

--tk

-----Original Message-----
From: Adam Montville [mailto:[hidden email]]

Sent: Monday, August 22, 2011 11:03 AM
To: Tim Keanini; Mann, Dave; [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info



On 8/22/11 7:50 AM, "Tim Keanini" <[hidden email]> wrote:

>At the core of this discussion is simply the question: How does a CCE
>come in to being?
>This is ontogenesis.  http://en.wikipedia.org/wiki/Ontogeny
>It is the only way to get complex systems to stabilize.

Insightful as usual.

>
>Picture a control panel with two knobs: one labeled social, the other
>labeled technical :-) As we turn up the technical knob and are success,

>we may wash out some of the inconsistency and slowness with the social
>but never will the social ever reach zero unless we are dealing with a
>world model that is too complex for human understanding all together.

Agree.

>With CCE, we are dealing with a parameters space far more vast than we
>care or even should care about understanding so it then becomes a game
>of being able to make socially stable those "parameters of interest" so

>that we can automate our ability to witness them.

The "parameters of interest" will change over time.

>This is what the
>checklist programs have done so far.  Mind you, sometimes this social
>understanding cannot be made stable and if this is true, the benefits
>of the technical will be limited to fragmented communities as they have

>been for years now.

Is this statement suggesting that reaching a stable vocabulary between
our domains is not possible?  It seems that stabilization is a necessary
condition for effective automation.

>
>
>Yes, I have had too much coffee this morning.

Never.

>
>--tk
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Adam

>Montville
>Sent: Monday, August 22, 2011 8:31 AM
>To: Mann, Dave; [hidden email]
>Subject: Re: [CCE-WORKING-GROUP-LIST] Capturing CCE Info
>
>On 8/19/11 1:07 PM, "Mann, Dave" <[hidden email]> wrote:
>
>>>From: Adam Montville [mailto:[hidden email]] At the time,
>>>helping human analysts correlate was the requirement.  I believe now
>>>this has changed somewhat.  I would like to see the industry move in
>>>a
>
>>>direction that permits very complicated correlations in an automated
>>>manner.  As we mature beyond the C&A-motivated capabilities of asset,

>>>configuration, and vulnerability management into supporting specific
>>>security processes (I.e. Event correlation), we are going to be
>>>serving much different needs.
>>
>>I can totally understand this desire and aspiration.
>>
>>My sense is that we (the configuration audit/management) community are

>>facing a very thorny problem though - one whose economic and human
>>process problems are just as hard as the technical ones and the
>>technical ones are way hard.
>>
>>The core issue as I see it is how do you instrument a platform and
>>then
>
>>generate, expose and share executable content against that
>>instrumentation in a way that is a) economically feasible and b)
>>meaningful to the configuration audit community?
>
>I would really like to see us expand from this limitation to the
>configuration audit community. Incident handlers, for example, may also

>find CCE useful.
>
>>
>>Languages (e.g. like OVAL) are certainly needed but they aren't
>>sufficient.  Check logic needs to be written, or generated.   Some
>>suggest that OS/application vendors should generate this content but
>>others have noted the lack of economic incentives.
>>
>>To further complicate this, our use case analysis (both for CCE and
>>other related efforts) has repeatedly and consistently shown that
>>software vendors think of "configuration issues" in very different
>>terms than the configuration audit/management community does.  So,
>>there's the strong possibility for the "be careful what you wish for"
>>problem.  Machine consumable content that is auto-generated by a
>>process that is centered more on feature & code-base management may
>>not
>
>>be useful for configuration audit.
>
>Yes, we should be careful what we wish for, but right now I feel that
>we're at a point of flushing out some important semantic differences.
>Consider a world in which CCE, the specification, is used outside just
>the security context.  Would we still call it CCE?
>
>Also, my argument here is that, especially for incident response
>capabilities, understanding configuration issues from the software
>vendors' point of view is, perhaps, as important as viewing
>configuration issues in the security context (in fact, when
>investigating an incident, aren't all "configuration issues"
>security-related?).
>
>>
>>Another consideration... I don't see large scale automated
>>configuration audit content provisioning happening until the content
>>itself is largely auto-generated from other data stores.
>
>This is an important point to make and to be heard.
>
>>
>>As many of you know, I'm a nut about vintage bicycles.  I ride a 1979
>>Trek.  It was handmade in a barn in Madison, WI and many of the early
>>Trek workers went on to notable careers as custom hand-made bike
>>builders.  In fact, they had to find other work because by 1989, Trek
>>bikes were pretty much all produced by precision robotics.  As much of

>>a fan of hand-made bikes as I am, Trek's move to automation allowed
>>them to become an industry giant.
>>
>>I think configuration content at the level you're talking about will
>>need to be auto-created, at least to some degree.
>
>I agree.  We're at the point where we ought to be considering how this
>can happen.
>
>>
>>
>>Dave Mann wrote:
>>>>3) Since the issue of CCE's future has been raised, my sense is that

>>>>the important success goals for CCE's near to mid-term progress
>include:
>>>>+ Broader coverage of security guides and audit tool issues by CCE.
>>
>>Adam wrote:
>>>I'm wondering if this isn't too narrow a focus.  This relegates CCE
>>>to
>
>>>security-specific settings, and it's clear that this industry is
>>>coming to the realization that security-specific processes really
>>>support IT processes, and that IT processes encompass more than
>>>security-specific settings.
>>
>>In terms of vision, it is too narrow and that has been CCE's position
>>since the beginning.
>>
>>But, in terms of current realities it remains something of a stretch
>>goal for us.  We aren't close to hitting that goal yet.
>>
>>Even if we drop the hopes for machine readable content related to CCEs

>>and just stick with CCE's as currently defined, broadening the scope
>>beyond what is captured in security guides and config audit tools will

>>require that we auto-generate CCE data.  This turns out to be pretty
>hard.
>>
>>As many of you know, Microsoft has been working with the CCE team to
>>auto-generate CCE candidates.  We've had some wonderful initial
>>successes along with the expected hiccups.  IMO, they're to be
>>commended for working on this as hard as they have. They are certainly

>>well out in front of anybody else in this regard.
>
>I didn't realize this is ongoing work.  Happy to hear it.
>
>>
>>One of the issues that we've encountered (and I must emphasize this,
>>we've seen this with every single OS/App vendor we've worked with) is
>>that their internal data is fundamentally different from what is
>>codified in CCE. There are significant tensions around level of
>>abstraction issues for instance.  Software manufacturing is different
>>from configuration management and this is to be expected and I in no
>>way fault Microsoft or any other software vendor for it.
>
>So, perhaps this is another point of evidence to substantiate an
>assertion that we're at a place where we need to consider the two as
>separate, but related definitions.  I'm not sure of the "right" answer
>- there are likely many ways to figure this out.
>
>>
>>So, let me toss out a challenge to my friends in the configuration
>>audit/management space?
>>
>>Would your company be willing to work with us to attempt to
>>auto-generate CCE candidates from your internal configuration
>>audit/management repositories?
>
>I hope the answer is yes from many.
>
>>
>>
>>-Dave
>>==================================================================
>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>------------------------------------------------------------------
>>[hidden email] | cell:<a href="tel:[phone]" value="[phone]">781.424.6003
>>==================================================================
>>
>>
>>
>>>
>>>>CCE was founded on 5 documented use cases as discussed in section 4
>>>>of the CCE overview paper [1].  In all 5 of the scenarios, the
>>>>correlation is done by humans, even the 4th use case in which
>>>>results
>
>>>>from multiple audit tools are integrated.
>>>
>>>This is an excellent point.  I can see a future, however, where more
>>>use cases are added, based on the inclusion of other processes.
>>>Consider a SIEM tool that detects five failed logon attempts over an
>>>hour's time followed by a good logon.  Traditionally, we would rely
>>>on
>
>>>a human to go figure out whether that incident is benign.  With
>>>configuration data, however, we could bolster that correlation to
>>>trigger only when particular configuration items are set in a
>>>particular way, if a configuration item subsequently changed, and so
>>>on.
>>>
>>>This is a problem not just limited to CCE, I think.  I'd also like to

>>>see things like: Tell me whether that user recently changed their
>>>password, because if they did, then the probability that this
>>>incident
>
>>>is benign just went up.
>>>
>>>>
>>>>2) If there is a clear and compelling need for machine processable
>>>>information regarding configuration controls that is not being met
>>>>by
>
>>>>other current efforts [2], the following questions should be worked
>>>>through:
>>>>+ What use cases should it support?
>>>
>>>This is probably the first question to answer, but I assert that to
>>>answer this question properly we need to identify the processes we
>>>would intend to support.  This is something that seems to be "common
>>>knowledge" in the community, but that is rarely called out
explicitly.
>>>
>>>>+ Who will create the content?
>>>>+ Who will be the guarantor of the quality of that content?
>>>>+ Should this be a government funded effort, "open source" or a
>>>>commercial venture?
>>>>
>>>>We're happy to have that discussion unfold here on this list, even
>>>>if
>
>>>>the end result isn't (and shouldn't be) a part of CCE.
>>>>
>>>
>>>>+ A content management and provisioning system capable of scaling to
>>>>this
>>>>scope
>>>>+ A formalized adoption program (similar to CVE's) that defines
>>>>+ industry
>>>>best practices for the inclusion of CCE ids into configuration
>>>>management tools and services.
>>>>+ More ubiquitous usage of CCE ids in configuration management tools

>>>>+ and
>>>>services.
>>>>
>>>>
>>>>Just to reiterate point 2)... Please feel free to continue the
>>>>discussion here.  It's an important issue and needs to be discussed.
>>>
>>>This is good.  I don't know if CCE is the right place for what we
>>>think we need at this point, but it's certainly related.
>>>
>>>>
>>>>
>>>>[1] -
>>>>http://cce.mitre.org/documents/Introduction_to_CCE_White_Paper_July_
>>>>2
>>>008.p
>>>>df
>>>>
>>>>[2] - If OVAL is sufficient to meet the use cases (unknowable till
>>>>the use cases are defined), we note that both NIST SCAP/FDCC and
>>>>MITRE's
>>>OVAL
>>>>Repository provide sets of machine processable checks.  The first is

>>>>funded by the US Government and the latter is more of an open source

>>>>effort (and traditionally, more focused on vulnerabilities than
>>>>configuration controls).
>>>>
>>>>-Dave
>>>>==================================================================
>>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>>------------------------------------------------------------------
>>>>[hidden email] | cell:<a href="tel:[phone]" value="[phone]">781.424.6003
>>>>==================================================================
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]
>>>>>[mailto:[hidden email] [hidden email]] On Behalf Of

>>>>>[hidden email]
>>>>>Sent: Thursday, August 11, 2011 11:28 AM
>>>>>To: cce-working-group-list
>>>>>Subject: Capturing CCE Info
>>>>>
>>>>>This is a discussion occurring on the asset-dev working group that
>>>>>really needs to be addressed here.
>>>>>
>>>>>This effort has been one of maturing and evolving.  We struggled
>>>>>with the right level to assign CCEs and got past that hurdle.  We
>>>>>moved from v4 to v5
>>>>>to add the Luhn check digit.  Now we need to make it   usable for
>other
>>>>>efforts to really use it appropriately.
>>>>>
>>>>>Thoughts on making this useful from a programmatic perspective for
>>>>>other efforts to benefit from?
>>>>>
>>>>>Kent Landfield
>>>>>Director Content Strategy, Architecture and Standards
>>>>>
>>>>>McAfee, Inc.
>>>>>5000 Headquarters Dr.
>>>>>Plano, Texas 75024
>>>>>
>>>>>Direct: <a href="tel:%2B1.972.963.7096" value="[phone]">+1.972.963.7096
>>>>>Mobile: <a href="tel:%2B1.817.637.8026" value="[phone]">+1.817.637.8026
>>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>>
>>>>>From: Kent Landfield
>>>>><[hidden email]<mailto:[hidden email]>>
>>>>>Date: Thu, 11 Aug 2011 10:15:53 -0500
>>>>>To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>>[hidden email]<mailto:[hidden email]>>
>>>>>Subject: Re: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>This is something that has to be address in CCE.  I do not agree
>>>>>that it was intended to be a human-readable format for the long
>>>>>term. That is where is stands today because of inadequacies in how
>>>>>we deal with a CCE entry that need to be further specified, but for

>>>>>the sake of it's usability and viability, it needs to be machine
>>>>>readable.
>>>>>
>>>>>Kent Landfield
>>>>>Director Content Strategy, Architecture and Standards
>>>>>
>>>>>McAfee, Inc.
>>>>>5000 Headquarters Dr.
>>>>>Plano, Texas 75024
>>>>>
>>>>>Direct: <a href="tel:%2B1.972.963.7096" value="[phone]">+1.972.963.7096
>>>>>Mobile: <a href="tel:%2B1.817.637.8026" value="[phone]">+1.817.637.8026
>>>>>Web: www.mcafee.com<http://www.mcafee.com/>
>>>>>
>>>>>From: "Davidson II, Mark S"
>>>>><[hidden email]<mailto:[hidden email]>>
>>>>>Reply-To: "[hidden email]<mailto:[hidden email]>" <asset-
>>>>>[hidden email]<mailto:[hidden email]>>
>>>>>Date: Thu, 11 Aug 2011 09:52:00 -0500
>>>>>To: Multiple recipients of list <[hidden email]<mailto:[hidden email]
>>>>>[hidden email]>>
>>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>CCE is intended to be a human-readable format, not a machine
>>>>>readable format. For that reason, I think it will be difficult if
>>>>>not infeasible to discern CCE metadata in a programmatic way.
>>>>>
>>>>>Relevant snippet for context:
>>>>><asr:metadata>
>>>>><asrm:cce_metadata>
>>>>><asrm:param_state>disabled</asrm:param_state>
>>>>><asrm:param_setting param="roles">
>>>>><asrm:setting>admin</asrm:setting>
>>>>><asrm:setting>user</asrm:setting>
>>>>></asrm:param_setting>
>>>>></asrm:cce_metadata>
>>>>></asr:metadata>
>>>>>I think it will be difficult to fill the CCE
>>>>>param_state/param_setting for the following reasons:
>>>>>1) There is not a machine-readable mapping from CCE to CCE
>>>>>parameters
>>>>>2) There is not a machine-readable mapping from CCE parameters to
>>>>>actual values (IE, enabled=0, disabled=1, etc)
>>>>>3) There is not a machine-readable mapping from CCE to method for
>>>>>collecting the value (technical mechanism)
>>>>>
>>>>>I think if you had the data to communicate, this structure would
>>>>>accommodate that data effectively. I'm not sure how we will
>>>>>actually
>
>>>>>get the data to populate this structure.
>>>>>
>>>>>-Mark
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]
>>>>>[hidden email]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
>>>>>Sent: Thursday, August 11, 2011 10:21 AM
>>>>>To: Multiple recipients of list
>>>>>Subject: RE: Follow-up from Last Call about Capturing CCE Info
>>>>>(UNCLASSIFIED)
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>I can't think of a better alternative.  Not sure how well we will
>>>>>be
>
>>>>>able to use this, but it appears to meet the need.  I'm worried
>>>>>about the lack of structure.  Can we specify schemas for the known
>>>>>types of metadata (the CCE, specifically)?  I'm also concerned that

>>>>>the CCE structure doesn't really help a tool automate the
>>>>>translation of checks into structured results.
>>>>>
>>>>>Looking at the schemas & documents themselves, I can't figure out
>>>>>why you've structured the documents the way you have.  If all
>>>>>idents
>
>>>>>in a report are in the same system, you should only have to specify

>>>>>the system once at the beginning, it doesn't make sense to
>>>>>re-specify the system for each result value set.  For results
>>>>>against a common ident, the results should be subordinate elements
>>>>>with relevant group-by attributes.
>>>>>
>>>>>Joseph L. Wolfkiel
>>>>>Engineering Group Lead
>>>>>DISA PEO MA/IA52
>>>>><a href="tel:%28301%29%20225-8820" value="[phone]">[phone]
>>>>>[hidden email]<mailto:[hidden email]>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]
>>>>>[hidden email]] On Behalf Of Halbardier, Adam
>>>>>Sent: Monday, August 08, 2011 1:46 PM
>>>>>To: Multiple recipients of list
>>>>>Subject: Follow-up from Last Call about Capturing CCE Info
>>>>>
>>>>>All,
>>>>>
>>>>>
>>>>>On the last call we discussed the difficulty with reporting against

>>>>>CCEs separate from the XCCDF benchmark and profile that checked the

>>>>>CCE.  I took an action to look at CCE and try to come up with a
>>>>>mechanism that could possibly support such a case.  Attached is a
>>>>>possible solution.
>>>>>Basically,
>>>>>I added a "metadata" construct to the result element that can
>>>>>capture arbitrary metadata about the setting of an ident.  For
>>>>>simpler idents, we just capture the relevant information as
>>>>>parameters on the result (see the CPE example).  For the CCE
>>>>>example, we can use the metadata element to capture the CCE
>>>>>settings.  I attached an extension schema for the CCE metadata.
>>>>>Basically, a CCE has one or more parameters.  Scanning through the
>>>>>CCE spreadsheets, I think there are two categories of parameters.
>>>>>One
>>>>>category is what I'm calling "state" parameters.  Those are
>>>>>parameters that just have a value, without a name associated with
>>>>>the parameter (e.g., "enabled/disabled").  For the first !
>>>>>category, the name of the parameter is the setting.  The second
>>>>>category of parameters is a named parameter that has a value, or
>>>>>list of values, associated with it (e.g., user roles).  In this
>>>>>case, the parameter needs to be identified, along with the value or

>>>>>list of values for the instance of the CCE.  The second category I
>>>>>called "setting param".
>>>>>
>>>>>
>>>>>A CCE metadata construct can have one or more of each of the two
>>>>>types of parameters.  The parameters MUST be provided in the same
>>>>>order as documented in the CCE.  The one potential disconnect here
>>>>>is that the values for "setting params" isn't enumerated (and I
>>>>>don't think it can be), so that could lead to data disconnects, but

>>>>>it might be a limitation we just have to live with in the
near-term.
>
>>>>>Please provide thought/feedback on this approach, and if you think
>>>>>it will solve the current needs.
>>>>>
>>>>>
>>>>>-Adam
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>>
>>>>>Classification:  UNCLASSIFIED
>>>>>Caveats: NONE
>>>>
>>>
>>
>

--
Mike Murray
Michael Murray and Associates

http://www.episteme.ca
Phone - 773-360-0658

Twitter - @mmurray

Facebook - michael.l.murray

LinkedIn - mikemurray

Skype - mike.murray
Aim - mmepisteme

[Mann, Dave]

TK wrote:
>At the core of this discussion is simply the question: How does a CCE
>come in to being?
>This is ontogenesis.  http://en.wikipedia.org/wiki/Ontogeny
>It is the only way to get complex systems to stabilize.

^ This! ^

I'll take a stab at it.

IMO, CCEs are the social objects that fulfill the needs of the pairwise sets of parties that are described in the 5 foundational use case scenarios of CCE:
1) Security guide author <-> System Designer
2) Internal Config Mgmt Lifecyle: Designer <-> Tester <-> Implementer
3) Configuration Auditor <-> Config Audit Tool Vendor (as mediated through the tool)
4) Configuration Audit Tool Vendors <-> Internal Report Creator
5) Internal Audit <-> External Audit

In each case, there are rights and responsibilities that these social pairs hold each other to.  In the words of Anne Rawls (who I believe was quoting Garfinkel), it is not what the utterance means, it's what it does in the context of the social interaction.  CCEs are the things that these pairs of people are holding each other accountable for in some way.

You will note in the CCE Overview paper, we document each use case with (at least) two personas, not one.  We document the ways that they hold each other accountable in some communication scenario and how it is that CCEs fulfill that need.   I refer to this approach of use case documentation as "bilateral end-point use case analysis".  Rawls and I have a paper that lays the theoretic foundations for this [1] but the CCE white paper is the best example of it in practice that I have.

The point to be made here is that if you have a different set of personas engaged in different sets of mutual accountabilities, then you will create the need for different social objects.  This explains why books and cars have multiple identifiers associated with them.  Different sets of shared rights and responsibilities are the "ontogenesis" of different ID structures.

This is why in one of my earlier emails on this topic that I asked for use cases that discussed who was producing information and who was consuming the information.  

FWIW, I have a hunch that the uses that have been hinted at so far will end up coalescing more around a level of abstraction that is one decided step below CCE's loa - more in line with CCE Technical Mechanisms or what has been discussed at the NIST conferences and Developer Days events for remediation issues.   But it's too early to tell.  

Who are the personas who will produce and use this information?  Which ones are in direct communication with others?  What are they trying to accomplish with their communications and in what ways are they holding each other accountable?

Regarding the stability of the social objects, they are only as stable as the social processes that create and sustain them.  Sometimes the social processes change dramatically and the social objects (and their standards and data structures) die.  Other times, they get "locked in" and are impossible to change.


[1] MITRE Technical Report - "“The Thing is … What is Our „What‟?”: An Ethnographic Study of a Design Team‟s Discussion of “Object” Clarity as a Problem in Designing an Information System to Facilitate System Interoperability"   Anne Warfield Rawls(Bentley College) and David Mann (The MITRE Corporation) - available on request.


-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:[hidden email] | cell:781.424.6003
==================================================================

[Adam Montville]

I think I need more coffee...

On 8/22/11 1:24 PM, "Mann, Dave" <[hidden email]> wrote:

>TK wrote:
>>At the core of this discussion is simply the question: How does a CCE
>>come in to being?
>>This is ontogenesis.  http://en.wikipedia.org/wiki/Ontogeny
>>It is the only way to get complex systems to stabilize.
>
>^ This! ^
>
>I'll take a stab at it.
>
>IMO, CCEs are the social objects that fulfill the needs of the pairwise
>sets of parties that are described in the 5 foundational use case
>scenarios of CCE:
>1) Security guide author <-> System Designer
>2) Internal Config Mgmt Lifecyle: Designer <-> Tester <-> Implementer
>3) Configuration Auditor <-> Config Audit Tool Vendor (as mediated
>through the tool)
>4) Configuration Audit Tool Vendors <-> Internal Report Creator
>5) Internal Audit <-> External Audit
>
>In each case, there are rights and responsibilities that these social
>pairs hold each other to.  In the words of Anne Rawls (who I believe was
>quoting Garfinkel), it is not what the utterance means, it's what it does
>in the context of the social interaction.  CCEs are the things that these
>pairs of people are holding each other accountable for in some way.
>
>You will note in the CCE Overview paper, we document each use case with
>(at least) two personas, not one.  We document the ways that they hold
>each other accountable in some communication scenario and how it is that
>CCEs fulfill that need.   I refer to this approach of use case
>documentation as "bilateral end-point use case analysis".  Rawls and I
>have a paper that lays the theoretic foundations for this [1] but the CCE
>white paper is the best example of it in practice that I have.
>
>The point to be made here is that if you have a different set of personas
>engaged in different sets of mutual accountabilities, then you will
>create the need for different social objects.  This explains why books
>and cars have multiple identifiers associated with them.  Different sets
>of shared rights and responsibilities are the "ontogenesis" of different
>ID structures.
>
>This is why in one of my earlier emails on this topic that I asked for
>use cases that discussed who was producing information and who was
>consuming the information.
>
>FWIW, I have a hunch that the uses that have been hinted at so far will
>end up coalescing more around a level of abstraction that is one decided
>step below CCE's loa - more in line with CCE Technical Mechanisms or what
>has been discussed at the NIST conferences and Developer Days events for
>remediation issues.   But it's too early to tell.
>
>Who are the personas who will produce and use this information?  Which
>ones are in direct communication with others?  What are they trying to
>accomplish with their communications and in what ways are they holding
>each other accountable?
>
>Regarding the stability of the social objects, they are only as stable as
>the social processes that create and sustain them.  Sometimes the social
>processes change dramatically and the social objects (and their standards
>and data structures) die.  Other times, they get "locked in" and are
>impossible to change.
>
>
>[1] MITRE Technical Report - "“The Thing is … What is Our „What‟?”: An
>Ethnographic Study of a Design Team‟s Discussion of “Object” Clarity as a
>Problem in Designing an Information System to Facilitate System
>Interoperability"   Anne Warfield Rawls(Bentley College) and David Mann
>(The MITRE Corporation) - available on request.
>
>
>-Dave
>==================================================================
>David Mann | Principal Infosec Scientist | The MITRE Corporation
>------------------------------------------------------------------
>e-mail:[hidden email] | cell:781.424.6003
>==================================================================
>
>