[CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

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

[CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Mann, Dave
Folks,

We've been listening to and processing all of the various points of view.  As always, your input and guidance is helpful.

There are several unresolved issues but one thing has come through loud and clear.  For CCE to scale, we need to dramatically simplify CCE's data requirements.  On the plus side, this will allow submitters of information (like Microsoft and potentially RedHat) to automate their submissions.  

On the possible downside, this will give downstream consumers of CCE less information to work with.

Of the potential producers of CCEs, we would like to ask, "Is this proposed simplified data fields more achievable?"

Of the downstream consumers of CCEs, we would like to ask, "Can you live with this as a minimum?"

If you are a consumer of CCE information, please resist the urge to ask for more information unless critical processes utterly fail for you.   The message has been clearly delivered and fully understood.  We must simplify the data demands to allow CCE to scale.


=====
PROPOSED CCE DATA FIELDS
=====

NAME: This is a text string that is unique within the platform group.  This may be "names" associated with GUI constructs, command names or navigation paths.   This field replaces and simplifies the previous "Description" field.

TECHNICAL MECHANISM: This field remains unchanged.  For each CCE, provide at least one way to set the configuration control.  Note that on some systems, this may be the same as the "Name".

REFERENCE/CITATION:  This field remains unchanged.  For each CCE, provide at least one reference document (or published tool or capability) along with a granular citation or location for more information.


=====
REMOVED CCE DATA FIELD
=====
DESCRIPTION: Is replaced with NAME.  See above.

PARAMETERS: Is removed entirely as it cannot be easily automated.



-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] PROPOSAL: Dramatically Simplified CCE Data Fields

Jesper Jurcenoks
I like it

Nice and simple like CVE

Jesper Jurcenoks

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Wednesday, October 17, 2012 12:26 PM
To: [hidden email]
Subject: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Folks,

We've been listening to and processing all of the various points of view.  As always, your input and guidance is helpful.

There are several unresolved issues but one thing has come through loud and clear.  For CCE to scale, we need to dramatically simplify CCE's data requirements.  On the plus side, this will allow submitters of information (like Microsoft and potentially RedHat) to automate their submissions.  

On the possible downside, this will give downstream consumers of CCE less information to work with.

Of the potential producers of CCEs, we would like to ask, "Is this proposed simplified data fields more achievable?"

Of the downstream consumers of CCEs, we would like to ask, "Can you live with this as a minimum?"

If you are a consumer of CCE information, please resist the urge to ask for more information unless critical processes utterly fail for you.   The message has been clearly delivered and fully understood.  We must simplify the data demands to allow CCE to scale.


=====
PROPOSED CCE DATA FIELDS
=====

NAME: This is a text string that is unique within the platform group.  This may be "names" associated with GUI constructs, command names or navigation paths.   This field replaces and simplifies the previous "Description" field.

TECHNICAL MECHANISM: This field remains unchanged.  For each CCE, provide at least one way to set the configuration control.  Note that on some systems, this may be the same as the "Name".

REFERENCE/CITATION:  This field remains unchanged.  For each CCE, provide at least one reference document (or published tool or capability) along with a granular citation or location for more information.


=====
REMOVED CCE DATA FIELD
=====
DESCRIPTION: Is replaced with NAME.  See above.

PARAMETERS: Is removed entirely as it cannot be easily automated.



-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] PROPOSAL: Dramatically Simplified CCE Data Fields

Cockrell, Erik
Agreed.  Polycom as a CCE producer would support this.

-----Original Message-----
From: Jesper Jurcenoks [mailto:[hidden email]]
Sent: Wednesday, October 17, 2012 11:49 PM
To: [hidden email]
Subject: Re: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

I like it

Nice and simple like CVE

Jesper Jurcenoks

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Wednesday, October 17, 2012 12:26 PM
To: [hidden email]
Subject: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Folks,

We've been listening to and processing all of the various points of view.  As always, your input and guidance is helpful.

There are several unresolved issues but one thing has come through loud and clear.  For CCE to scale, we need to dramatically simplify CCE's data requirements.  On the plus side, this will allow submitters of information (like Microsoft and potentially RedHat) to automate their submissions.  

On the possible downside, this will give downstream consumers of CCE less information to work with.

Of the potential producers of CCEs, we would like to ask, "Is this proposed simplified data fields more achievable?"

Of the downstream consumers of CCEs, we would like to ask, "Can you live with this as a minimum?"

If you are a consumer of CCE information, please resist the urge to ask for more information unless critical processes utterly fail for you.   The message has been clearly delivered and fully understood.  We must simplify the data demands to allow CCE to scale.


=====
PROPOSED CCE DATA FIELDS
=====

NAME: This is a text string that is unique within the platform group.  This may be "names" associated with GUI constructs, command names or navigation paths.   This field replaces and simplifies the previous "Description" field.

TECHNICAL MECHANISM: This field remains unchanged.  For each CCE, provide at least one way to set the configuration control.  Note that on some systems, this may be the same as the "Name".

REFERENCE/CITATION:  This field remains unchanged.  For each CCE, provide at least one reference document (or published tool or capability) along with a granular citation or location for more information.


=====
REMOVED CCE DATA FIELD
=====
DESCRIPTION: Is replaced with NAME.  See above.

PARAMETERS: Is removed entirely as it cannot be easily automated.



-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] PROPOSAL: Dramatically Simplified CCE Data Fields

Blake Frantz
In reply to this post by Mann, Dave
Hi Dave/*,

Given that schema changes are on the table I thought I'd share some thoughts and questions. Most of which you've probably considered before. Hopefully, some of my spewing will be constructive. Here's the abridged version:

A. Consider making "Parameters" optional so we can preserve CCSS-to-CCE-state mappings
B. Consider punting or redefining Technical Mechanisms as it seem less than useful
C. Question on proposed scope of "Name"
D. Consider replacing /cce/@platform with a set of applicable CPEs
E. Consider structuring the Name field or adding optional metadata fields to help with automating CCE analysis.

The rest of this email attempts to provide context for the above items.

Thanks for your time.

Blake

[begin lt;dr;]

I understand and treat "Parameters" as "possible states" for the given CCE. If that is invalid, ignore the next paragraph.

A. Consider making "Parameters" optional so we can preserve CCSS-to-CCE-state mappings:

Dropping "Parameters" will make CCEs easier for us to produce. However, I have concern that doing so may impact our ability to bind a CCSS score to a given CCE state as there is a many-to-one relationship between CCSS scores and a given CCE. See http://www.ietf.org/mail-archive/web/sacm/current/msg00122.html for ramblings on this. If folks want CCSS-to-CCE-state mappings while not blocking CCE creation, we may need to make "Parameters" optional. That being said, this may already be solved by some activity I'm ignorant to.

I understand "Technical Mechanisms" primary intent is to participate in the remediation workflow.  If that is invalid, ignore the next paragraph.

B. Consider punting or redefining Technical Mechanisms as it seem less than useful:

When I talk with folks about remediation content, they typically want it in one of two forms:

1. A statement or procedure that conveys some action for a human to take.
        a. "Set the Protocol directive in /etc/ssh/sshd_config to 2"
        b. "Disable the chargen service"
2. A blob or structured value that is consumed by software that intends to implement the given state.
        a. <insert shell pipeline or script here>
        b. <insert OVAL/SCE/ECL here>

Is this consistent with what others are hearing/doing? If so, the technical mechanism field doesn't seem to provide much value as defined. Perhaps this field gets punted or redefined to reference an optional collection of CRE-IDs.

C. Question on proposed scope of "Name":

In the proposed schema, is an example of a "platform group"  something like "Windows" or something like "Windows 7 SP1"? The reason I ask is historically distinct CCEs were generated for Windows 7 and Windows XP for the same "Name", i.e Disable Guest. It seems there may be some energy behind reducing the platform specificity of CCE and I'm curious if your proposal intends to do that or if I'm reading in to things a bit.  

If a given CCE "Name" is to remain scoped to a single, specific platform, then skipping the next paragraph with give you 30 seconds of your life back.

D. Consider replacing /cce/@platform with a set of applicable CPEs:

We may want to consider swapping out the /cce/@platform attribute for a set of CPEv2.3s the given CCE applies to. A potential advantage of doing this is it may provide consistency, flexibility, and efficiency when authoring CCEs. If Red Hat wants to submit one master set of CCEs that apply to RHEL 4,5,6 then they can do that and CPE-aware software will understand what to do. If what SteveG suggests regarding other Linux vendors unknowingly reusing RHEL CCEs occurs, and it doesn't seem unlikely, we can simply add additional CPE entries to the affected CCEs instead of creating a new set of CCEs for each Linux distro.  We could abstract or restrict the scope of a CCE as much or as little as makes sense by leveraging CPEv2.3's flexibility.

E. Consider structuring the Name field or adding optional metadata fields to help with automating CCE analysis.

It seems there is some agreement that adding automation to the CCE review and creation process is ideal. In order for the review component to be automated, w/o dishing out namespaces to each CCE submitter, it seems the Name field needs to be something software can take action on. With that in mind, consider the following examples as possible values a "Name" might have:

Assume our CCE scope is an OS.

service['sshd'].state
user['guest'].state
group['administrators'].membership
file['/etc/passwd'].mode
file['c:\boot.ini'].owner
interface['*'].protocols.ipv6.state

Assume our CCE scope is "OpenSSH"

config['protocol']
config['banner']

Assume our CCE scope is "Windows"

gpo['computer\security settings\foo']
registry['hkml\foo\bar']

Taken with the "platform" attribute or a CPE, the above concept may help automate the analysis of CCEs, including the detection of collisions. On the CCE creation side, this is harder to generate than your proposed form, but may not be horribly awfully terrible. The above seems to reduce to two components: the "artifact type" (i.e  file contents, kernel param, reg key value, service state, etc) and the "artifact instance". I suspect most CCE producers know these values. The downside of this is it adds complexity, may require us to agree on a grammar or enumerations of valid "artifact types", and may not be able to model all configuration knobs we seek to reference.  Or, perhaps we keep "Name" as you've defined it and add optional/metadata fields for artifact type, instance, or similar to help with CCE analysis. This is a concept we've been kicking around at CIS to improve our benchmark development process.
 
[end tl;dr;]

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Wednesday, October 17, 2012 12:29 PM
To: [hidden email]
Subject: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Folks,

We've been listening to and processing all of the various points of view.  As always, your input and guidance is helpful.

There are several unresolved issues but one thing has come through loud and clear.  For CCE to scale, we need to dramatically simplify CCE's data requirements.  On the plus side, this will allow submitters of information (like Microsoft and potentially RedHat) to automate their submissions.  

On the possible downside, this will give downstream consumers of CCE less information to work with.

Of the potential producers of CCEs, we would like to ask, "Is this proposed simplified data fields more achievable?"

Of the downstream consumers of CCEs, we would like to ask, "Can you live with this as a minimum?"

If you are a consumer of CCE information, please resist the urge to ask for more information unless critical processes utterly fail for you.   The message has been clearly delivered and fully understood.  We must simplify the data demands to allow CCE to scale.


=====
PROPOSED CCE DATA FIELDS
=====

NAME: This is a text string that is unique within the platform group.  This may be "names" associated with GUI constructs, command names or navigation paths.   This field replaces and simplifies the previous "Description" field.

TECHNICAL MECHANISM: This field remains unchanged.  For each CCE, provide at least one way to set the configuration control.  Note that on some systems, this may be the same as the "Name".

REFERENCE/CITATION:  This field remains unchanged.  For each CCE, provide at least one reference document (or published tool or capability) along with a granular citation or location for more information.


=====
REMOVED CCE DATA FIELD
=====
DESCRIPTION: Is replaced with NAME.  See above.

PARAMETERS: Is removed entirely as it cannot be easily automated.



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

...


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

[CCE-WORKING-GROUP-LIST] FW: [External] Re: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Mann, Dave
Could somebody remove this guy

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


-----Original Message-----
From: Halbardier, Adam [USA] [mailto:[hidden email]]
Sent: Thursday, October 18, 2012 12:01 PM
To: Mann, Dave
Subject: RE: [External] Re: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Hi Dave,

I can't find unsubscribe instructions for this list on the CCE website. Could you provide it?

Thanks,
Adam

-----Original Message-----
From: Blake Frantz [mailto:[hidden email]]
Sent: Thursday, October 18, 2012 8:44 AM
To: [hidden email]
Subject: [External] Re: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Hi Dave/*,

Given that schema changes are on the table I thought I'd share some thoughts and questions. Most of which you've probably considered before. Hopefully, some of my spewing will be constructive. Here's the abridged version:

A. Consider making "Parameters" optional so we can preserve CCSS-to-CCE-state mappings B. Consider punting or redefining Technical Mechanisms as it seem less than useful C. Question on proposed scope of "Name"
D. Consider replacing /cce/@platform with a set of applicable CPEs E. Consider structuring the Name field or adding optional metadata fields to help with automating CCE analysis.

The rest of this email attempts to provide context for the above items.

Thanks for your time.

Blake

[begin lt;dr;]

I understand and treat "Parameters" as "possible states" for the given CCE. If that is invalid, ignore the next paragraph.

A. Consider making "Parameters" optional so we can preserve CCSS-to-CCE-state mappings:

Dropping "Parameters" will make CCEs easier for us to produce. However, I have concern that doing so may impact our ability to bind a CCSS score to a given CCE state as there is a many-to-one relationship between CCSS scores and a given CCE. See http://www.ietf.org/mail-archive/web/sacm/current/msg00122.html for ramblings on this. If folks want CCSS-to-CCE-state mappings while not blocking CCE creation, we may need to make "Parameters" optional. That being said, this may already be solved by some activity I'm ignorant to.

I understand "Technical Mechanisms" primary intent is to participate in the remediation workflow.  If that is invalid, ignore the next paragraph.

B. Consider punting or redefining Technical Mechanisms as it seem less than useful:

When I talk with folks about remediation content, they typically want it in one of two forms:

1. A statement or procedure that conveys some action for a human to take.
        a. "Set the Protocol directive in /etc/ssh/sshd_config to 2"
        b. "Disable the chargen service"
2. A blob or structured value that is consumed by software that intends to implement the given state.
        a. <insert shell pipeline or script here>
        b. <insert OVAL/SCE/ECL here>

Is this consistent with what others are hearing/doing? If so, the technical mechanism field doesn't seem to provide much value as defined. Perhaps this field gets punted or redefined to reference an optional collection of CRE-IDs.

C. Question on proposed scope of "Name":

In the proposed schema, is an example of a "platform group"  something like "Windows" or something like "Windows 7 SP1"? The reason I ask is historically distinct CCEs were generated for Windows 7 and Windows XP for the same "Name", i.e Disable Guest. It seems there may be some energy behind reducing the platform specificity of CCE and I'm curious if your proposal intends to do that or if I'm reading in to things a bit.  

If a given CCE "Name" is to remain scoped to a single, specific platform, then skipping the next paragraph with give you 30 seconds of your life back.

D. Consider replacing /cce/@platform with a set of applicable CPEs:

We may want to consider swapping out the /cce/@platform attribute for a set of CPEv2.3s the given CCE applies to. A potential advantage of doing this is it may provide consistency, flexibility, and efficiency when authoring CCEs. If Red Hat wants to submit one master set of CCEs that apply to RHEL 4,5,6 then they can do that and CPE-aware software will understand what to do. If what SteveG suggests regarding other Linux vendors unknowingly reusing RHEL CCEs occurs, and it doesn't seem unlikely, we can simply add additional CPE entries to the affected CCEs instead of creating a new set of CCEs for each Linux distro.  We could abstract or restrict the scope of a CCE as much or as little as makes sense by leveraging CPEv2.3's flexibility.

E. Consider structuring the Name field or adding optional metadata fields to help with automating CCE analysis.

It seems there is some agreement that adding automation to the CCE review and creation process is ideal. In order for the review component to be automated, w/o dishing out namespaces to each CCE submitter, it seems the Name field needs to be something software can take action on. With that in mind, consider the following examples as possible values a "Name" might have:

Assume our CCE scope is an OS.

service['sshd'].state
user['guest'].state
group['administrators'].membership
file['/etc/passwd'].mode
file['c:\boot.ini'].owner
interface['*'].protocols.ipv6.state

Assume our CCE scope is "OpenSSH"

config['protocol']
config['banner']

Assume our CCE scope is "Windows"

gpo['computer\security settings\foo']
registry['hkml\foo\bar']

Taken with the "platform" attribute or a CPE, the above concept may help automate the analysis of CCEs, including the detection of collisions. On the CCE creation side, this is harder to generate than your proposed form, but may not be horribly awfully terrible. The above seems to reduce to two components: the "artifact type" (i.e  file contents, kernel param, reg key value, service state, etc) and the "artifact instance". I suspect most CCE producers know these values. The downside of this is it adds complexity, may require us to agree on a grammar or enumerations of valid "artifact types", and may not be able to model all configuration knobs we seek to reference.  Or, perhaps we keep "Name" as you've defined it and add optional/metadata fields for artifact type, instance, or similar to help with CCE analysis. This is a concept we've been kicking around at CIS to improve our benchmark development process.
 
[end tl;dr;]

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Wednesday, October 17, 2012 12:29 PM
To: [hidden email]
Subject: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Folks,

We've been listening to and processing all of the various points of view.  As always, your input and guidance is helpful.

There are several unresolved issues but one thing has come through loud and clear.  For CCE to scale, we need to dramatically simplify CCE's data requirements.  On the plus side, this will allow submitters of information (like Microsoft and potentially RedHat) to automate their submissions.  

On the possible downside, this will give downstream consumers of CCE less information to work with.

Of the potential producers of CCEs, we would like to ask, "Is this proposed simplified data fields more achievable?"

Of the downstream consumers of CCEs, we would like to ask, "Can you live with this as a minimum?"

If you are a consumer of CCE information, please resist the urge to ask for more information unless critical processes utterly fail for you.   The message has been clearly delivered and fully understood.  We must simplify the data demands to allow CCE to scale.


=====
PROPOSED CCE DATA FIELDS
=====

NAME: This is a text string that is unique within the platform group.  This may be "names" associated with GUI constructs, command names or navigation paths.   This field replaces and simplifies the previous "Description" field.

TECHNICAL MECHANISM: This field remains unchanged.  For each CCE, provide at least one way to set the configuration control.  Note that on some systems, this may be the same as the "Name".

REFERENCE/CITATION:  This field remains unchanged.  For each CCE, provide at least one reference document (or published tool or capability) along with a granular citation or location for more information.


=====
REMOVED CCE DATA FIELD
=====
DESCRIPTION: Is replaced with NAME.  See above.

PARAMETERS: Is removed entirely as it cannot be easily automated.



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

...


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

Re: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Adam Montville
In reply to this post by Blake Frantz
I like the idea of reducing CCE's data requirements.

I also have some comments regarding Blake's response, provided inline.

Regards,

Adam

On 10/18/12 8:44 AM, "Blake Frantz" <[hidden email]> wrote:

>Hi Dave/*,
>
>Given that schema changes are on the table I thought I'd share some
>thoughts and questions. Most of which you've probably considered before.
>Hopefully, some of my spewing will be constructive. Here's the abridged
>version:
>
>A. Consider making "Parameters" optional so we can preserve
>CCSS-to-CCE-state mappings
>B. Consider punting or redefining Technical Mechanisms as it seem less
>than useful

I agree with this idea.  If CCE is really an identifier, then let it be
that.  If we need some way to talk about technical mechanisms, then we can
create that separately - alternatively, we already have some indication of
appropriate technical mechanisms buried in OVAL content.

>C. Question on proposed scope of "Name"
>D. Consider replacing /cce/@platform with a set of applicable CPEs

At first glance, I like this idea a lot.  It feels cleaner than having
separate CCEs for the same name per platform.  I'm sure there are nuances
in terms of valid parameters and/or technical mechanisms, but if we're
stripping some or all of that information out to leave CCE as a simple
identifier, I don't see - on the surface - why this approach wouldn't work.

>E. Consider structuring the Name field or adding optional metadata fields
>to help with automating CCE analysis.

I like this idea as well, though we could simply step into it.  It seems
that we could modularize things a bit by cleaning up CCE and then creating
augmentations as driven by real-world use cases.  Analysis of the
configuration items identified by CCEs would be an epic with several
stories, I think.

>
>The rest of this email attempts to provide context for the above items.
>
>Thanks for your time.
>
>Blake
>
>[begin lt;dr;]
>
>I understand and treat "Parameters" as "possible states" for the given
>CCE. If that is invalid, ignore the next paragraph.
>
>A. Consider making "Parameters" optional so we can preserve
>CCSS-to-CCE-state mappings:
>
>Dropping "Parameters" will make CCEs easier for us to produce. However, I
>have concern that doing so may impact our ability to bind a CCSS score to
>a given CCE state as there is a many-to-one relationship between CCSS
>scores and a given CCE. See
>http://www.ietf.org/mail-archive/web/sacm/current/msg00122.html for
>ramblings on this. If folks want CCSS-to-CCE-state mappings while not
>blocking CCE creation, we may need to make "Parameters" optional. That
>being said, this may already be solved by some activity I'm ignorant to.
>
>I understand "Technical Mechanisms" primary intent is to participate in
>the remediation workflow.  If that is invalid, ignore the next paragraph.
>
>B. Consider punting or redefining Technical Mechanisms as it seem less
>than useful:
>
>When I talk with folks about remediation content, they typically want it
>in one of two forms:
>
>1. A statement or procedure that conveys some action for a human to take.
> a. "Set the Protocol directive in /etc/ssh/sshd_config to 2"
> b. "Disable the chargen service"
>2. A blob or structured value that is consumed by software that intends
>to implement the given state.
> a. <insert shell pipeline or script here>
> b. <insert OVAL/SCE/ECL here>
>
>Is this consistent with what others are hearing/doing? If so, the
>technical mechanism field doesn't seem to provide much value as defined.
>Perhaps this field gets punted or redefined to reference an optional
>collection of CRE-IDs.
>
>C. Question on proposed scope of "Name":
>
>In the proposed schema, is an example of a "platform group"  something
>like "Windows" or something like "Windows 7 SP1"? The reason I ask is
>historically distinct CCEs were generated for Windows 7 and Windows XP
>for the same "Name", i.e Disable Guest. It seems there may be some energy
>behind reducing the platform specificity of CCE and I'm curious if your
>proposal intends to do that or if I'm reading in to things a bit.
>
>If a given CCE "Name" is to remain scoped to a single, specific platform,
>then skipping the next paragraph with give you 30 seconds of your life
>back.
>
>D. Consider replacing /cce/@platform with a set of applicable CPEs:
>
>We may want to consider swapping out the /cce/@platform attribute for a
>set of CPEv2.3s the given CCE applies to. A potential advantage of doing
>this is it may provide consistency, flexibility, and efficiency when
>authoring CCEs. If Red Hat wants to submit one master set of CCEs that
>apply to RHEL 4,5,6 then they can do that and CPE-aware software will
>understand what to do. If what SteveG suggests regarding other Linux
>vendors unknowingly reusing RHEL CCEs occurs, and it doesn't seem
>unlikely, we can simply add additional CPE entries to the affected CCEs
>instead of creating a new set of CCEs for each Linux distro.  We could
>abstract or restrict the scope of a CCE as much or as little as makes
>sense by leveraging CPEv2.3's flexibility.
>
>E. Consider structuring the Name field or adding optional metadata fields
>to help with automating CCE analysis.
>
>It seems there is some agreement that adding automation to the CCE review
>and creation process is ideal. In order for the review component to be
>automated, w/o dishing out namespaces to each CCE submitter, it seems the
>Name field needs to be something software can take action on. With that
>in mind, consider the following examples as possible values a "Name"
>might have:
>
>Assume our CCE scope is an OS.
>
>service['sshd'].state
>user['guest'].state
>group['administrators'].membership
>file['/etc/passwd'].mode
>file['c:\boot.ini'].owner
>interface['*'].protocols.ipv6.state
>
>Assume our CCE scope is "OpenSSH"
>
>config['protocol']
>config['banner']
>
>Assume our CCE scope is "Windows"
>
>gpo['computer\security settings\foo']
>registry['hkml\foo\bar']
>
>Taken with the "platform" attribute or a CPE, the above concept may help
>automate the analysis of CCEs, including the detection of collisions. On
>the CCE creation side, this is harder to generate than your proposed
>form, but may not be horribly awfully terrible. The above seems to reduce
>to two components: the "artifact type" (i.e  file contents, kernel param,
>reg key value, service state, etc) and the "artifact instance". I suspect
>most CCE producers know these values. The downside of this is it adds
>complexity, may require us to agree on a grammar or enumerations of valid
>"artifact types", and may not be able to model all configuration knobs we
>seek to reference.  Or, perhaps we keep "Name" as you've defined it and
>add optional/metadata fields for artifact type, instance, or similar to
>help with CCE analysis. This is a concept we've been kicking around at
>CIS to improve our benchmark development process.
>
>[end tl;dr;]
>
>-----Original Message-----
>From: Mann, Dave [mailto:[hidden email]]
>Sent: Wednesday, October 17, 2012 12:29 PM
>To: [hidden email]
>Subject: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE
>Data Fields
>
>Folks,
>
>We've been listening to and processing all of the various points of view.
> As always, your input and guidance is helpful.
>
>There are several unresolved issues but one thing has come through loud
>and clear.  For CCE to scale, we need to dramatically simplify CCE's data
>requirements.  On the plus side, this will allow submitters of
>information (like Microsoft and potentially RedHat) to automate their
>submissions.  
>
>On the possible downside, this will give downstream consumers of CCE less
>information to work with.
>
>Of the potential producers of CCEs, we would like to ask, "Is this
>proposed simplified data fields more achievable?"
>
>Of the downstream consumers of CCEs, we would like to ask, "Can you live
>with this as a minimum?"
>
>If you are a consumer of CCE information, please resist the urge to ask
>for more information unless critical processes utterly fail for you.
>The message has been clearly delivered and fully understood.  We must
>simplify the data demands to allow CCE to scale.
>
>
>=====
>PROPOSED CCE DATA FIELDS
>=====
>
>NAME: This is a text string that is unique within the platform group.
>This may be "names" associated with GUI constructs, command names or
>navigation paths.   This field replaces and simplifies the previous
>"Description" field.
>
>TECHNICAL MECHANISM: This field remains unchanged.  For each CCE, provide
>at least one way to set the configuration control.  Note that on some
>systems, this may be the same as the "Name".
>
>REFERENCE/CITATION:  This field remains unchanged.  For each CCE, provide
>at least one reference document (or published tool or capability) along
>with a granular citation or location for more information.
>
>
>=====
>REMOVED CCE DATA FIELD
>=====
>DESCRIPTION: Is replaced with NAME.  See above.
>
>PARAMETERS: Is removed entirely as it cannot be easily automated.
>
>
>
>-Dave
>==================================================================
>David Mann | Principal Infosec Scientist | The MITRE Corporation
>------------------------------------------------------------------
>e-mail:[hidden email] | cell:781.424.6003
>==================================================================
>
>...
>
>
>This message and attachments may contain confidential information.  If it
>appears that this message was sent to you by mistake, any retention,
>dissemination, distribution or copying of this message and attachments is
>strictly prohibited.  Please notify the sender immediately and
>permanently delete the message and any attachments.
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE Data Fields

Adam Montville
Will anyone on this list be attending IETF 85 next week?  If so, would it make sense to meet to discuss some of these issues?

Regards,

Adam W. Montville | Security and Compliance Architect
CISA, CISSP

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | Take CONTROL






On Oct 22, 2012, at 3:10 PM, Adam Montville <[hidden email]> wrote:

I like the idea of reducing CCE's data requirements.

I also have some comments regarding Blake's response, provided inline.

Regards,

Adam

On 10/18/12 8:44 AM, "Blake Frantz" <[hidden email]> wrote:

Hi Dave/*,

Given that schema changes are on the table I thought I'd share some
thoughts and questions. Most of which you've probably considered before.
Hopefully, some of my spewing will be constructive. Here's the abridged
version:

A. Consider making "Parameters" optional so we can preserve
CCSS-to-CCE-state mappings
B. Consider punting or redefining Technical Mechanisms as it seem less
than useful

I agree with this idea.  If CCE is really an identifier, then let it be
that.  If we need some way to talk about technical mechanisms, then we can
create that separately - alternatively, we already have some indication of
appropriate technical mechanisms buried in OVAL content.

C. Question on proposed scope of "Name"
D. Consider replacing /cce/@platform with a set of applicable CPEs

At first glance, I like this idea a lot.  It feels cleaner than having
separate CCEs for the same name per platform.  I'm sure there are nuances
in terms of valid parameters and/or technical mechanisms, but if we're
stripping some or all of that information out to leave CCE as a simple
identifier, I don't see - on the surface - why this approach wouldn't work.

E. Consider structuring the Name field or adding optional metadata fields
to help with automating CCE analysis.

I like this idea as well, though we could simply step into it.  It seems
that we could modularize things a bit by cleaning up CCE and then creating
augmentations as driven by real-world use cases.  Analysis of the
configuration items identified by CCEs would be an epic with several
stories, I think.


The rest of this email attempts to provide context for the above items.

Thanks for your time.

Blake

[begin lt;dr;]

I understand and treat "Parameters" as "possible states" for the given
CCE. If that is invalid, ignore the next paragraph.

A. Consider making "Parameters" optional so we can preserve
CCSS-to-CCE-state mappings:

Dropping "Parameters" will make CCEs easier for us to produce. However, I
have concern that doing so may impact our ability to bind a CCSS score to
a given CCE state as there is a many-to-one relationship between CCSS
scores and a given CCE. See
http://www.ietf.org/mail-archive/web/sacm/current/msg00122.html for
ramblings on this. If folks want CCSS-to-CCE-state mappings while not
blocking CCE creation, we may need to make "Parameters" optional. That
being said, this may already be solved by some activity I'm ignorant to.

I understand "Technical Mechanisms" primary intent is to participate in
the remediation workflow.  If that is invalid, ignore the next paragraph.

B. Consider punting or redefining Technical Mechanisms as it seem less
than useful:

When I talk with folks about remediation content, they typically want it
in one of two forms:

1. A statement or procedure that conveys some action for a human to take.
a. "Set the Protocol directive in /etc/ssh/sshd_config to 2"
b. "Disable the chargen service"
2. A blob or structured value that is consumed by software that intends
to implement the given state.
a. <insert shell pipeline or script here>
b. <insert OVAL/SCE/ECL here>

Is this consistent with what others are hearing/doing? If so, the
technical mechanism field doesn't seem to provide much value as defined.
Perhaps this field gets punted or redefined to reference an optional
collection of CRE-IDs.

C. Question on proposed scope of "Name":

In the proposed schema, is an example of a "platform group"  something
like "Windows" or something like "Windows 7 SP1"? The reason I ask is
historically distinct CCEs were generated for Windows 7 and Windows XP
for the same "Name", i.e Disable Guest. It seems there may be some energy
behind reducing the platform specificity of CCE and I'm curious if your
proposal intends to do that or if I'm reading in to things a bit.

If a given CCE "Name" is to remain scoped to a single, specific platform,
then skipping the next paragraph with give you 30 seconds of your life
back.

D. Consider replacing /cce/@platform with a set of applicable CPEs:

We may want to consider swapping out the /cce/@platform attribute for a
set of CPEv2.3s the given CCE applies to. A potential advantage of doing
this is it may provide consistency, flexibility, and efficiency when
authoring CCEs. If Red Hat wants to submit one master set of CCEs that
apply to RHEL 4,5,6 then they can do that and CPE-aware software will
understand what to do. If what SteveG suggests regarding other Linux
vendors unknowingly reusing RHEL CCEs occurs, and it doesn't seem
unlikely, we can simply add additional CPE entries to the affected CCEs
instead of creating a new set of CCEs for each Linux distro.  We could
abstract or restrict the scope of a CCE as much or as little as makes
sense by leveraging CPEv2.3's flexibility.

E. Consider structuring the Name field or adding optional metadata fields
to help with automating CCE analysis.

It seems there is some agreement that adding automation to the CCE review
and creation process is ideal. In order for the review component to be
automated, w/o dishing out namespaces to each CCE submitter, it seems the
Name field needs to be something software can take action on. With that
in mind, consider the following examples as possible values a "Name"
might have:

Assume our CCE scope is an OS.

service['sshd'].state
user['guest'].state
group['administrators'].membership
file['/etc/passwd'].mode
file['c:\boot.ini'].owner
interface['*'].protocols.ipv6.state

Assume our CCE scope is "OpenSSH"

config['protocol']
config['banner']

Assume our CCE scope is "Windows"

gpo['computer\security settings\foo']
registry['hkml\foo\bar']

Taken with the "platform" attribute or a CPE, the above concept may help
automate the analysis of CCEs, including the detection of collisions. On
the CCE creation side, this is harder to generate than your proposed
form, but may not be horribly awfully terrible. The above seems to reduce
to two components: the "artifact type" (i.e  file contents, kernel param,
reg key value, service state, etc) and the "artifact instance". I suspect
most CCE producers know these values. The downside of this is it adds
complexity, may require us to agree on a grammar or enumerations of valid
"artifact types", and may not be able to model all configuration knobs we
seek to reference.  Or, perhaps we keep "Name" as you've defined it and
add optional/metadata fields for artifact type, instance, or similar to
help with CCE analysis. This is a concept we've been kicking around at
CIS to improve our benchmark development process.

[end tl;dr;]

-----Original Message-----
From: Mann, Dave [mailto:damann@MITRE.ORG]
Sent: Wednesday, October 17, 2012 12:29 PM
To: [hidden email]
Subject: [CCE-WORKING-GROUP-LIST] PROPOSAL: Dramatically Simplified CCE
Data Fields

Folks,

We've been listening to and processing all of the various points of view.
As always, your input and guidance is helpful.

There are several unresolved issues but one thing has come through loud
and clear.  For CCE to scale, we need to dramatically simplify CCE's data
requirements.  On the plus side, this will allow submitters of
information (like Microsoft and potentially RedHat) to automate their
submissions.  

On the possible downside, this will give downstream consumers of CCE less
information to work with.

Of the potential producers of CCEs, we would like to ask, "Is this
proposed simplified data fields more achievable?"

Of the downstream consumers of CCEs, we would like to ask, "Can you live
with this as a minimum?"

If you are a consumer of CCE information, please resist the urge to ask
for more information unless critical processes utterly fail for you.
The message has been clearly delivered and fully understood.  We must
simplify the data demands to allow CCE to scale.


=====
PROPOSED CCE DATA FIELDS
=====

NAME: This is a text string that is unique within the platform group.
This may be "names" associated with GUI constructs, command names or
navigation paths.   This field replaces and simplifies the previous
"Description" field.

TECHNICAL MECHANISM: This field remains unchanged.  For each CCE, provide
at least one way to set the configuration control.  Note that on some
systems, this may be the same as the "Name".

REFERENCE/CITATION:  This field remains unchanged.  For each CCE, provide
at least one reference document (or published tool or capability) along
with a granular citation or location for more information.


=====
REMOVED CCE DATA FIELD
=====
DESCRIPTION: Is replaced with NAME.  See above.

PARAMETERS: Is removed entirely as it cannot be easily automated.



-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:damann@mitre.org | cell:781.424.6003
==================================================================

...


This message and attachments may contain confidential information.  If it
appears that this message was sent to you by mistake, any retention,
dissemination, distribution or copying of this message and attachments is
strictly prohibited.  Please notify the sender immediately and
permanently delete the message and any attachments.




Loading...