Quantcast

[CCE-WORKING-GROUP-LIST] Scope of CCE?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[CCE-WORKING-GROUP-LIST] Scope of CCE?

Mann, Dave
This question is so important, that I think it makes sense to break it off of the "Internal Checklists" thread and to give it its own thread.

What should be the scope of CCE?
a) Only controls mentioned in prominent, public security guides (the traditional CCE answer)
b) All configurable controls in a platform, as defined by the vendor.

The original, longer-winded asking of this question follows...

Regarding automating CCE content generation, Kelly suggested:
First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.

Dave responds:
Kelly is making a significant suggestion here that merits serious consideration by the CCE Working Group.  

The question that it begs is, what is the scope of CCE?

To this end, I would like to turn this discussion back towards the subject heading.  Is there still relevance to the concept of a "security checklist"?

MITRE has been involved with discussions regarding CCE content creation with several primary source vendors, including Microsoft.   Kelly's suggestion is consistent with what we are hearing from other primary source vendors. They have (or are getting close to having) the ability to auto-generate IDs for all controls in a given platform.

There are 2 important implications here.  First is a matter of scale.  Microsoft and other similar vendors have the ability to produce thousands and even tens of thousands controls for a single platform.

Second is a matter of security relevance.  Per strong guidance from the Working Group, CCE has traditionally restricted its scope to only those controls whose security relevance was documented through its inclusion in published security guides or security audit tools.

Is there a case to be made that primary source vendors should produce proprietary IDs for all controls in their products and as a both/and solution that CCE ids should be reserved to identify a smaller subset of controls that are considered to have security importance by the security audit community?

[NOTE: this would somewhat mirror the use of CVE.  Vendors track all bugs and software defects, but only smaller subset of bugs have security relevance and are given CVE ids.]

In past Working Group discussions (I'm thinking here primarily about past Developer Days events), some members of the security audit tool community made a strong argument for keeping CCE's traditional "guardrail" scoping decision of only giving IDs to those controls in security guides.  Paraphrasing, the line of argument was, "Customer expectation is such that if there is a CCE then our customers expect us to create an audit check for the issue.  If there are CCE ids for every possible control, we would not be able to write enough audit checks to keep up."

Thoughts?

Should CCE IDs be given for all possible controls in a platform?

Or only for those that are documented in a security guide?


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

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Kelly Hengesteg
Sent: Monday, October 08, 2012 7:05 PM
To: Jesper Jurcenoks; cce-working-group-list
Cc: Michael Tan
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Jesper and colleagues,
I agree that is a great question, can we make the process easier:). I have to tell you I (we) at Microsoft are really frustrated with the current process. It is currently manual, very expensive and does not meet the needs of the authors, especially when you are participating out of goodwill for the community.

Instead of going on for a long time about what doesn't work, I would like to talk about what we as authors should expect and want to make the process better.

First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.

What would it look like. I foresee a service in which I can sign in to the CCE-ID assignment service. I can then upload my CCE-ID_request.xml. The service would walk through a series of tests that include unique CCE-ID and CCE-ID descriptions, parameters, technical mechanism and reference (optional). Depending on whether I uploaded an update or request for new CCE's I would get the appropriate test cases.  The service would then provide me with one of two results, success/failure.  In the case of success, I would get an updated XML file with the randomly assigned new CCE-ID's (when requesting new),  If my XML had errors, I would get a failure report, outing specifically what CCE description was not passing and cite the test case to enable quick updates.

This would provide me an incentive to continue investing in this standard.  Today, it is too expensive for us to continue with manual process we have in place today. If we truly want vendors and the community to continue making investments here, we have to make it more efficient.

Thoughts? How can we make this a reality?

Thanks,
Kelly


-----Original Message-----
From: Jesper Jurcenoks [mailto:[hidden email]]
Sent: Wednesday, October 3, 2012 10:09 PM
To: [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Dave and List.

I want to turn the question it's head.

Are we questioning the need for CCE-ids because assigning CCE's is cumbersome compared to the rewards?

If that is the case then maybe we should ask: If issuing of CCE ids is a barrier to use and adoption, then instead of getting rid of CCE-ids, can we make the process of assigning CCE-ids easier on everybody ?

JJ


-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Tuesday, October 02, 2012 1:02 PM
To: [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Nod.  Agreed.

If configuration information were like automobiles or books, then the producers of the car or book could be counted on to register the VIN or ISBN.

This is not the case with configuration controls in software.

We typically have multiple sources of configuration control information for the same platform and the primary source vendor may or may not be a participant.

In vulnerability management, pretty much all aspects of VM require that many sources of information be consulted, making CVE a near necessity.

It could be argued (this is what we're trying to discern) that when most end users deal with a specific platform, they typically only need to navigate between 2 sources, say a security guide of their choosing and their 3rd party tool.  It could also be argued that some/many users rely primarily on the intelligence of their 3rd party tools and never even consult configuration guides.

If this conjecture is true, then it may be that end users will be able to perform their configuration management duties just fine by relying on proprietary IDs.

My first email on this subject is based on the 5 core use cases that CCE is founded on.   We are trying to determine if these use cases break if there was no CCE and if there is only proprietary IDs.

If people believe that things will break without CCEs, please try to describe which use cases fail (per my first email).

SIDE COMMENT THAT CCE HAS BEEN MAKING PUBLICLY FOR SOME TIME:  CCE creation and coordination would be infinitely easier if publishers of configuration information followed the lead of their vulnerability information peers by publishing their own proprietary IDs.  This would help pre-atomize their proprietary data and would give concrete references into their information sets that could be used to help manage the CCE process much better.    But this note is a digression from the main question.

Are CCE's really needed?


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


-----Original Message-----
From: Quinn, Stephen [mailto:[hidden email]]
Sent: Tuesday, October 02, 2012 3:29 PM
To: Banghart, John; Mann, Dave; cce-working-group-list
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Folk,

  John is correct... Historically, this has been an organizing principle for government authors of checklists.  The CCE identifier and subsequent description eliminates the need for secondary conversations that ensure we are discussing the same configuration item (I.e. Account Lockout vs lockout duration, etc).


Steve
NIST

----- Original Message -----
From: Banghart, John [mailto:[hidden email]]
Sent: Tuesday, October 02, 2012 03:19 PM
To: Mann, Dave <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Dave,

But would guidance authors really use their own ID's?  If Microsoft tells me that "Password Length" = ID1234, then why wouldn't I use that when creating the USGCB?  If they don't tell me, and I use my own and DISA uses their own, then how would we correlate between the guidance documents?  It seems to me that if that happened, I would call up DISA and we would create some sort of mapping.  Then that would be mapped to CIS, then mapped to something else, until we all realized that we need a common identifier and create CCE.  :)

-John

On 10/2/12 3:10 PM, "Mann, Dave" <[hidden email]> wrote:

>John,
>
>Yes, that is the question we're asking, although you're asking it in an
>even more stark manner.
>
>I don't think it is true that there is ever a single authoritative
>source of configuration information.  Despite the fact the primary
>source vendors may produce configuration guidance (this varies widely),
>various organizations still produce (or oversee the production of)
>security guides that still get used.  Add to this that I suspect it is
>still common for end users to rely on proprietary content embedded in
>their 3rd party audit and management tools.
>
>Better to say that configuration management is easier because a much
>smaller number of sources must be managed.
>
>Or not?
>
>That's what we're asking.
>
>If all publishers of configuration information (NIST, DISA, CIS,
>McAfee, Symantec, nCircle, etc., Microsoft, Apple, RedHat, Oracle,
>etc.) all used proprietary IDs, would there still be a need for CCE ids?
>
>-Dave
>==================================================================
>David Mann | Principal Infosec Scientist | The MITRE Corporation
>------------------------------------------------------------------
>e-mail:[hidden email] | cell:781.424.6003
>==================================================================
>
>
>-----Original Message-----
>From: Banghart, John [mailto:[hidden email]]
>Sent: Tuesday, October 02, 2012 2:59 PM
>To: Mann, Dave; cce-working-group-list
>Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>Created and Used?
>
>Dave,
>
>So the suggestion is that vulnerability information is hard because it
>comes from many sources and therefore requires a commonly shared ID,
>but configuration information really only has one authoritative source,
>and so therefore might not require anything other then a proprietary ID.
>
>Is that consistent with what you are saying?
>
>-John
>
>
>On 10/2/12 2:46 PM, "Mann, Dave" <[hidden email]> wrote:
>
>>John,
>>
>>Here is my crude, biased and short history of the vulnerability space
>>compared to the configuration space.
>>
>>----
>>Vulnerabilities
>>----
>>c1990 - Most vendors suppressed vulnerability information and followed
>>the silent patch model.
>>
>>c1995 - Thanks in large measure to mailing lists like Bugtraq, the
>>expected practice for vulnerability information moved to full
>>disclosure and then responsible disclosure. Disclosure of
>>vulnerability information was then accompanied by proprietary IDs,
>>including: ISS X-Force IDs, Security Focus BIDs and CERT-CC Advisory numbers.
>>
>>c1999 - CVE was launched as a cross-reference between established
>>proprietary IDs, not as a replacement for them.  In the years that
>>followed, publishers of vulnerability information paid the internal
>>costs of integrating CVE ids in response to market demand from their
>>end users who need to correlate vulnerability information across multiple sources.
>>
>>-----
>>Configuration Controls
>>-----
>>c1995 - Configuration information mostly published in prose security
>>guides and technical support repositories (e.g. Unix man pages,
>>Microsoft TechNet).  Proprietary IDs were not used. (DISA was an early
>>outlier.)
>>
>>2006 - CCE was established.  Publishers of configuration information
>>still weren't publishing their configuration information with their
>>own proprietary IDs.
>>
>>
>>I suspect that one of the key differences between the two domains has
>>been one of volume.  "Names" for vulnerabilities like "ping of death"
>>were entirely overrun by the sheer volume of information in that space.
>>
>>NOTE: publishers of vulnerability information turned to using
>>proprietary IDs *BEFORE* CVE existed
>>
>>In contrast, I suspect that publishers of configuration information
>>(guide authors and primary source vendors) as well as their key
>>customers are coming to the understanding that "names" for controls is
>>likewise being overwhelmed by volume.  But, they are coming to this
>>realization
>>*AFTER* CCE was created.
>>
>>Hence (I believe) the incorrect assumption on their part that they can
>>use CCE IDs as primary keys for their configuration information.
>>
>>The question remains, if publishers used proprietary IDs, would there
>>still be a need for CCE?
>>
>>For CVE, the answer is a resounding and clear, "Yes."
>>
>>
>>-Dave
>>==================================================================
>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>------------------------------------------------------------------
>>e-mail:[hidden email] | cell:781.424.6003
>>==================================================================
>>
>>
>>-----Original Message-----
>>From: Banghart, John [mailto:[hidden email]]
>>Sent: Tuesday, October 02, 2012 2:02 PM
>>To: Mann, Dave; cce-working-group-list
>>Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>>Created and Used?
>>
>>Dave,
>>
>>You suggest below that product vendors aren't creating their own
>>configuration ID's because of CCE.  However, they weren't creating
>>them before CCE was invented.  What has changed that leads the CCE
>>team to believe that CCE is a barrier?
>>
>>-John
>>
>>
>>On 10/2/12 1:49 PM, "Mann, Dave" <[hidden email]> wrote:
>>
>>>Folks,
>>>
>>>We really need your input.
>>>
>>>If all producers of configuration information (security guide
>>>authors, primary source vendors, security tool vendors) tagged their
>>>published configuration information with their own proprietary IDs
>>>(as is common in the vulnerability management space), would there
>>>still be a compelling need for CCE IDs?
>>>
>>>This is definitely a case where silence means, "No."
>>>
>>>-Dave
>>>==================================================================
>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>------------------------------------------------------------------
>>>e-mail:[hidden email] | cell:781.424.6003
>>>==================================================================
>>>
>>>-----Original Message-----
>>>From: Mann, Dave
>>>Sent: Wednesday, September 26, 2012 2:34 PM
>>>To: cce-working-group-list
>>>Subject: How Are Internal Checklists Created and Used?
>>>
>>>Folks,
>>>
>>>We need your input.  Please respond to the following questions...
>>>
>>>1) How do large companies and enterprises create their own, internal
>>>configuration checklists?
>>>
>>>2) How many external sources of information do they typically draw from
>>>for any given platform?   Do they rely primarily on published security
>>>guides, pre-built capabilities in their configuration
>>>audit/management tools or documentation from the software's vendor?
>>>
>>>3) How do they audit against their internal checklists?
>>>Specifically, how do they find audit checks that correspond to
>>>controls listed in their internal checklists?
>>>
>>>4) Is it common for companies to use multiple configuration
>>>audit/management tools for the same platform (perhaps across multiple
>>>business units) and is it common for them to need to consolidate the
>>>results?
>>>
>>>5) Lastly, how do they communicate with auditors and regulators
>>>regarding their configuration posture?  What form of documentation to
>>>they use?
>>>
>>>
>>>
>>>We are currently revisiting CCE's core value proposition.   CCE has been
>>>envisioned to be "CVE for configuration controls" and like CVE, CCE's
>>>goal has been to provide cross-reference IDs that could be used to
>>>quickly and accurately correlate across multiple sources of
>>>configuration information.
>>>
>>>If you are involved in doing about any aspect of vulnerability
>>>management, you must quickly and accurately find vulnerability
>>>information across multiple sources of information.  The general
>>>question we are asking can be stated as follows:
>>>  Is the same thing true for configuration management?
>>>
>>>For over a year, the CCE team has been advocating that all producers
>>>of configuration information publish their own proprietary IDs and to
>>>embed them in all forms of their published configuration guidance or tools.
>>>This is how things are done in the vulnerability management space and
>>>it is very successful.  Every vulnerability database uses their own
>>>ID scheme [1].  The same is true for vulnerability alerting services,
>>>vulnerability assessment products and security bulletins.   This allows
>>>each provider to publish their information with no hard dependency on
>>>CVE.  CVE does *not* replace proprietary IDs.  Instead, CVE IDs are
>>>added as cross-references.  In fact, the existence of proprietary IDs
>>>make CVE possible.
>>>
>>>In stark contrast, the use of proprietary IDs for configuration
>>>information is nearly unheard of [2].  Instead, controls tend to be
>>>referred to using English based names that may correspond to labels
>>>in GUIs or command names.
>>>
>>>We are increasingly becoming concerned that the existence of CCEs is
>>>dissuading publishers of configuration information from issuing their
>>>own proprietary IDs and that this, in turn, is creating unrealistic
>>>dependencies on CCE.  Namely, publishers need to be able to define
>>>controls in anyway that makes sense for them and their stakeholders,
>>>regardless of whether or not it conflicts with another organizations
>>>definition.
>>>
>>>We urge all publishers of configuration information to use their own
>>>IDs.
>>>
>>>In the next breath we ask, if all configuration information
>>>publishers used their own proprietary IDs (as they do in the
>>>vulnerability space), would there still be a need for a common cross-reference ID like CCE?
>>>
>>>
>>>
>>>[1] The major exception to this is the NIST National Vulnerability
>>>Database, which adds additional information to CVE data.
>>>
>>>[2] One notable exception to this are DISA's STIGs, which use "STIG
>>>IDs".
>>>
>>>-Dave
>>>==================================================================
>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>------------------------------------------------------------------
>>>e-mail:[hidden email] | cell:781.424.6003
>>>==================================================================
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [CCE-WORKING-GROUP-LIST] Scope of CCE?

Blake Frantz
+1 to for all configurable knobs that the community is willing to create a CCE for.

Reasons for that:

1. If I understand DaveM correctly, then primary vendors are developing automation capabilities to generate CCEs for all configuration controls in their respective products. I say CCE all of them. If the vendors are auto-generating IDs, then it's likely more expensive to ask them to filter out items that are not security-relevant. It already costs vendors time/money to generate CCEs  - the cheaper we make it for them the better.

2. What is irrelevant to security today may be relevant tomorrow. If we limit CCEs to only those configuration surfaces that have security relevance today, we may not have a CCE when we need it. Overtime, IMO, the speed by which an organization can mitigate risk associated with new vulnerabilities becomes increasingly critical. CCE can help with that. Particularly, for new vulnerabilities that have no patch but do have a configuration-based workaround. Imagine how awesome it will be if/when vendor advisories are enriched with CCEs and delivered directly to your vulnerability scanner which in-turn scans all applicable assets for the state of the CCE the vendor said will mitigate that hot new vuln until a patch is shipped.

Blake

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Thursday, October 11, 2012 11:26 AM
To: [hidden email]
Subject: [CCE-WORKING-GROUP-LIST] Scope of CCE?

This question is so important, that I think it makes sense to break it off of the "Internal Checklists" thread and to give it its own thread.

What should be the scope of CCE?
a) Only controls mentioned in prominent, public security guides (the traditional CCE answer)
b) All configurable controls in a platform, as defined by the vendor.

The original, longer-winded asking of this question follows...

Regarding automating CCE content generation, Kelly suggested:
First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.

Dave responds:
Kelly is making a significant suggestion here that merits serious consideration by the CCE Working Group.  

The question that it begs is, what is the scope of CCE?

To this end, I would like to turn this discussion back towards the subject heading.  Is there still relevance to the concept of a "security checklist"?

MITRE has been involved with discussions regarding CCE content creation with several primary source vendors, including Microsoft.   Kelly's suggestion is consistent with what we are hearing from other primary source vendors. They have (or are getting close to having) the ability to auto-generate IDs for all controls in a given platform.

There are 2 important implications here.  First is a matter of scale.  Microsoft and other similar vendors have the ability to produce thousands and even tens of thousands controls for a single platform.

Second is a matter of security relevance.  Per strong guidance from the Working Group, CCE has traditionally restricted its scope to only those controls whose security relevance was documented through its inclusion in published security guides or security audit tools.

Is there a case to be made that primary source vendors should produce proprietary IDs for all controls in their products and as a both/and solution that CCE ids should be reserved to identify a smaller subset of controls that are considered to have security importance by the security audit community?

[NOTE: this would somewhat mirror the use of CVE.  Vendors track all bugs and software defects, but only smaller subset of bugs have security relevance and are given CVE ids.]

In past Working Group discussions (I'm thinking here primarily about past Developer Days events), some members of the security audit tool community made a strong argument for keeping CCE's traditional "guardrail" scoping decision of only giving IDs to those controls in security guides.  Paraphrasing, the line of argument was, "Customer expectation is such that if there is a CCE then our customers expect us to create an audit check for the issue.  If there are CCE ids for every possible control, we would not be able to write enough audit checks to keep up."

Thoughts?

Should CCE IDs be given for all possible controls in a platform?

Or only for those that are documented in a security guide?


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

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Kelly Hengesteg
Sent: Monday, October 08, 2012 7:05 PM
To: Jesper Jurcenoks; cce-working-group-list
Cc: Michael Tan
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Jesper and colleagues,
I agree that is a great question, can we make the process easier:). I have to tell you I (we) at Microsoft are really frustrated with the current process. It is currently manual, very expensive and does not meet the needs of the authors, especially when you are participating out of goodwill for the community.

Instead of going on for a long time about what doesn't work, I would like to talk about what we as authors should expect and want to make the process better.

First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.

What would it look like. I foresee a service in which I can sign in to the CCE-ID assignment service. I can then upload my CCE-ID_request.xml. The service would walk through a series of tests that include unique CCE-ID and CCE-ID descriptions, parameters, technical mechanism and reference (optional). Depending on whether I uploaded an update or request for new CCE's I would get the appropriate test cases.  The service would then provide me with one of two results, success/failure.  In the case of success, I would get an updated XML file with the randomly assigned new CCE-ID's (when requesting new),  If my XML had errors, I would get a failure report, outing specifically what CCE description was not passing and cite the test case to enable quick updates.

This would provide me an incentive to continue investing in this standard.  Today, it is too expensive for us to continue with manual process we have in place today. If we truly want vendors and the community to continue making investments here, we have to make it more efficient.

Thoughts? How can we make this a reality?

Thanks,
Kelly


-----Original Message-----
From: Jesper Jurcenoks [mailto:[hidden email]]
Sent: Wednesday, October 3, 2012 10:09 PM
To: [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Dave and List.

I want to turn the question it's head.

Are we questioning the need for CCE-ids because assigning CCE's is cumbersome compared to the rewards?

If that is the case then maybe we should ask: If issuing of CCE ids is a barrier to use and adoption, then instead of getting rid of CCE-ids, can we make the process of assigning CCE-ids easier on everybody ?

JJ


-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Tuesday, October 02, 2012 1:02 PM
To: [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Nod.  Agreed.

If configuration information were like automobiles or books, then the producers of the car or book could be counted on to register the VIN or ISBN.

This is not the case with configuration controls in software.

We typically have multiple sources of configuration control information for the same platform and the primary source vendor may or may not be a participant.

In vulnerability management, pretty much all aspects of VM require that many sources of information be consulted, making CVE a near necessity.

It could be argued (this is what we're trying to discern) that when most end users deal with a specific platform, they typically only need to navigate between 2 sources, say a security guide of their choosing and their 3rd party tool.  It could also be argued that some/many users rely primarily on the intelligence of their 3rd party tools and never even consult configuration guides.

If this conjecture is true, then it may be that end users will be able to perform their configuration management duties just fine by relying on proprietary IDs.

My first email on this subject is based on the 5 core use cases that CCE is founded on.   We are trying to determine if these use cases break if there was no CCE and if there is only proprietary IDs.

If people believe that things will break without CCEs, please try to describe which use cases fail (per my first email).

SIDE COMMENT THAT CCE HAS BEEN MAKING PUBLICLY FOR SOME TIME:  CCE creation and coordination would be infinitely easier if publishers of configuration information followed the lead of their vulnerability information peers by publishing their own proprietary IDs.  This would help pre-atomize their proprietary data and would give concrete references into their information sets that could be used to help manage the CCE process much better.    But this note is a digression from the main question.

Are CCE's really needed?


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


-----Original Message-----
From: Quinn, Stephen [mailto:[hidden email]]
Sent: Tuesday, October 02, 2012 3:29 PM
To: Banghart, John; Mann, Dave; cce-working-group-list
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Folk,

  John is correct... Historically, this has been an organizing principle for government authors of checklists.  The CCE identifier and subsequent description eliminates the need for secondary conversations that ensure we are discussing the same configuration item (I.e. Account Lockout vs lockout duration, etc).


Steve
NIST

----- Original Message -----
From: Banghart, John [mailto:[hidden email]]
Sent: Tuesday, October 02, 2012 03:19 PM
To: Mann, Dave <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Dave,

But would guidance authors really use their own ID's?  If Microsoft tells me that "Password Length" = ID1234, then why wouldn't I use that when creating the USGCB?  If they don't tell me, and I use my own and DISA uses their own, then how would we correlate between the guidance documents?  It seems to me that if that happened, I would call up DISA and we would create some sort of mapping.  Then that would be mapped to CIS, then mapped to something else, until we all realized that we need a common identifier and create CCE.  :)

-John

On 10/2/12 3:10 PM, "Mann, Dave" <[hidden email]> wrote:

>John,
>
>Yes, that is the question we're asking, although you're asking it in an
>even more stark manner.
>
>I don't think it is true that there is ever a single authoritative
>source of configuration information.  Despite the fact the primary
>source vendors may produce configuration guidance (this varies widely),
>various organizations still produce (or oversee the production of)
>security guides that still get used.  Add to this that I suspect it is
>still common for end users to rely on proprietary content embedded in
>their 3rd party audit and management tools.
>
>Better to say that configuration management is easier because a much
>smaller number of sources must be managed.
>
>Or not?
>
>That's what we're asking.
>
>If all publishers of configuration information (NIST, DISA, CIS,
>McAfee, Symantec, nCircle, etc., Microsoft, Apple, RedHat, Oracle,
>etc.) all used proprietary IDs, would there still be a need for CCE ids?
>
>-Dave
>==================================================================
>David Mann | Principal Infosec Scientist | The MITRE Corporation
>------------------------------------------------------------------
>e-mail:[hidden email] | cell:781.424.6003
>==================================================================
>
>
>-----Original Message-----
>From: Banghart, John [mailto:[hidden email]]
>Sent: Tuesday, October 02, 2012 2:59 PM
>To: Mann, Dave; cce-working-group-list
>Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>Created and Used?
>
>Dave,
>
>So the suggestion is that vulnerability information is hard because it
>comes from many sources and therefore requires a commonly shared ID,
>but configuration information really only has one authoritative source,
>and so therefore might not require anything other then a proprietary ID.
>
>Is that consistent with what you are saying?
>
>-John
>
>
>On 10/2/12 2:46 PM, "Mann, Dave" <[hidden email]> wrote:
>
>>John,
>>
>>Here is my crude, biased and short history of the vulnerability space
>>compared to the configuration space.
>>
>>----
>>Vulnerabilities
>>----
>>c1990 - Most vendors suppressed vulnerability information and followed
>>the silent patch model.
>>
>>c1995 - Thanks in large measure to mailing lists like Bugtraq, the
>>expected practice for vulnerability information moved to full
>>disclosure and then responsible disclosure. Disclosure of
>>vulnerability information was then accompanied by proprietary IDs,
>>including: ISS X-Force IDs, Security Focus BIDs and CERT-CC Advisory numbers.
>>
>>c1999 - CVE was launched as a cross-reference between established
>>proprietary IDs, not as a replacement for them.  In the years that
>>followed, publishers of vulnerability information paid the internal
>>costs of integrating CVE ids in response to market demand from their
>>end users who need to correlate vulnerability information across multiple sources.
>>
>>-----
>>Configuration Controls
>>-----
>>c1995 - Configuration information mostly published in prose security
>>guides and technical support repositories (e.g. Unix man pages,
>>Microsoft TechNet).  Proprietary IDs were not used. (DISA was an early
>>outlier.)
>>
>>2006 - CCE was established.  Publishers of configuration information
>>still weren't publishing their configuration information with their
>>own proprietary IDs.
>>
>>
>>I suspect that one of the key differences between the two domains has
>>been one of volume.  "Names" for vulnerabilities like "ping of death"
>>were entirely overrun by the sheer volume of information in that space.
>>
>>NOTE: publishers of vulnerability information turned to using
>>proprietary IDs *BEFORE* CVE existed
>>
>>In contrast, I suspect that publishers of configuration information
>>(guide authors and primary source vendors) as well as their key
>>customers are coming to the understanding that "names" for controls is
>>likewise being overwhelmed by volume.  But, they are coming to this
>>realization
>>*AFTER* CCE was created.
>>
>>Hence (I believe) the incorrect assumption on their part that they can
>>use CCE IDs as primary keys for their configuration information.
>>
>>The question remains, if publishers used proprietary IDs, would there
>>still be a need for CCE?
>>
>>For CVE, the answer is a resounding and clear, "Yes."
>>
>>
>>-Dave
>>==================================================================
>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>------------------------------------------------------------------
>>e-mail:[hidden email] | cell:781.424.6003
>>==================================================================
>>
>>
>>-----Original Message-----
>>From: Banghart, John [mailto:[hidden email]]
>>Sent: Tuesday, October 02, 2012 2:02 PM
>>To: Mann, Dave; cce-working-group-list
>>Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>>Created and Used?
>>
>>Dave,
>>
>>You suggest below that product vendors aren't creating their own
>>configuration ID's because of CCE.  However, they weren't creating
>>them before CCE was invented.  What has changed that leads the CCE
>>team to believe that CCE is a barrier?
>>
>>-John
>>
>>
>>On 10/2/12 1:49 PM, "Mann, Dave" <[hidden email]> wrote:
>>
>>>Folks,
>>>
>>>We really need your input.
>>>
>>>If all producers of configuration information (security guide
>>>authors, primary source vendors, security tool vendors) tagged their
>>>published configuration information with their own proprietary IDs
>>>(as is common in the vulnerability management space), would there
>>>still be a compelling need for CCE IDs?
>>>
>>>This is definitely a case where silence means, "No."
>>>
>>>-Dave
>>>==================================================================
>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>------------------------------------------------------------------
>>>e-mail:[hidden email] | cell:781.424.6003
>>>==================================================================
>>>
>>>-----Original Message-----
>>>From: Mann, Dave
>>>Sent: Wednesday, September 26, 2012 2:34 PM
>>>To: cce-working-group-list
>>>Subject: How Are Internal Checklists Created and Used?
>>>
>>>Folks,
>>>
>>>We need your input.  Please respond to the following questions...
>>>
>>>1) How do large companies and enterprises create their own, internal
>>>configuration checklists?
>>>
>>>2) How many external sources of information do they typically draw from
>>>for any given platform?   Do they rely primarily on published security
>>>guides, pre-built capabilities in their configuration
>>>audit/management tools or documentation from the software's vendor?
>>>
>>>3) How do they audit against their internal checklists?
>>>Specifically, how do they find audit checks that correspond to
>>>controls listed in their internal checklists?
>>>
>>>4) Is it common for companies to use multiple configuration
>>>audit/management tools for the same platform (perhaps across multiple
>>>business units) and is it common for them to need to consolidate the
>>>results?
>>>
>>>5) Lastly, how do they communicate with auditors and regulators
>>>regarding their configuration posture?  What form of documentation to
>>>they use?
>>>
>>>
>>>
>>>We are currently revisiting CCE's core value proposition.   CCE has been
>>>envisioned to be "CVE for configuration controls" and like CVE, CCE's
>>>goal has been to provide cross-reference IDs that could be used to
>>>quickly and accurately correlate across multiple sources of
>>>configuration information.
>>>
>>>If you are involved in doing about any aspect of vulnerability
>>>management, you must quickly and accurately find vulnerability
>>>information across multiple sources of information.  The general
>>>question we are asking can be stated as follows:
>>>  Is the same thing true for configuration management?
>>>
>>>For over a year, the CCE team has been advocating that all producers
>>>of configuration information publish their own proprietary IDs and to
>>>embed them in all forms of their published configuration guidance or tools.
>>>This is how things are done in the vulnerability management space and
>>>it is very successful.  Every vulnerability database uses their own
>>>ID scheme [1].  The same is true for vulnerability alerting services,
>>>vulnerability assessment products and security bulletins.   This allows
>>>each provider to publish their information with no hard dependency on
>>>CVE.  CVE does *not* replace proprietary IDs.  Instead, CVE IDs are
>>>added as cross-references.  In fact, the existence of proprietary IDs
>>>make CVE possible.
>>>
>>>In stark contrast, the use of proprietary IDs for configuration
>>>information is nearly unheard of [2].  Instead, controls tend to be
>>>referred to using English based names that may correspond to labels
>>>in GUIs or command names.
>>>
>>>We are increasingly becoming concerned that the existence of CCEs is
>>>dissuading publishers of configuration information from issuing their
>>>own proprietary IDs and that this, in turn, is creating unrealistic
>>>dependencies on CCE.  Namely, publishers need to be able to define
>>>controls in anyway that makes sense for them and their stakeholders,
>>>regardless of whether or not it conflicts with another organizations
>>>definition.
>>>
>>>We urge all publishers of configuration information to use their own
>>>IDs.
>>>
>>>In the next breath we ask, if all configuration information
>>>publishers used their own proprietary IDs (as they do in the
>>>vulnerability space), would there still be a need for a common cross-reference ID like CCE?
>>>
>>>
>>>
>>>[1] The major exception to this is the NIST National Vulnerability
>>>Database, which adds additional information to CVE data.
>>>
>>>[2] One notable exception to this are DISA's STIGs, which use "STIG
>>>IDs".
>>>
>>>-Dave
>>>==================================================================
>>>David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>------------------------------------------------------------------
>>>e-mail:[hidden email] | cell:781.424.6003
>>>==================================================================
>>

...

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [CCE-WORKING-GROUP-LIST] Scope of CCE?

Randal Taylor
I agree completely.  We need as many configuration items as possible.  
This will give us more flexibility in the future.

Randy


On 10/11/2012 5:54 PM, Blake Frantz wrote:

> +1 to for all configurable knobs that the community is willing to create a CCE for.
>
> Reasons for that:
>
> 1. If I understand DaveM correctly, then primary vendors are developing automation capabilities to generate CCEs for all configuration controls in their respective products. I say CCE all of them. If the vendors are auto-generating IDs, then it's likely more expensive to ask them to filter out items that are not security-relevant. It already costs vendors time/money to generate CCEs  - the cheaper we make it for them the better.
>
> 2. What is irrelevant to security today may be relevant tomorrow. If we limit CCEs to only those configuration surfaces that have security relevance today, we may not have a CCE when we need it. Overtime, IMO, the speed by which an organization can mitigate risk associated with new vulnerabilities becomes increasingly critical. CCE can help with that. Particularly, for new vulnerabilities that have no patch but do have a configuration-based workaround. Imagine how awesome it will be if/when vendor advisories are enriched with CCEs and delivered directly to your vulnerability scanner which in-turn scans all applicable assets for the state of the CCE the vendor said will mitigate that hot new vuln until a patch is shipped.
>
> Blake
>
> -----Original Message-----
> From: Mann, Dave [mailto:[hidden email]]
> Sent: Thursday, October 11, 2012 11:26 AM
> To: [hidden email]
> Subject: [CCE-WORKING-GROUP-LIST] Scope of CCE?
>
> This question is so important, that I think it makes sense to break it off of the "Internal Checklists" thread and to give it its own thread.
>
> What should be the scope of CCE?
> a) Only controls mentioned in prominent, public security guides (the traditional CCE answer)
> b) All configurable controls in a platform, as defined by the vendor.
>
> The original, longer-winded asking of this question follows...
>
> Regarding automating CCE content generation, Kelly suggested:
> First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.
>
> Dave responds:
> Kelly is making a significant suggestion here that merits serious consideration by the CCE Working Group.
>
> The question that it begs is, what is the scope of CCE?
>
> To this end, I would like to turn this discussion back towards the subject heading.  Is there still relevance to the concept of a "security checklist"?
>
> MITRE has been involved with discussions regarding CCE content creation with several primary source vendors, including Microsoft.   Kelly's suggestion is consistent with what we are hearing from other primary source vendors. They have (or are getting close to having) the ability to auto-generate IDs for all controls in a given platform.
>
> There are 2 important implications here.  First is a matter of scale.  Microsoft and other similar vendors have the ability to produce thousands and even tens of thousands controls for a single platform.
>
> Second is a matter of security relevance.  Per strong guidance from the Working Group, CCE has traditionally restricted its scope to only those controls whose security relevance was documented through its inclusion in published security guides or security audit tools.
>
> Is there a case to be made that primary source vendors should produce proprietary IDs for all controls in their products and as a both/and solution that CCE ids should be reserved to identify a smaller subset of controls that are considered to have security importance by the security audit community?
>
> [NOTE: this would somewhat mirror the use of CVE.  Vendors track all bugs and software defects, but only smaller subset of bugs have security relevance and are given CVE ids.]
>
> In past Working Group discussions (I'm thinking here primarily about past Developer Days events), some members of the security audit tool community made a strong argument for keeping CCE's traditional "guardrail" scoping decision of only giving IDs to those controls in security guides.  Paraphrasing, the line of argument was, "Customer expectation is such that if there is a CCE then our customers expect us to create an audit check for the issue.  If there are CCE ids for every possible control, we would not be able to write enough audit checks to keep up."
>
> Thoughts?
>
> Should CCE IDs be given for all possible controls in a platform?
>
> Or only for those that are documented in a security guide?
>
>
> -Dave
> ==================================================================
> David Mann | Principal Infosec Scientist | The MITRE Corporation
> ------------------------------------------------------------------
> e-mail:[hidden email] | cell:781.424.6003 ==================================================================
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Kelly Hengesteg
> Sent: Monday, October 08, 2012 7:05 PM
> To: Jesper Jurcenoks; cce-working-group-list
> Cc: Michael Tan
> Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Jesper and colleagues,
> I agree that is a great question, can we make the process easier:). I have to tell you I (we) at Microsoft are really frustrated with the current process. It is currently manual, very expensive and does not meet the needs of the authors, especially when you are participating out of goodwill for the community.
>
> Instead of going on for a long time about what doesn't work, I would like to talk about what we as authors should expect and want to make the process better.
>
> First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.
>
> What would it look like. I foresee a service in which I can sign in to the CCE-ID assignment service. I can then upload my CCE-ID_request.xml. The service would walk through a series of tests that include unique CCE-ID and CCE-ID descriptions, parameters, technical mechanism and reference (optional). Depending on whether I uploaded an update or request for new CCE's I would get the appropriate test cases.  The service would then provide me with one of two results, success/failure.  In the case of success, I would get an updated XML file with the randomly assigned new CCE-ID's (when requesting new),  If my XML had errors, I would get a failure report, outing specifically what CCE description was not passing and cite the test case to enable quick updates.
>
> This would provide me an incentive to continue investing in this standard.  Today, it is too expensive for us to continue with manual process we have in place today. If we truly want vendors and the community to continue making investments here, we have to make it more efficient.
>
> Thoughts? How can we make this a reality?
>
> Thanks,
> Kelly
>
>
> -----Original Message-----
> From: Jesper Jurcenoks [mailto:[hidden email]]
> Sent: Wednesday, October 3, 2012 10:09 PM
> To: [hidden email]
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Dave and List.
>
> I want to turn the question it's head.
>
> Are we questioning the need for CCE-ids because assigning CCE's is cumbersome compared to the rewards?
>
> If that is the case then maybe we should ask: If issuing of CCE ids is a barrier to use and adoption, then instead of getting rid of CCE-ids, can we make the process of assigning CCE-ids easier on everybody ?
>
> JJ
>
>
> -----Original Message-----
> From: Mann, Dave [mailto:[hidden email]]
> Sent: Tuesday, October 02, 2012 1:02 PM
> To: [hidden email]
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Nod.  Agreed.
>
> If configuration information were like automobiles or books, then the producers of the car or book could be counted on to register the VIN or ISBN.
>
> This is not the case with configuration controls in software.
>
> We typically have multiple sources of configuration control information for the same platform and the primary source vendor may or may not be a participant.
>
> In vulnerability management, pretty much all aspects of VM require that many sources of information be consulted, making CVE a near necessity.
>
> It could be argued (this is what we're trying to discern) that when most end users deal with a specific platform, they typically only need to navigate between 2 sources, say a security guide of their choosing and their 3rd party tool.  It could also be argued that some/many users rely primarily on the intelligence of their 3rd party tools and never even consult configuration guides.
>
> If this conjecture is true, then it may be that end users will be able to perform their configuration management duties just fine by relying on proprietary IDs.
>
> My first email on this subject is based on the 5 core use cases that CCE is founded on.   We are trying to determine if these use cases break if there was no CCE and if there is only proprietary IDs.
>
> If people believe that things will break without CCEs, please try to describe which use cases fail (per my first email).
>
> SIDE COMMENT THAT CCE HAS BEEN MAKING PUBLICLY FOR SOME TIME:  CCE creation and coordination would be infinitely easier if publishers of configuration information followed the lead of their vulnerability information peers by publishing their own proprietary IDs.  This would help pre-atomize their proprietary data and would give concrete references into their information sets that could be used to help manage the CCE process much better.    But this note is a digression from the main question.
>
> Are CCE's really needed?
>
>
> -Dave
> ==================================================================
> David Mann | Principal Infosec Scientist | The MITRE Corporation
> ------------------------------------------------------------------
> e-mail:[hidden email] | cell:781.424.6003 ==================================================================
>
>
> -----Original Message-----
> From: Quinn, Stephen [mailto:[hidden email]]
> Sent: Tuesday, October 02, 2012 3:29 PM
> To: Banghart, John; Mann, Dave; cce-working-group-list
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Folk,
>
>    John is correct... Historically, this has been an organizing principle for government authors of checklists.  The CCE identifier and subsequent description eliminates the need for secondary conversations that ensure we are discussing the same configuration item (I.e. Account Lockout vs lockout duration, etc).
>
>
> Steve
> NIST
>
> ----- Original Message -----
> From: Banghart, John [mailto:[hidden email]]
> Sent: Tuesday, October 02, 2012 03:19 PM
> To: Mann, Dave <[hidden email]>; [hidden email] <[hidden email]>
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Dave,
>
> But would guidance authors really use their own ID's?  If Microsoft tells me that "Password Length" = ID1234, then why wouldn't I use that when creating the USGCB?  If they don't tell me, and I use my own and DISA uses their own, then how would we correlate between the guidance documents?  It seems to me that if that happened, I would call up DISA and we would create some sort of mapping.  Then that would be mapped to CIS, then mapped to something else, until we all realized that we need a common identifier and create CCE.  :)
>
> -John
>
> On 10/2/12 3:10 PM, "Mann, Dave" <[hidden email]> wrote:
>
>> John,
>>
>> Yes, that is the question we're asking, although you're asking it in an
>> even more stark manner.
>>
>> I don't think it is true that there is ever a single authoritative
>> source of configuration information.  Despite the fact the primary
>> source vendors may produce configuration guidance (this varies widely),
>> various organizations still produce (or oversee the production of)
>> security guides that still get used.  Add to this that I suspect it is
>> still common for end users to rely on proprietary content embedded in
>> their 3rd party audit and management tools.
>>
>> Better to say that configuration management is easier because a much
>> smaller number of sources must be managed.
>>
>> Or not?
>>
>> That's what we're asking.
>>
>> If all publishers of configuration information (NIST, DISA, CIS,
>> McAfee, Symantec, nCircle, etc., Microsoft, Apple, RedHat, Oracle,
>> etc.) all used proprietary IDs, would there still be a need for CCE ids?
>>
>> -Dave
>> ==================================================================
>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>> ------------------------------------------------------------------
>> e-mail:[hidden email] | cell:781.424.6003
>> ==================================================================
>>
>>
>> -----Original Message-----
>> From: Banghart, John [mailto:[hidden email]]
>> Sent: Tuesday, October 02, 2012 2:59 PM
>> To: Mann, Dave; cce-working-group-list
>> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>> Created and Used?
>>
>> Dave,
>>
>> So the suggestion is that vulnerability information is hard because it
>> comes from many sources and therefore requires a commonly shared ID,
>> but configuration information really only has one authoritative source,
>> and so therefore might not require anything other then a proprietary ID.
>>
>> Is that consistent with what you are saying?
>>
>> -John
>>
>>
>> On 10/2/12 2:46 PM, "Mann, Dave" <[hidden email]> wrote:
>>
>>> John,
>>>
>>> Here is my crude, biased and short history of the vulnerability space
>>> compared to the configuration space.
>>>
>>> ----
>>> Vulnerabilities
>>> ----
>>> c1990 - Most vendors suppressed vulnerability information and followed
>>> the silent patch model.
>>>
>>> c1995 - Thanks in large measure to mailing lists like Bugtraq, the
>>> expected practice for vulnerability information moved to full
>>> disclosure and then responsible disclosure. Disclosure of
>>> vulnerability information was then accompanied by proprietary IDs,
>>> including: ISS X-Force IDs, Security Focus BIDs and CERT-CC Advisory numbers.
>>>
>>> c1999 - CVE was launched as a cross-reference between established
>>> proprietary IDs, not as a replacement for them.  In the years that
>>> followed, publishers of vulnerability information paid the internal
>>> costs of integrating CVE ids in response to market demand from their
>>> end users who need to correlate vulnerability information across multiple sources.
>>>
>>> -----
>>> Configuration Controls
>>> -----
>>> c1995 - Configuration information mostly published in prose security
>>> guides and technical support repositories (e.g. Unix man pages,
>>> Microsoft TechNet).  Proprietary IDs were not used. (DISA was an early
>>> outlier.)
>>>
>>> 2006 - CCE was established.  Publishers of configuration information
>>> still weren't publishing their configuration information with their
>>> own proprietary IDs.
>>>
>>>
>>> I suspect that one of the key differences between the two domains has
>>> been one of volume.  "Names" for vulnerabilities like "ping of death"
>>> were entirely overrun by the sheer volume of information in that space.
>>>
>>> NOTE: publishers of vulnerability information turned to using
>>> proprietary IDs *BEFORE* CVE existed
>>>
>>> In contrast, I suspect that publishers of configuration information
>>> (guide authors and primary source vendors) as well as their key
>>> customers are coming to the understanding that "names" for controls is
>>> likewise being overwhelmed by volume.  But, they are coming to this
>>> realization
>>> *AFTER* CCE was created.
>>>
>>> Hence (I believe) the incorrect assumption on their part that they can
>>> use CCE IDs as primary keys for their configuration information.
>>>
>>> The question remains, if publishers used proprietary IDs, would there
>>> still be a need for CCE?
>>>
>>> For CVE, the answer is a resounding and clear, "Yes."
>>>
>>>
>>> -Dave
>>> ==================================================================
>>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>>> ------------------------------------------------------------------
>>> e-mail:[hidden email] | cell:781.424.6003
>>> ==================================================================
>>>
>>>
>>> -----Original Message-----
>>> From: Banghart, John [mailto:[hidden email]]
>>> Sent: Tuesday, October 02, 2012 2:02 PM
>>> To: Mann, Dave; cce-working-group-list
>>> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>>> Created and Used?
>>>
>>> Dave,
>>>
>>> You suggest below that product vendors aren't creating their own
>>> configuration ID's because of CCE.  However, they weren't creating
>>> them before CCE was invented.  What has changed that leads the CCE
>>> team to believe that CCE is a barrier?
>>>
>>> -John
>>>
>>>
>>> On 10/2/12 1:49 PM, "Mann, Dave" <[hidden email]> wrote:
>>>
>>>> Folks,
>>>>
>>>> We really need your input.
>>>>
>>>> If all producers of configuration information (security guide
>>>> authors, primary source vendors, security tool vendors) tagged their
>>>> published configuration information with their own proprietary IDs
>>>> (as is common in the vulnerability management space), would there
>>>> still be a compelling need for CCE IDs?
>>>>
>>>> This is definitely a case where silence means, "No."
>>>>
>>>> -Dave
>>>> ==================================================================
>>>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>> ------------------------------------------------------------------
>>>> e-mail:[hidden email] | cell:781.424.6003
>>>> ==================================================================
>>>>
>>>> -----Original Message-----
>>>> From: Mann, Dave
>>>> Sent: Wednesday, September 26, 2012 2:34 PM
>>>> To: cce-working-group-list
>>>> Subject: How Are Internal Checklists Created and Used?
>>>>
>>>> Folks,
>>>>
>>>> We need your input.  Please respond to the following questions...
>>>>
>>>> 1) How do large companies and enterprises create their own, internal
>>>> configuration checklists?
>>>>
>>>> 2) How many external sources of information do they typically draw from
>>>> for any given platform?   Do they rely primarily on published security
>>>> guides, pre-built capabilities in their configuration
>>>> audit/management tools or documentation from the software's vendor?
>>>>
>>>> 3) How do they audit against their internal checklists?
>>>> Specifically, how do they find audit checks that correspond to
>>>> controls listed in their internal checklists?
>>>>
>>>> 4) Is it common for companies to use multiple configuration
>>>> audit/management tools for the same platform (perhaps across multiple
>>>> business units) and is it common for them to need to consolidate the
>>>> results?
>>>>
>>>> 5) Lastly, how do they communicate with auditors and regulators
>>>> regarding their configuration posture?  What form of documentation to
>>>> they use?
>>>>
>>>>
>>>>
>>>> We are currently revisiting CCE's core value proposition.   CCE has been
>>>> envisioned to be "CVE for configuration controls" and like CVE, CCE's
>>>> goal has been to provide cross-reference IDs that could be used to
>>>> quickly and accurately correlate across multiple sources of
>>>> configuration information.
>>>>
>>>> If you are involved in doing about any aspect of vulnerability
>>>> management, you must quickly and accurately find vulnerability
>>>> information across multiple sources of information.  The general
>>>> question we are asking can be stated as follows:
>>>>   Is the same thing true for configuration management?
>>>>
>>>> For over a year, the CCE team has been advocating that all producers
>>>> of configuration information publish their own proprietary IDs and to
>>>> embed them in all forms of their published configuration guidance or tools.
>>>> This is how things are done in the vulnerability management space and
>>>> it is very successful.  Every vulnerability database uses their own
>>>> ID scheme [1].  The same is true for vulnerability alerting services,
>>>> vulnerability assessment products and security bulletins.   This allows
>>>> each provider to publish their information with no hard dependency on
>>>> CVE.  CVE does *not* replace proprietary IDs.  Instead, CVE IDs are
>>>> added as cross-references.  In fact, the existence of proprietary IDs
>>>> make CVE possible.
>>>>
>>>> In stark contrast, the use of proprietary IDs for configuration
>>>> information is nearly unheard of [2].  Instead, controls tend to be
>>>> referred to using English based names that may correspond to labels
>>>> in GUIs or command names.
>>>>
>>>> We are increasingly becoming concerned that the existence of CCEs is
>>>> dissuading publishers of configuration information from issuing their
>>>> own proprietary IDs and that this, in turn, is creating unrealistic
>>>> dependencies on CCE.  Namely, publishers need to be able to define
>>>> controls in anyway that makes sense for them and their stakeholders,
>>>> regardless of whether or not it conflicts with another organizations
>>>> definition.
>>>>
>>>> We urge all publishers of configuration information to use their own
>>>> IDs.
>>>>
>>>> In the next breath we ask, if all configuration information
>>>> publishers used their own proprietary IDs (as they do in the
>>>> vulnerability space), would there still be a need for a common cross-reference ID like CCE?
>>>>
>>>>
>>>>
>>>> [1] The major exception to this is the NIST National Vulnerability
>>>> Database, which adds additional information to CVE data.
>>>>
>>>> [2] One notable exception to this are DISA's STIGs, which use "STIG
>>>> IDs".
>>>>
>>>> -Dave
>>>> ==================================================================
>>>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>> ------------------------------------------------------------------
>>>> e-mail:[hidden email] | cell:781.424.6003
>>>> ==================================================================
> ...
>
> This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [CCE-WORKING-GROUP-LIST] Scope of CCE?

Mann, Dave
In reply to this post by Mann, Dave
If primary source vendors (e.g. Microsoft, RedHat, etc.) can auto produce and document their own, proprietary IDs for all controls in a given platform that they produce, is there any need for CCE?

I would think that the only extra value would be a consistent syntax for IDs.  Would that be true?

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


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Randal Taylor
Sent: Thursday, October 11, 2012 6:04 PM
To: cce-working-group-list
Subject: Re: Scope of CCE?

I agree completely.  We need as many configuration items as possible.  
This will give us more flexibility in the future.

Randy


On 10/11/2012 5:54 PM, Blake Frantz wrote:

> +1 to for all configurable knobs that the community is willing to create a CCE for.
>
> Reasons for that:
>
> 1. If I understand DaveM correctly, then primary vendors are developing automation capabilities to generate CCEs for all configuration controls in their respective products. I say CCE all of them. If the vendors are auto-generating IDs, then it's likely more expensive to ask them to filter out items that are not security-relevant. It already costs vendors time/money to generate CCEs  - the cheaper we make it for them the better.
>
> 2. What is irrelevant to security today may be relevant tomorrow. If we limit CCEs to only those configuration surfaces that have security relevance today, we may not have a CCE when we need it. Overtime, IMO, the speed by which an organization can mitigate risk associated with new vulnerabilities becomes increasingly critical. CCE can help with that. Particularly, for new vulnerabilities that have no patch but do have a configuration-based workaround. Imagine how awesome it will be if/when vendor advisories are enriched with CCEs and delivered directly to your vulnerability scanner which in-turn scans all applicable assets for the state of the CCE the vendor said will mitigate that hot new vuln until a patch is shipped.
>
> Blake
>
> -----Original Message-----
> From: Mann, Dave [mailto:[hidden email]]
> Sent: Thursday, October 11, 2012 11:26 AM
> To: [hidden email]
> Subject: [CCE-WORKING-GROUP-LIST] Scope of CCE?
>
> This question is so important, that I think it makes sense to break it off of the "Internal Checklists" thread and to give it its own thread.
>
> What should be the scope of CCE?
> a) Only controls mentioned in prominent, public security guides (the traditional CCE answer)
> b) All configurable controls in a platform, as defined by the vendor.
>
> The original, longer-winded asking of this question follows...
>
> Regarding automating CCE content generation, Kelly suggested:
> First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.
>
> Dave responds:
> Kelly is making a significant suggestion here that merits serious consideration by the CCE Working Group.
>
> The question that it begs is, what is the scope of CCE?
>
> To this end, I would like to turn this discussion back towards the subject heading.  Is there still relevance to the concept of a "security checklist"?
>
> MITRE has been involved with discussions regarding CCE content creation with several primary source vendors, including Microsoft.   Kelly's suggestion is consistent with what we are hearing from other primary source vendors. They have (or are getting close to having) the ability to auto-generate IDs for all controls in a given platform.
>
> There are 2 important implications here.  First is a matter of scale.  Microsoft and other similar vendors have the ability to produce thousands and even tens of thousands controls for a single platform.
>
> Second is a matter of security relevance.  Per strong guidance from the Working Group, CCE has traditionally restricted its scope to only those controls whose security relevance was documented through its inclusion in published security guides or security audit tools.
>
> Is there a case to be made that primary source vendors should produce proprietary IDs for all controls in their products and as a both/and solution that CCE ids should be reserved to identify a smaller subset of controls that are considered to have security importance by the security audit community?
>
> [NOTE: this would somewhat mirror the use of CVE.  Vendors track all bugs and software defects, but only smaller subset of bugs have security relevance and are given CVE ids.]
>
> In past Working Group discussions (I'm thinking here primarily about past Developer Days events), some members of the security audit tool community made a strong argument for keeping CCE's traditional "guardrail" scoping decision of only giving IDs to those controls in security guides.  Paraphrasing, the line of argument was, "Customer expectation is such that if there is a CCE then our customers expect us to create an audit check for the issue.  If there are CCE ids for every possible control, we would not be able to write enough audit checks to keep up."
>
> Thoughts?
>
> Should CCE IDs be given for all possible controls in a platform?
>
> Or only for those that are documented in a security guide?
>
>
> -Dave
> ==================================================================
> David Mann | Principal Infosec Scientist | The MITRE Corporation
> ------------------------------------------------------------------
> e-mail:[hidden email] | cell:781.424.6003 ==================================================================
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Kelly Hengesteg
> Sent: Monday, October 08, 2012 7:05 PM
> To: Jesper Jurcenoks; cce-working-group-list
> Cc: Michael Tan
> Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Jesper and colleagues,
> I agree that is a great question, can we make the process easier:). I have to tell you I (we) at Microsoft are really frustrated with the current process. It is currently manual, very expensive and does not meet the needs of the authors, especially when you are participating out of goodwill for the community.
>
> Instead of going on for a long time about what doesn't work, I would like to talk about what we as authors should expect and want to make the process better.
>
> First let's automate the process and remove any manual steps (unless the author requests an exception). This process is prime for automation and from my vantage point it can be fully automated.
>
> What would it look like. I foresee a service in which I can sign in to the CCE-ID assignment service. I can then upload my CCE-ID_request.xml. The service would walk through a series of tests that include unique CCE-ID and CCE-ID descriptions, parameters, technical mechanism and reference (optional). Depending on whether I uploaded an update or request for new CCE's I would get the appropriate test cases.  The service would then provide me with one of two results, success/failure.  In the case of success, I would get an updated XML file with the randomly assigned new CCE-ID's (when requesting new),  If my XML had errors, I would get a failure report, outing specifically what CCE description was not passing and cite the test case to enable quick updates.
>
> This would provide me an incentive to continue investing in this standard.  Today, it is too expensive for us to continue with manual process we have in place today. If we truly want vendors and the community to continue making investments here, we have to make it more efficient.
>
> Thoughts? How can we make this a reality?
>
> Thanks,
> Kelly
>
>
> -----Original Message-----
> From: Jesper Jurcenoks [mailto:[hidden email]]
> Sent: Wednesday, October 3, 2012 10:09 PM
> To: [hidden email]
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Dave and List.
>
> I want to turn the question it's head.
>
> Are we questioning the need for CCE-ids because assigning CCE's is cumbersome compared to the rewards?
>
> If that is the case then maybe we should ask: If issuing of CCE ids is a barrier to use and adoption, then instead of getting rid of CCE-ids, can we make the process of assigning CCE-ids easier on everybody ?
>
> JJ
>
>
> -----Original Message-----
> From: Mann, Dave [mailto:[hidden email]]
> Sent: Tuesday, October 02, 2012 1:02 PM
> To: [hidden email]
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Nod.  Agreed.
>
> If configuration information were like automobiles or books, then the producers of the car or book could be counted on to register the VIN or ISBN.
>
> This is not the case with configuration controls in software.
>
> We typically have multiple sources of configuration control information for the same platform and the primary source vendor may or may not be a participant.
>
> In vulnerability management, pretty much all aspects of VM require that many sources of information be consulted, making CVE a near necessity.
>
> It could be argued (this is what we're trying to discern) that when most end users deal with a specific platform, they typically only need to navigate between 2 sources, say a security guide of their choosing and their 3rd party tool.  It could also be argued that some/many users rely primarily on the intelligence of their 3rd party tools and never even consult configuration guides.
>
> If this conjecture is true, then it may be that end users will be able to perform their configuration management duties just fine by relying on proprietary IDs.
>
> My first email on this subject is based on the 5 core use cases that CCE is founded on.   We are trying to determine if these use cases break if there was no CCE and if there is only proprietary IDs.
>
> If people believe that things will break without CCEs, please try to describe which use cases fail (per my first email).
>
> SIDE COMMENT THAT CCE HAS BEEN MAKING PUBLICLY FOR SOME TIME:  CCE creation and coordination would be infinitely easier if publishers of configuration information followed the lead of their vulnerability information peers by publishing their own proprietary IDs.  This would help pre-atomize their proprietary data and would give concrete references into their information sets that could be used to help manage the CCE process much better.    But this note is a digression from the main question.
>
> Are CCE's really needed?
>
>
> -Dave
> ==================================================================
> David Mann | Principal Infosec Scientist | The MITRE Corporation
> ------------------------------------------------------------------
> e-mail:[hidden email] | cell:781.424.6003 ==================================================================
>
>
> -----Original Message-----
> From: Quinn, Stephen [mailto:[hidden email]]
> Sent: Tuesday, October 02, 2012 3:29 PM
> To: Banghart, John; Mann, Dave; cce-working-group-list
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Folk,
>
>    John is correct... Historically, this has been an organizing principle for government authors of checklists.  The CCE identifier and subsequent description eliminates the need for secondary conversations that ensure we are discussing the same configuration item (I.e. Account Lockout vs lockout duration, etc).
>
>
> Steve
> NIST
>
> ----- Original Message -----
> From: Banghart, John [mailto:[hidden email]]
> Sent: Tuesday, October 02, 2012 03:19 PM
> To: Mann, Dave <[hidden email]>; [hidden email] <[hidden email]>
> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?
>
> Dave,
>
> But would guidance authors really use their own ID's?  If Microsoft tells me that "Password Length" = ID1234, then why wouldn't I use that when creating the USGCB?  If they don't tell me, and I use my own and DISA uses their own, then how would we correlate between the guidance documents?  It seems to me that if that happened, I would call up DISA and we would create some sort of mapping.  Then that would be mapped to CIS, then mapped to something else, until we all realized that we need a common identifier and create CCE.  :)
>
> -John
>
> On 10/2/12 3:10 PM, "Mann, Dave" <[hidden email]> wrote:
>
>> John,
>>
>> Yes, that is the question we're asking, although you're asking it in an
>> even more stark manner.
>>
>> I don't think it is true that there is ever a single authoritative
>> source of configuration information.  Despite the fact the primary
>> source vendors may produce configuration guidance (this varies widely),
>> various organizations still produce (or oversee the production of)
>> security guides that still get used.  Add to this that I suspect it is
>> still common for end users to rely on proprietary content embedded in
>> their 3rd party audit and management tools.
>>
>> Better to say that configuration management is easier because a much
>> smaller number of sources must be managed.
>>
>> Or not?
>>
>> That's what we're asking.
>>
>> If all publishers of configuration information (NIST, DISA, CIS,
>> McAfee, Symantec, nCircle, etc., Microsoft, Apple, RedHat, Oracle,
>> etc.) all used proprietary IDs, would there still be a need for CCE ids?
>>
>> -Dave
>> ==================================================================
>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>> ------------------------------------------------------------------
>> e-mail:[hidden email] | cell:781.424.6003
>> ==================================================================
>>
>>
>> -----Original Message-----
>> From: Banghart, John [mailto:[hidden email]]
>> Sent: Tuesday, October 02, 2012 2:59 PM
>> To: Mann, Dave; cce-working-group-list
>> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>> Created and Used?
>>
>> Dave,
>>
>> So the suggestion is that vulnerability information is hard because it
>> comes from many sources and therefore requires a commonly shared ID,
>> but configuration information really only has one authoritative source,
>> and so therefore might not require anything other then a proprietary ID.
>>
>> Is that consistent with what you are saying?
>>
>> -John
>>
>>
>> On 10/2/12 2:46 PM, "Mann, Dave" <[hidden email]> wrote:
>>
>>> John,
>>>
>>> Here is my crude, biased and short history of the vulnerability space
>>> compared to the configuration space.
>>>
>>> ----
>>> Vulnerabilities
>>> ----
>>> c1990 - Most vendors suppressed vulnerability information and followed
>>> the silent patch model.
>>>
>>> c1995 - Thanks in large measure to mailing lists like Bugtraq, the
>>> expected practice for vulnerability information moved to full
>>> disclosure and then responsible disclosure. Disclosure of
>>> vulnerability information was then accompanied by proprietary IDs,
>>> including: ISS X-Force IDs, Security Focus BIDs and CERT-CC Advisory numbers.
>>>
>>> c1999 - CVE was launched as a cross-reference between established
>>> proprietary IDs, not as a replacement for them.  In the years that
>>> followed, publishers of vulnerability information paid the internal
>>> costs of integrating CVE ids in response to market demand from their
>>> end users who need to correlate vulnerability information across multiple sources.
>>>
>>> -----
>>> Configuration Controls
>>> -----
>>> c1995 - Configuration information mostly published in prose security
>>> guides and technical support repositories (e.g. Unix man pages,
>>> Microsoft TechNet).  Proprietary IDs were not used. (DISA was an early
>>> outlier.)
>>>
>>> 2006 - CCE was established.  Publishers of configuration information
>>> still weren't publishing their configuration information with their
>>> own proprietary IDs.
>>>
>>>
>>> I suspect that one of the key differences between the two domains has
>>> been one of volume.  "Names" for vulnerabilities like "ping of death"
>>> were entirely overrun by the sheer volume of information in that space.
>>>
>>> NOTE: publishers of vulnerability information turned to using
>>> proprietary IDs *BEFORE* CVE existed
>>>
>>> In contrast, I suspect that publishers of configuration information
>>> (guide authors and primary source vendors) as well as their key
>>> customers are coming to the understanding that "names" for controls is
>>> likewise being overwhelmed by volume.  But, they are coming to this
>>> realization
>>> *AFTER* CCE was created.
>>>
>>> Hence (I believe) the incorrect assumption on their part that they can
>>> use CCE IDs as primary keys for their configuration information.
>>>
>>> The question remains, if publishers used proprietary IDs, would there
>>> still be a need for CCE?
>>>
>>> For CVE, the answer is a resounding and clear, "Yes."
>>>
>>>
>>> -Dave
>>> ==================================================================
>>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>>> ------------------------------------------------------------------
>>> e-mail:[hidden email] | cell:781.424.6003
>>> ==================================================================
>>>
>>>
>>> -----Original Message-----
>>> From: Banghart, John [mailto:[hidden email]]
>>> Sent: Tuesday, October 02, 2012 2:02 PM
>>> To: Mann, Dave; cce-working-group-list
>>> Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists
>>> Created and Used?
>>>
>>> Dave,
>>>
>>> You suggest below that product vendors aren't creating their own
>>> configuration ID's because of CCE.  However, they weren't creating
>>> them before CCE was invented.  What has changed that leads the CCE
>>> team to believe that CCE is a barrier?
>>>
>>> -John
>>>
>>>
>>> On 10/2/12 1:49 PM, "Mann, Dave" <[hidden email]> wrote:
>>>
>>>> Folks,
>>>>
>>>> We really need your input.
>>>>
>>>> If all producers of configuration information (security guide
>>>> authors, primary source vendors, security tool vendors) tagged their
>>>> published configuration information with their own proprietary IDs
>>>> (as is common in the vulnerability management space), would there
>>>> still be a compelling need for CCE IDs?
>>>>
>>>> This is definitely a case where silence means, "No."
>>>>
>>>> -Dave
>>>> ==================================================================
>>>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>> ------------------------------------------------------------------
>>>> e-mail:[hidden email] | cell:781.424.6003
>>>> ==================================================================
>>>>
>>>> -----Original Message-----
>>>> From: Mann, Dave
>>>> Sent: Wednesday, September 26, 2012 2:34 PM
>>>> To: cce-working-group-list
>>>> Subject: How Are Internal Checklists Created and Used?
>>>>
>>>> Folks,
>>>>
>>>> We need your input.  Please respond to the following questions...
>>>>
>>>> 1) How do large companies and enterprises create their own, internal
>>>> configuration checklists?
>>>>
>>>> 2) How many external sources of information do they typically draw from
>>>> for any given platform?   Do they rely primarily on published security
>>>> guides, pre-built capabilities in their configuration
>>>> audit/management tools or documentation from the software's vendor?
>>>>
>>>> 3) How do they audit against their internal checklists?
>>>> Specifically, how do they find audit checks that correspond to
>>>> controls listed in their internal checklists?
>>>>
>>>> 4) Is it common for companies to use multiple configuration
>>>> audit/management tools for the same platform (perhaps across multiple
>>>> business units) and is it common for them to need to consolidate the
>>>> results?
>>>>
>>>> 5) Lastly, how do they communicate with auditors and regulators
>>>> regarding their configuration posture?  What form of documentation to
>>>> they use?
>>>>
>>>>
>>>>
>>>> We are currently revisiting CCE's core value proposition.   CCE has been
>>>> envisioned to be "CVE for configuration controls" and like CVE, CCE's
>>>> goal has been to provide cross-reference IDs that could be used to
>>>> quickly and accurately correlate across multiple sources of
>>>> configuration information.
>>>>
>>>> If you are involved in doing about any aspect of vulnerability
>>>> management, you must quickly and accurately find vulnerability
>>>> information across multiple sources of information.  The general
>>>> question we are asking can be stated as follows:
>>>>   Is the same thing true for configuration management?
>>>>
>>>> For over a year, the CCE team has been advocating that all producers
>>>> of configuration information publish their own proprietary IDs and to
>>>> embed them in all forms of their published configuration guidance or tools.
>>>> This is how things are done in the vulnerability management space and
>>>> it is very successful.  Every vulnerability database uses their own
>>>> ID scheme [1].  The same is true for vulnerability alerting services,
>>>> vulnerability assessment products and security bulletins.   This allows
>>>> each provider to publish their information with no hard dependency on
>>>> CVE.  CVE does *not* replace proprietary IDs.  Instead, CVE IDs are
>>>> added as cross-references.  In fact, the existence of proprietary IDs
>>>> make CVE possible.
>>>>
>>>> In stark contrast, the use of proprietary IDs for configuration
>>>> information is nearly unheard of [2].  Instead, controls tend to be
>>>> referred to using English based names that may correspond to labels
>>>> in GUIs or command names.
>>>>
>>>> We are increasingly becoming concerned that the existence of CCEs is
>>>> dissuading publishers of configuration information from issuing their
>>>> own proprietary IDs and that this, in turn, is creating unrealistic
>>>> dependencies on CCE.  Namely, publishers need to be able to define
>>>> controls in anyway that makes sense for them and their stakeholders,
>>>> regardless of whether or not it conflicts with another organizations
>>>> definition.
>>>>
>>>> We urge all publishers of configuration information to use their own
>>>> IDs.
>>>>
>>>> In the next breath we ask, if all configuration information
>>>> publishers used their own proprietary IDs (as they do in the
>>>> vulnerability space), would there still be a need for a common cross-reference ID like CCE?
>>>>
>>>>
>>>>
>>>> [1] The major exception to this is the NIST National Vulnerability
>>>> Database, which adds additional information to CVE data.
>>>>
>>>> [2] One notable exception to this are DISA's STIGs, which use "STIG
>>>> IDs".
>>>>
>>>> -Dave
>>>> ==================================================================
>>>> David Mann | Principal Infosec Scientist | The MITRE Corporation
>>>> ------------------------------------------------------------------
>>>> e-mail:[hidden email] | cell:781.424.6003
>>>> ==================================================================
> ...
>
> This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [CCE-WORKING-GROUP-LIST] Scope of CCE?

Steve Grubb
On Friday, October 12, 2012 03:12:22 PM Mann, Dave wrote:
> If primary source vendors (e.g. Microsoft, RedHat, etc.) can auto produce
> and document their own, proprietary IDs for all controls in a given
> platform that they produce, is there any need for CCE?
>
> I would think that the only extra value would be a consistent syntax for
> IDs.  Would that be true?

We don't produce any proprietary identifiers at all. But what we would like to
see is a uniform set of identifiers that can be re-used so that we don't need
new ones for each release of RHEL. As far as we are concerned, all OS should
have similar identifiers. There are other parts of SCAP that know specifically
which file or how to how to do the check. But something like "The password
length should be set appropriately" is universal across all OSes.

To us, we would like a set of ID's that can be used on RHEL5, 6, 7, Fedora 17,
18, rawhide, maybe even Centos or Scientific Linux. (Imagine how many govt
agencies are running RHEL content on Centos? Do you think they are applying
for new ID's?) As far as that goes, Linux is a place where people share code
and other things. So, I bet you'll find people trying to use RHEL content for
Ubuntu, Debian, Suse, etc. Those people won't know that they are supposed to
have unique identifiers and they won't go get new ones. CCE identifiers will
leak from one distribution to another. IOW, I think the horse is out of the
barn in our world.

To me, the most sensible thing to create one set of identifiers once and for
all and only add to them when needed. (This would probably help the 800-53
mappings, too.) This would have the added benefit of allowing greater
correlation between operating systems and releases of those OS'es.

-Steve
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [CCE-WORKING-GROUP-LIST] Scope of CCE?

Mann, Dave
Steve Grubb noted:
We don't produce any proprietary identifiers at all. But what we would like to
see is a uniform set of identifiers that can be re-used so that we don't need
new ones for each release of RHEL.

Dave responds:
If you were to produce your own proprietary IDs, you could produce them in any way you choose to, with no regard to existing CCE conventions such as re-issuance of CCEs for different platform groups (i.e. major versions).

The same would be true for any producer of proprietary IDs.  


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


-----Original Message-----
From: Steve Grubb [mailto:[hidden email]]
Sent: Friday, October 12, 2012 4:09 PM
To: Mann, Dave
Cc: cce-working-group-list
Subject: Re: [CCE-WORKING-GROUP-LIST] Scope of CCE?

On Friday, October 12, 2012 03:12:22 PM Mann, Dave wrote:
> If primary source vendors (e.g. Microsoft, RedHat, etc.) can auto produce
> and document their own, proprietary IDs for all controls in a given
> platform that they produce, is there any need for CCE?
>
> I would think that the only extra value would be a consistent syntax for
> IDs.  Would that be true?

We don't produce any proprietary identifiers at all. But what we would like to
see is a uniform set of identifiers that can be re-used so that we don't need
new ones for each release of RHEL. As far as we are concerned, all OS should
have similar identifiers. There are other parts of SCAP that know specifically
which file or how to how to do the check. But something like "The password
length should be set appropriately" is universal across all OSes.

To us, we would like a set of ID's that can be used on RHEL5, 6, 7, Fedora 17,
18, rawhide, maybe even Centos or Scientific Linux. (Imagine how many govt
agencies are running RHEL content on Centos? Do you think they are applying
for new ID's?) As far as that goes, Linux is a place where people share code
and other things. So, I bet you'll find people trying to use RHEL content for
Ubuntu, Debian, Suse, etc. Those people won't know that they are supposed to
have unique identifiers and they won't go get new ones. CCE identifiers will
leak from one distribution to another. IOW, I think the horse is out of the
barn in our world.

To me, the most sensible thing to create one set of identifiers once and for
all and only add to them when needed. (This would probably help the 800-53
mappings, too.) This would have the added benefit of allowing greater
correlation between operating systems and releases of those OS'es.

-Steve
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [CCE-WORKING-GROUP-LIST] Scope of CCE?

Jeffrey Blank
My background:
I have been involved with creation of security baselines, primarily for
Unix-like operating systems.

Steve's wish for re-use of identifiers might diminish if the
cost-benefit argument for creating a submission were not so poor.

Negatives:
1) it is difficult/costly to submit for CCEs
2) nearly all elements of a CCE submission could be considered a
deformed version of certain XCCDF elements
3) there is no apparent value in their per-platform nature

Positives:
1) it encourages guidance writers to a achieve a level of granularity
2) it provides a handle to a guidance fragment (via the identifier)

Do the positives outweigh the negatives, as currently implemented?
I would argue no.

The CCE description and mechanism (and often painfully contrived
parameterization) are worthless and costly to produce.  It's also an
indignity to ask a human being to write something that has no audience,
whether human or machine.

Strong points demand strong evidence, so here is an illustration:
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rhel6-cces-rhel5.html
(Hopefully it's there by the time you read this.)

The first column is obviously a CCE identifier.
The second and third columns are XCCDF title and description.
The last two columns are CCE description and "technical mechanism".
(The naive reader might believe that the last two columns are meant for
at human or machine consumption, but we all know better.)

Consider this table also a submission for RHEL 6 CCEs (as RHEL 5 CCEs
are actually featured here); where the CCE description/mechanism is not
available, consider the XCCDF-derived columns as submission text. I
think that Mitre was seeking Excel spreadsheets for submission, but
maybe we can try using an open standard instead.  Please alert Red Hat
(Steve) and myself if you have any questions about the submission.

Since this is about the future of CCE, I would suggest that the
following course of reform would provide the same level of value without
the costs/overhead currently involved:
1) Vendors maintain their own CCE identifier blocks
2) The text could be XCCDF Title and Description and associated Values
(or whatever is enough to disambiguate identification of the knob)
3) Mitre would offer review (possibly offering a "vetted" designation)
on the level of granularity, within a reasonable timeframe

That said, Phyllis Lee would be authoritative for our position, not me.

As Blake mentioned, it is attractive to have CCEs (or some kind of
identifier) for as many of the knobs as possible on a platform.  But
this is also clearly untenable for CCE in its current form.







On 10/12/2012 05:38 PM, Mann, Dave wrote:

> Steve Grubb noted: We don't produce any proprietary identifiers at
> all. But what we would like to see is a uniform set of identifiers
> that can be re-used so that we don't need new ones for each release
> of RHEL.
>
> Dave responds: If you were to produce your own proprietary IDs, you
> could produce them in any way you choose to, with no regard to
> existing CCE conventions such as re-issuance of CCEs for different
> platform groups (i.e. major versions).
>
> The same would be true for any producer of proprietary IDs.
>
>
> -Dave
> ==================================================================
> David Mann | Principal Infosec Scientist | The MITRE Corporation
> ------------------------------------------------------------------
> e-mail:[hidden email] | cell:781.424.6003
> ==================================================================
>
>
> -----Original Message----- From: Steve Grubb
> [mailto:[hidden email]] Sent: Friday, October 12, 2012 4:09 PM To:
> Mann, Dave Cc: cce-working-group-list Subject: Re:
> [CCE-WORKING-GROUP-LIST] Scope of CCE?
>
> On Friday, October 12, 2012 03:12:22 PM Mann, Dave wrote:
>> If primary source vendors (e.g. Microsoft, RedHat, etc.) can auto
>> produce and document their own, proprietary IDs for all controls in
>> a given platform that they produce, is there any need for CCE?
>>
>> I would think that the only extra value would be a consistent
>> syntax for IDs.  Would that be true?
>
> We don't produce any proprietary identifiers at all. But what we
> would like to see is a uniform set of identifiers that can be re-used
> so that we don't need new ones for each release of RHEL. As far as we
> are concerned, all OS should have similar identifiers. There are
> other parts of SCAP that know specifically which file or how to how
> to do the check. But something like "The password length should be
> set appropriately" is universal across all OSes.
>
> To us, we would like a set of ID's that can be used on RHEL5, 6, 7,
> Fedora 17, 18, rawhide, maybe even Centos or Scientific Linux.
> (Imagine how many govt agencies are running RHEL content on Centos?
> Do you think they are applying for new ID's?) As far as that goes,
> Linux is a place where people share code and other things. So, I bet
> you'll find people trying to use RHEL content for Ubuntu, Debian,
> Suse, etc. Those people won't know that they are supposed to have
> unique identifiers and they won't go get new ones. CCE identifiers
> will leak from one distribution to another. IOW, I think the horse is
> out of the barn in our world.
>
> To me, the most sensible thing to create one set of identifiers once
> and for all and only add to them when needed. (This would probably
> help the 800-53 mappings, too.) This would have the added benefit of
> allowing greater correlation between operating systems and releases
> of those OS'es.
>
> -Steve
>
Loading...