Quantcast

[CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

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

[CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

Mann, Dave
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] How Are Internal Checklists Created and Used?

Mann, Dave
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] How Are Internal Checklists Created and Used?

Banghart, John-2
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] How Are Internal Checklists Created and Used?

Mann, Dave
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] How Are Internal Checklists Created and Used?

Banghart, John-2
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] How Are Internal Checklists Created and Used?

Mann, Dave
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] How Are Internal Checklists Created and Used?

Banghart, John-2
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] How Are Internal Checklists Created and Used?

Kent Landfield
In reply to this post by Mann, Dave
Dave writes:
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?

Yes.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Mann>, David Mann <[hidden email]>
Date: Tuesday, October 2, 2012 3:10 PM
To: cce-working-group-list <[hidden email]>
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

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 [[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 [[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] How Are Internal Checklists Created and Used?

Stephen.Quinn
In reply to this post by Banghart, John-2
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] How Are Internal Checklists Created and Used?

Mann, Dave
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] How Are Internal Checklists Created and Used?

Banghart, John-2
Dave said:

"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."


This argument is flawed.  First, the concept of "end users" is far to
nebulous to use in a broadly sweeping manner. Plenty of users don't get to
choose what guidance they use, others don't care, some do, and so on.
Secondly, the value of security automation specifications isn't to the end
users.  It's about helping users manage and report their system state in
as accurately and timely a manner as possible without having to understand
how it works under the hood.  It isn't clear to me how it would help them
to have a slew of proprietary ID's based on multiple interpretations.

I get that CCE is hard, that it is time consuming, and that adequate
incentives haven't been implemented to get vendors to contribute more
directly to their creation.  Are you asking if CCE is worth the current
level of effort? Because if you are, that's a reasonable question worth
discussion.  But barring some further explanation, I don¹t' see how we can
proceed without CCE.

-John

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

>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] How Are Internal Checklists Created and Used?

Tim Keanini
In reply to this post by Kent Landfield

Yes

 

--

Tim "TK" Keanini, Chief Research Officer    …    nCircle Inc.   …   mbl (415) 328-2722  …

Blog: patterns.ncircle.com   Twitter: @tkeanini

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, October 02, 2012 2:28 PM
To: [hidden email]; [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

 

Dave writes:

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?

 

Yes.

 

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: <Mann>, David Mann <[hidden email]>
Date: Tuesday, October 2, 2012 3:10 PM
To: cce-working-group-list <[hidden email]>
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

 

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 [[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 [[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] How Are Internal Checklists Created and Used?

Adam Montville
Yes.

Sent from my iPhone

On Oct 3, 2012, at 2:07 PM, "Tim Keanini" <[hidden email]> wrote:

Yes

 

--

Tim "TK" Keanini, Chief Research Officer    …    nCircle Inc.   …   mbl (415) 328-2722  …

Blog: patterns.ncircle.com   Twitter: @tkeanini

 

From: [hidden email] [[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, October 02, 2012 2:28 PM
To: [hidden email]; [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

 

Dave writes:

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?

 

Yes.

 

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: <Mann>, David Mann <[hidden email]>
Date: Tuesday, October 2, 2012 3:10 PM
To: cce-working-group-list <[hidden email]>
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

 

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 [[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 [[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] How Are Internal Checklists Created and Used?

Jesper Jurcenoks
In reply to this post by Mann, Dave
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] How Are Internal Checklists Created and Used?

Kelly Hengesteg
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] How Are Internal Checklists Created and Used?

Cockrell, Erik
This is Erik Cockrell from Polycom.  I completely agree with the need for automation of the CCE registration process.  This would greatly assist my company in adopting SCAP that much faster.

-----Original Message-----
From: Kelly Hengesteg [mailto:[hidden email]]
Sent: Monday, October 08, 2012 6:05 PM
To: [hidden email]
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] How Are Internal Checklists Created and Used?

Mann, Dave
In reply to this post by Kelly Hengesteg
The issue of making the production of identifiers easier is simple to solve.  

All that is required is to allow producers of IDs to produce IDs in any way that suits them.  That is, to use proprietary IDs.  This is how producers of vulnerability information handle things today.  Microsoft attaches their own IDs to their security bulletins, RedHat uses their own IDs for their errata and so on.

Drawing on the history of identifier systems, there are really only 3 basic approaches.

NON-COORDINATED, PROPRIETARY IDs (e.g. Serial Numbers) - Organizations can produce any sort of proprietary ID they want with no coordination costs.   All producers of vulnerability information do this.  Most manufacturers of produced good do this when they produce serial numbers.   Note, in this approach, there is no shared, universal registry of IDs. There is no (public) "laptop serial number database" that covers all manufacturers of laptops.

STRUCTURED, FEDERATED IDs (e.g. VIN, ISBN) - In this approach, the format is set.  Participants are given sole right to produce IDs for their own goods.  There is a centrally managed registry of legitimate entries but if a participant fails to follow the rules, they can't issue the IDs.    The primary barrier to this approach for configuration controls is that there is no agreement as to whether or not software manufactures could or should be compelled to participate and whether or not security guide authors could or should be compelled to not  participate in deference to the software manufacturer.

CENTRALIZED IDs (e.g. CVE) - This approach recognizes that a) there are multiple sources for information and b) the sources of that information are unlikely to bear the cost of creating a fully formed registry entry.


In terms of CCE production, the core question then resolves to the question of whether or not the industry needs a centralized *REGISTRY* of shared IDs.  If it doesn't, then proprietary IDs will work.  If it does, then there needs to be certain minimum standard of what constitutes a properly formed registry entry.  

Could the system be more automated?  Sure.

But the real question is, Is the set of fields that comprises a CCE entry too much or too little?  

For the record, we're not seeing submissions from vendors failing due to a lack of automation.   It's almost always due to the fact that a) the CCE fields don't line up well with the vendors internal data and/or b) insufficient analytical work is done to avoid duplication from other configuration information sources.  

It isn't clear to me how automation would make either of those easier.  

Happy to talk about changing what we record for a CCE entry.  


-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] How Are Internal Checklists Created and Used?

Mann, Dave
In reply to this post by Kent Landfield
Dave writes:
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?

Kent Landfield responded:
Yes.

Adam Montvale responded:
Yes.

TK Keanini responded:
Yes.


Dave re-asks....

Why?


We really need to understand what breaks if there is no CCE (and there is only proprietary IDs).

John Banghart wrote:
This argument is flawed.  First, the concept of "end users" is far to
nebulous to use in a broadly sweeping manner. Plenty of users don't get to
choose what guidance they use, others don't care, some do, and so on.
Secondly, the value of security automation specifications isn't to the end
users.  It's about helping users manage and report their system state in
as accurately and timely a manner as possible without having to understand
how it works under the hood.  It isn't clear to me how it would help them
to have a slew of proprietary ID's based on multiple interpretations.


Dave re-asks....

And it isn't clear to us what breaks if there are, in fact, a slew of proprietary IDs based on multiple interpretations.

Our (limited) sense is that when end users confront a system, they do so based primarily on a single set of guidance. That guidance may be an prose security guide.  It may be an automated checklist (e.g. SCAP).  Or it may be a capability in a 3rd party tool.    If our understanding is correct, that end-user will be able to proceed in managing the configuration of that system with little to no need to cross-reference across other sources of configuration information.

That is, while there may be "a slew of proprietary ID's based on multiple interpretations", the end user would never see them or need to deal with them.

If we're wrong on this.... If it is the case that users need to coordinate and cross-reference across multiple sources of configuration information, we need to hear why.

Microsoft and Polycom have both just told us that coordination costs with CCE are too expensive.

Why would things fail if Microsoft and Polycom just produced and self-published their own proprietary IDs?




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

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

Dave writes:
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?

Yes.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Mann>, David Mann <[hidden email]>
Date: Tuesday, October 2, 2012 3:10 PM
To: cce-working-group-list <[hidden email]>
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

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] How Are Internal Checklists Created and Used?

Cockrell, Erik
One question I have is even if proprietary IDs were used, wouldn't there need to be some standards in place as to the format and structure to prevent duplicate IDs being used by multiple companies or organizations?

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

Dave writes:
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?

Kent Landfield responded:
Yes.

Adam Montvale responded:
Yes.

TK Keanini responded:
Yes.


Dave re-asks....

Why?


We really need to understand what breaks if there is no CCE (and there is only proprietary IDs).

John Banghart wrote:
This argument is flawed.  First, the concept of "end users" is far to nebulous to use in a broadly sweeping manner. Plenty of users don't get to choose what guidance they use, others don't care, some do, and so on.
Secondly, the value of security automation specifications isn't to the end users.  It's about helping users manage and report their system state in as accurately and timely a manner as possible without having to understand how it works under the hood.  It isn't clear to me how it would help them to have a slew of proprietary ID's based on multiple interpretations.


Dave re-asks....

And it isn't clear to us what breaks if there are, in fact, a slew of proprietary IDs based on multiple interpretations.

Our (limited) sense is that when end users confront a system, they do so based primarily on a single set of guidance. That guidance may be an prose security guide.  It may be an automated checklist (e.g. SCAP).  Or it may be a capability in a 3rd party tool.    If our understanding is correct, that end-user will be able to proceed in managing the configuration of that system with little to no need to cross-reference across other sources of configuration information.

That is, while there may be "a slew of proprietary ID's based on multiple interpretations", the end user would never see them or need to deal with them.

If we're wrong on this.... If it is the case that users need to coordinate and cross-reference across multiple sources of configuration information, we need to hear why.

Microsoft and Polycom have both just told us that coordination costs with CCE are too expensive.

Why would things fail if Microsoft and Polycom just produced and self-published their own proprietary IDs?




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

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

Dave writes:
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?

Yes.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Mann>, David Mann <[hidden email]>
Date: Tuesday, October 2, 2012 3:10 PM
To: cce-working-group-list <[hidden email]>
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

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] How Are Internal Checklists Created and Used?

Mann, Dave
Erik asks:
One question I have is even if proprietary IDs were used, wouldn't there need to be some standards in place as to the format and structure to prevent duplicate IDs being used by multiple companies or organizations?

I think all that is needed is copyright claims by each organization over their own ID space.

For example, I am relatively certain that Red Hat enforces copyright on the format RHBA-YYYY-NNNN for their advisory numbers.  This ensures that nobody other than Red Hat can publish an ID with that format, hence no duplication.

The same could be said for Microsoft's advisory number scheme.  


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


-----Original Message-----
From: Cockrell, Erik [mailto:[hidden email]]
Sent: Tuesday, October 09, 2012 3:18 PM
To: Mann, Dave; cce-working-group-list
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

One question I have is even if proprietary IDs were used, wouldn't there need to be some standards in place as to the format and structure to prevent duplicate IDs being used by multiple companies or organizations?

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

Dave writes:
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?

Kent Landfield responded:
Yes.

Adam Montvale responded:
Yes.

TK Keanini responded:
Yes.


Dave re-asks....

Why?


We really need to understand what breaks if there is no CCE (and there is only proprietary IDs).

John Banghart wrote:
This argument is flawed.  First, the concept of "end users" is far to nebulous to use in a broadly sweeping manner. Plenty of users don't get to choose what guidance they use, others don't care, some do, and so on.
Secondly, the value of security automation specifications isn't to the end users.  It's about helping users manage and report their system state in as accurately and timely a manner as possible without having to understand how it works under the hood.  It isn't clear to me how it would help them to have a slew of proprietary ID's based on multiple interpretations.


Dave re-asks....

And it isn't clear to us what breaks if there are, in fact, a slew of proprietary IDs based on multiple interpretations.

Our (limited) sense is that when end users confront a system, they do so based primarily on a single set of guidance. That guidance may be an prose security guide.  It may be an automated checklist (e.g. SCAP).  Or it may be a capability in a 3rd party tool.    If our understanding is correct, that end-user will be able to proceed in managing the configuration of that system with little to no need to cross-reference across other sources of configuration information.

That is, while there may be "a slew of proprietary ID's based on multiple interpretations", the end user would never see them or need to deal with them.

If we're wrong on this.... If it is the case that users need to coordinate and cross-reference across multiple sources of configuration information, we need to hear why.

Microsoft and Polycom have both just told us that coordination costs with CCE are too expensive.

Why would things fail if Microsoft and Polycom just produced and self-published their own proprietary IDs?




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

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

Dave writes:
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?

Yes.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Mann>, David Mann <[hidden email]>
Date: Tuesday, October 2, 2012 3:10 PM
To: cce-working-group-list <[hidden email]>
Subject: RE: [CCE-WORKING-GROUP-LIST] How Are Internal Checklists Created and Used?

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 ==================================================================
12
Loading...