CPE 2.3 technical drafts; CPE webconference

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CPE 2.3 technical drafts; CPE webconference

Brant Cheikes

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


cpe-dictionary-spec_20100507.pptx (264K) Download Attachment
cpe-naming-spec_20100507.pptx (244K) Download Attachment
Backward Compatibility 03May10.pptx (120K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Wolfkiel, Joseph

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.       The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.        I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.       I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.       With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.        I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Brant Cheikes

Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete message copied below.)  Rather than responding to them all in a single message, I’ll respond in separate messages.

 

This message addresses this comment:

Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

 

I’d say that there’s still a critical requirement for an authoritative source of unique product identifiers.  Whether that’s a single source (like NIST/NVD) or some federation of complementary authoritative sources is a separate question.  Heretofore, the dictionary has been the sine qua non of CPE—its indispensible ingredient.  Without a common reference for names, we don’t have an interoperability solution, just a common structure for passing around a specified but loosely defined set of attribute value pairs.  So I don’t see how we can do without a Dictionary specification—by specifying the format for dictionary entries and the rules to be used for assigning proper values to attributes, we effectively define how tool interoperability is achieved.

 

The validation point is an interesting one.  I could well imagine SCAP imposing a CPE conformance test to ensure that credentialed scanners always report products using the names listed in an “official dictionary” whenever a name for the intended product exists.  A weaker test would require that product names simply be “well formed”—this would work for non-credentialed network scanners which in effect generate patterns for matching against dictionary names.  A third validation test could confirm that patterns match the proper dictionary entries.  The details certainly need to be worked out, but the task seems quite doable—and essential if we are to ensure that CPE provides a true tool interoperability solution.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.       The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.        I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.       I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.       With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.        I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Brant Cheikes
In reply to this post by Wolfkiel, Joseph

Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete message copied below.)  Rather than responding to them all in a single message, I’ll respond in separate messages.

 

This message addresses this comment:

“With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.”

 

Regarding the suggestion of defining bindings in a specification document separate from naming, I’m quite supportive of that, at least in principle.  In practice it won’t work for v2.3.  We simply don’t have enough time to write a slew of separate specs.  For the moment, naming and bindings are going to have to be defined in the same specification.  In the future, I think it would be a good idea to break the bindings out separately.

 

I’m not sure I understand the suggestion that we might define “some number of transport formats”.  Within the Core Team we discussed the idea of allowing more than one binding, but this kept raising an interoperability objection.  Suppose we defined and allowed 15 different formats (above you hinted at least five).  Which one(s) must vendors implement?  Should a CPE-conformant vulnerability management tool be required to recognize and accept all 15 different formats?  Our sense within the team was that the vendors want us to specify a single format, rather than deal with an open-ended and potentially extensible set.  So for now we’ve chosen to stick with the (flawed) URI and URI-like bindings (the former purely for reasons of backward compatibility with 2.2).  Before we go introducing the possibility of many alternate bindings, I’d like to better understand how to do that without creating an interoperability nightmare.  Do we really want vendors trying to differentiate their products based on which CPE name binding(s) they support?

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.       The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.        I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.       I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.       With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.        I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Waltermire, David A.
In reply to this post by Brant Cheikes

We also have a use case under SCAP today where a stripped down CPE dictionary containing only the CPE names referenced in an XCCDF instance is included as part of an SCAP data stream.  This document is used to reference the associated OVAL inventory definition that should be used as a pre condition to the evaluation of a checklist.  We will need to continue this support in SCAP validated products to address content backwards compatibility concerns.

 

Sincerely,

 

David Waltermire

SCAP Architect

National Institute of Standards and Technology

(301) 975-3390

[hidden email]


From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, May 18, 2010 6:31 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete message copied below.)  Rather than responding to them all in a single message, I’ll respond in separate messages.

 

This message addresses this comment:

Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

 

I’d say that there’s still a critical requirement for an authoritative source of unique product identifiers.  Whether that’s a single source (like NIST/NVD) or some federation of complementary authoritative sources is a separate question.  Heretofore, the dictionary has been the sine qua non of CPE—its indispensible ingredient.  Without a common reference for names, we don’t have an interoperability solution, just a common structure for passing around a specified but loosely defined set of attribute value pairs.  So I don’t see how we can do without a Dictionary specification—by specifying the format for dictionary entries and the rules to be used for assigning proper values to attributes, we effectively define how tool interoperability is achieved.

 

The validation point is an interesting one.  I could well imagine SCAP imposing a CPE conformance test to ensure that credentialed scanners always report products using the names listed in an “official dictionary” whenever a name for the intended product exists.  A weaker test would require that product names simply be “well formed”—this would work for non-credentialed network scanners which in effect generate patterns for matching against dictionary names.  A third validation test could confirm that patterns match the proper dictionary entries.  The details certainly need to be worked out, but the task seems quite doable—and essential if we are to ensure that CPE provides a true tool interoperability solution.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.    Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.   The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.    I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.   I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.   With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.   With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.    I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Brant Cheikes
In reply to this post by Wolfkiel, Joseph

This message contains a few miscellaneous responses to Lt Col Wolfkiel’s comments.

 

·         The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification. […]

 

Point taken; we are still evaluating the issues underlying the proposal for a “$” character to represent “unknown” attribute values.

 

·         But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth. […]

 

The [a1=v1,a2=v2,…] notation is used in the specification when describing so-called “well-formed names”.  It is not a binding (aka “transport”) and is clearly distinguished in the draft specification from bindings.  The Naming specification will clearly separate the conceptual definition of a well-formed name (WFN) from the definitions of their bindings to machine-readable representations suitable for exchange among machines.

 

That said, your comment suggests that our decisions about bindings should be partly driven by bandwidth/transmission concerns.  Could you elaborate these concerns?  The CPE 2.2 specification is completely silent on this point.  At the moment, we only envisage supporting two bindings: a v2.2-conformant URI (for backward compatibility) and a “formatted string” binding that looks very similar to a URI but does not have to adhere to all the character-set restrictions imposed on URIs.  I’d like to hear more about community requirements to minimize the size/complexity of name bindings.

 

·         I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them. 

 

Point taken; we are still evaluating the rationale for “other_edition”.  It may well be dropped.

 

·         With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

 

(Assume for now we’ve dropped other_edition.)  We’re not thinking of prohibiting the use of the “legacy” edition attribute—it’s stlll valid and needed for backward compatibility.  What we’re going to prohibit is the simultaneous use of both the “legacy” edition attribute and any of the newly-introduced attributes (i.e., sw_edition, target_sw, target_hw).  So if you use “legacy” edition, you can’t use any of sw_edition, target_sw, or target_hw; and if you use any of sw_edition, target_sw, or target_hw, you can’t use “legacy” edition.  In the 2.2 URI binding, if the “legacy” edition attribute is used, it is mapped into the 2.2 URI’s “edition” component.  If any of the new edition attributes are used, a “packing” operation is used to pack the three attribute values into the 2.2 URI’s “edition” component.  When creating a 2.3 formatted string binding, things work a bit differently, since the 2.3 binding does not have a place for “legacy” edition in addition to sw_edition, target_sw, and target_hw.  In this case, “legacy” edition (if used) is mapped to sw_edition and the other two attributes left blank.  Otherwise we map the specified values of sw_edition, target_sw, and target_hw to their positions in the 2.3 string binding.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.       The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.        I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.       I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.       With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.        I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Vladimir Giszpenc
In reply to this post by Brant Cheikes
Could we

1.  Keep XML as the must support protocol?
2.  Create a transform from each other protocol (JSON, binary, etc) to XML so a CPE consumer could transform what they get to XML?

 
Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete
message copied below.)  Rather than responding to them all in a single
message, I'll respond in separate messages.

 

This message addresses this comment:

"With respect to "Bindings" this is where I would like to get away from
specifying transport.   I think there should be a separate specification
governing transmission schemas/bindings for CPE.  That way we can define
more efficient/effective ways of transferring CPE information and still
claim compliance with using CPE "names."   If we can define some number of
transport formats in a separate spec, then tools can claim support for the
"URI" format, "attribute-based format", "tag value pair format", "binary
format", or "JSON format" and we can add/deprecate transport formats as
requirements are better defined *** without having to change the naming
specification***."

 

Regarding the suggestion of defining bindings in a specification document
separate from naming, I'm quite supportive of that, at least in principle.
In practice it won't work for v2.3.  We simply don't have enough time to
write a slew of separate specs.  For the moment, naming and bindings are
going to have to be defined in the same specification.  In the future, I
think it would be a good idea to break the bindings out separately.

 

I'm not sure I understand the suggestion that we might define "some number
of transport formats".  Within the Core Team we discussed the idea of
allowing more than one binding, but this kept raising an interoperability
objection.  Suppose we defined and allowed 15 different formats (above you
hinted at least five).  Which one(s) must vendors implement?  Should a
CPE-conformant vulnerability management tool be required to recognize and
accept all 15 different formats?  Our sense within the team was that the
vendors want us to specify a single format, rather than deal with an
open-ended and potentially extensible set.  So for now we've chosen to stick
with the (flawed) URI and URI-like bindings (the former purely for reasons
of backward compatibility with 2.2).  Before we go introducing the
possibility of many alternate bindings, I'd like to better understand how to
do that without creating an interoperability nightmare.  Do we really want
vendors trying to differentiate their products based on which CPE name
binding(s) they support?

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference

 

All,

 

I won't be able to join the conference until about halfway through, so I
thought I'd put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The
functionality described in the presentation distributed is not a product the
DoD would be interested in purchasing, nor would we expect to require "CPE
Dictionary" validation in any products we would buy.  Does anyone else
perceive the requirement to specify this information?  If a validation
program were set up for it, would anyone use it?

2.       The "$" appears to be an exact form/fit replacement for the "" with
respect to existing CPE specification.  I can't figure out what value it
adds, other than embodying the behavior we had previously assigned to "".
The down side is that it breaks backwards compatibility with 2.2 for CPE
consumers.  Is the benefit worth the price?  Alternatively, couldn't we use
the "*" symbol for that functionality?  Seems unnecessarily difficult to
implement a spec where "", "*", and "$" mean the same thing with respect to
matching.

 

CPE Naming Specification:

1.        I'm okay with using the example shown - as an example:

[a1="v1",a2="v2",.]

Ex1: [part="a",vendor="adobe",.]

Ex2: [part="o",version="3.*"]

-          But I want to avoid having the naming specification force us to
use the tag-value pair transport shown in the example.  This would force a
CPE name to take up a full line of XML for each part of a CPE name, which is
very wasteful of bandwidth.  Again, please separate transport from content
management.

2.       I'm very much on board with the addition of separate components for
sw_edition, target_sw, and target_hw, but can't figure out how adding
"other_edition" will be useful.  Seems like it would only end up being the
dumping place for names that should have better metadata labels (e.g. build
number) if we actually want to use them.  Suggest this would be a good place
to append an anyType or anyAttribute to allow for extensibility if we find
another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the "old" edition field, I'd
like to hear some other thought on that.  Seems like matching with CPE 2.2
names would require you to transport both, otherwise (since there were no
ordering rules in effect in CPE 2.2) there would not be any way to
concatenate the new attributes together in any known order to consistently
recreate the old edition information.

4.       With respect to "Bindings" this is where I would like to get away
from specifying transport.   I think there should be a separate
specification governing transmission schemas/bindings for CPE.  That way we
can define more efficient/effective ways of transferring CPE information and
still claim compliance with using CPE "names."   If we can define some
number of transport formats in a separate spec, then tools can claim support
for the "URI" format, "attribute-based format", "tag value pair format",
"binary format", or "JSON format" and we can add/deprecate transport formats
as requirements are better defined *** without having to change the naming
specification***.

 

Backward Compatibility:

1.        I'm not really worried about this issue.  I'm not aware that there
are any known consumers of the current CPE dictionary built into any
commercial or government products, so these issues may be largely
theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I've attached three technical works in progress intended to give everyone on
the list a sense of the direction we're heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the
monolithic CPE specification into four components, arranged in a stack.  At
the bottom of the stack is the Naming Specification.  I've attached a slide
deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still
working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the
specification stack.  I've attached a slide deck that summarizes plans for
the Dictionary.

 

A third slide deck on backward compatibility is also attached, for
reference.  As we prepared our designs for 2.3 we gave a lot of thought to
what "preserving backward compatibility" means for CPE.  The thinking
reflected in the attached charts ultimately guided our decisions about what
we could and could not do in a minor release of the CPE specification.
We've tried to thoughtfully balance the need to preserve backward
compatibility in a minor release with the community's need to see new
features introduced into the standard.

 

We look forward to feedback on any or all of these materials-please use the
cpe-list.  As a reminder, we've scheduled an open web conference for this
coming Friday for anyone who wants to ask questions or provide comments and
feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 ("CPECPE")

Meeting Password: 76466348 ("SOGOOD4U")

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or
Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to:
http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room
to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press
connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for
compatibility with the web conference. Follow this link to the browser test
link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Brant Cheikes
Vlad,

The "must support protocol" in 2.2 is the URI.  In the Core Team we've discussed making XML the required protocol in 2.3, and agreed that there would be benefits to doing so.  But ultimately we have chosen not to do so.  A major consideration is lack of time to develop and properly vet a new required binding that differs so dramatically from current practice.  If we want to introduce any new features into CPE 2.3, we need to get it into final draft form by the beginning of June--a mere couple of weeks away.  Consequently, we feel obliged to err on the side of caution for 2.3, make a few limited improvements within the available time window, then immediately start working more deliberatively and openly on a major release which will have a year to mature, and will be subjected to a much lengthier and more public review by the CPE user community.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Tuesday, May 18, 2010 9:09 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Could we

1.  Keep XML as the must support protocol?
2.  Create a transform from each other protocol (JSON, binary, etc) to XML so a CPE consumer could transform what they get to XML?

 
Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete
message copied below.)  Rather than responding to them all in a single
message, I'll respond in separate messages.

 

This message addresses this comment:

"With respect to "Bindings" this is where I would like to get away from
specifying transport.   I think there should be a separate specification
governing transmission schemas/bindings for CPE.  That way we can define
more efficient/effective ways of transferring CPE information and still
claim compliance with using CPE "names."   If we can define some number of
transport formats in a separate spec, then tools can claim support for the
"URI" format, "attribute-based format", "tag value pair format", "binary
format", or "JSON format" and we can add/deprecate transport formats as
requirements are better defined *** without having to change the naming
specification***."

 

Regarding the suggestion of defining bindings in a specification document
separate from naming, I'm quite supportive of that, at least in principle.
In practice it won't work for v2.3.  We simply don't have enough time to
write a slew of separate specs.  For the moment, naming and bindings are
going to have to be defined in the same specification.  In the future, I
think it would be a good idea to break the bindings out separately.

 

I'm not sure I understand the suggestion that we might define "some number
of transport formats".  Within the Core Team we discussed the idea of
allowing more than one binding, but this kept raising an interoperability
objection.  Suppose we defined and allowed 15 different formats (above you
hinted at least five).  Which one(s) must vendors implement?  Should a
CPE-conformant vulnerability management tool be required to recognize and
accept all 15 different formats?  Our sense within the team was that the
vendors want us to specify a single format, rather than deal with an
open-ended and potentially extensible set.  So for now we've chosen to stick
with the (flawed) URI and URI-like bindings (the former purely for reasons
of backward compatibility with 2.2).  Before we go introducing the
possibility of many alternate bindings, I'd like to better understand how to
do that without creating an interoperability nightmare.  Do we really want
vendors trying to differentiate their products based on which CPE name
binding(s) they support?

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference

 

All,

 

I won't be able to join the conference until about halfway through, so I
thought I'd put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The
functionality described in the presentation distributed is not a product the
DoD would be interested in purchasing, nor would we expect to require "CPE
Dictionary" validation in any products we would buy.  Does anyone else
perceive the requirement to specify this information?  If a validation
program were set up for it, would anyone use it?

2.       The "$" appears to be an exact form/fit replacement for the "" with
respect to existing CPE specification.  I can't figure out what value it
adds, other than embodying the behavior we had previously assigned to "".
The down side is that it breaks backwards compatibility with 2.2 for CPE
consumers.  Is the benefit worth the price?  Alternatively, couldn't we use
the "*" symbol for that functionality?  Seems unnecessarily difficult to
implement a spec where "", "*", and "$" mean the same thing with respect to
matching.

 

CPE Naming Specification:

1.        I'm okay with using the example shown - as an example:

[a1="v1",a2="v2",.]

Ex1: [part="a",vendor="adobe",.]

Ex2: [part="o",version="3.*"]

-          But I want to avoid having the naming specification force us to
use the tag-value pair transport shown in the example.  This would force a
CPE name to take up a full line of XML for each part of a CPE name, which is
very wasteful of bandwidth.  Again, please separate transport from content
management.

2.       I'm very much on board with the addition of separate components for
sw_edition, target_sw, and target_hw, but can't figure out how adding
"other_edition" will be useful.  Seems like it would only end up being the
dumping place for names that should have better metadata labels (e.g. build
number) if we actually want to use them.  Suggest this would be a good place
to append an anyType or anyAttribute to allow for extensibility if we find
another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the "old" edition field, I'd
like to hear some other thought on that.  Seems like matching with CPE 2.2
names would require you to transport both, otherwise (since there were no
ordering rules in effect in CPE 2.2) there would not be any way to
concatenate the new attributes together in any known order to consistently
recreate the old edition information.

4.       With respect to "Bindings" this is where I would like to get away
from specifying transport.   I think there should be a separate
specification governing transmission schemas/bindings for CPE.  That way we
can define more efficient/effective ways of transferring CPE information and
still claim compliance with using CPE "names."   If we can define some
number of transport formats in a separate spec, then tools can claim support
for the "URI" format, "attribute-based format", "tag value pair format",
"binary format", or "JSON format" and we can add/deprecate transport formats
as requirements are better defined *** without having to change the naming
specification***.

 

Backward Compatibility:

1.        I'm not really worried about this issue.  I'm not aware that there
are any known consumers of the current CPE dictionary built into any
commercial or government products, so these issues may be largely
theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I've attached three technical works in progress intended to give everyone on
the list a sense of the direction we're heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the
monolithic CPE specification into four components, arranged in a stack.  At
the bottom of the stack is the Naming Specification.  I've attached a slide
deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still
working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the
specification stack.  I've attached a slide deck that summarizes plans for
the Dictionary.

 

A third slide deck on backward compatibility is also attached, for
reference.  As we prepared our designs for 2.3 we gave a lot of thought to
what "preserving backward compatibility" means for CPE.  The thinking
reflected in the attached charts ultimately guided our decisions about what
we could and could not do in a minor release of the CPE specification.
We've tried to thoughtfully balance the need to preserve backward
compatibility in a minor release with the community's need to see new
features introduced into the standard.

 

We look forward to feedback on any or all of these materials-please use the
cpe-list.  As a reminder, we've scheduled an open web conference for this
coming Friday for anyone who wants to ask questions or provide comments and
feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 ("CPECPE")

Meeting Password: 76466348 ("SOGOOD4U")

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or
Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to:
http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room
to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press
connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for
compatibility with the web conference. Follow this link to the browser test
link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Vladimir Giszpenc
Brant.

In my first question replace "XML as the default" with "URI as the
default" and in the second replace "transform to XML" with "transform to
URI".  


My 2 cents:
Personally, I am all about transforms and I will share this so every
authenticated scanner gathering software inventory can get the same
results on hosts with rpm as the package manager.  Unfortunately, I
don't think the below algorithm translates to Windows, but if there is a
WMI way to do the equivalent, let's at least share that.  For all the
special sauce ways of determining versions (file dates, versions,
hashes, etc, don't share), but for the vanilla case it is probably
published somewhere already so let's at least share that.

1.  Get the list of packages from the package database. (language works
differently on Linux)

rpm -qa --qf
'(%{URL})(%{PACKAGER})(%{NAME})(%{EPOCH})(%{VERSION})(%{RELEASE})(%{ARCH
})\n'

for each line:
  2.  If URL doesn't exist use PACKAGER and if that doesn't exist use
NAME (our special sauce is no secret)
  3.  Escape special characters (point of contention, but necessary when
names contain colons and more)
  4.  cpestring = "cpe:/a:" + name + ":" + product + ":" + version + ":"
+ update + ":" + edition + ":"
  5.  convert to lowercase
  6.  convert abbreviations (this was considered for removal but is
still in the spec as far as I know)

These RPM packages come mostly from the Operating System vendor itself
so names are authoritative enough and they are signed to boot.  A
federated dictionary of OS vendor supplied names would certainly go a
long way to solve the 80/20 of naming.  Change the algorithm if you
want, but keep it algorithmic and we can even automatically generate the
dictionary (if you must have one).  For CPE to succeed, we must automate
the addition of new entries into the dictionary.  Anything less will be
too slow and too expensive.

Can we come up with algorithms for Mac, Debian and every other major OS
Vendor's package managers?


Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


> -----Original Message-----
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Wednesday, May 19, 2010 9:44 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Vlad,
>
> The "must support protocol" in 2.2 is the URI.  In the Core Team we've
discussed making XML the
> required protocol in 2.3, and agreed that there would be benefits to
doing so.  But ultimately we have
> chosen not to do so.  A major consideration is lack of time to develop
and properly vet a new required
> binding that differs so dramatically from current practice.  If we
want to introduce any new features
> into CPE 2.3, we need to get it into final draft form by the beginning
of June--a mere couple of weeks
> away.  Consequently, we feel obliged to err on the side of caution for
2.3, make a few limited
> improvements within the available time window, then immediately start
working more deliberatively and
> openly on a major release which will have a year to mature, and will
be subjected to a much lengthier

> and more public review by the CPE user community.
>
> /Brant
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
> -----Original Message-----
> From: Vladimir Giszpenc [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 9:09 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Could we
>
> 1.  Keep XML as the must support protocol?
> 2.  Create a transform from each other protocol (JSON, binary, etc) to
XML so a CPE consumer could
> transform what they get to XML?
>
>
> Lt Col Wolfkiel posted a number of concerns worth discussing.
(Complete
> message copied below.)  Rather than responding to them all in a single
> message, I'll respond in separate messages.
>
>
>
> This message addresses this comment:
>
> "With respect to "Bindings" this is where I would like to get away
from
> specifying transport.   I think there should be a separate
specification
> governing transmission schemas/bindings for CPE.  That way we can
define
> more efficient/effective ways of transferring CPE information and
still
> claim compliance with using CPE "names."   If we can define some
number of
> transport formats in a separate spec, then tools can claim support for
the
> "URI" format, "attribute-based format", "tag value pair format",
"binary
> format", or "JSON format" and we can add/deprecate transport formats
as
> requirements are better defined *** without having to change the
naming
> specification***."
>
>
>
> Regarding the suggestion of defining bindings in a specification
document
> separate from naming, I'm quite supportive of that, at least in
principle.
> In practice it won't work for v2.3.  We simply don't have enough time
to
> write a slew of separate specs.  For the moment, naming and bindings
are
> going to have to be defined in the same specification.  In the future,
I
> think it would be a good idea to break the bindings out separately.
>
>
>
> I'm not sure I understand the suggestion that we might define "some
number
> of transport formats".  Within the Core Team we discussed the idea of
> allowing more than one binding, but this kept raising an
interoperability
> objection.  Suppose we defined and allowed 15 different formats (above
you
> hinted at least five).  Which one(s) must vendors implement?  Should a
> CPE-conformant vulnerability management tool be required to recognize
and
> accept all 15 different formats?  Our sense within the team was that
the
> vendors want us to specify a single format, rather than deal with an
> open-ended and potentially extensible set.  So for now we've chosen to
stick
> with the (flawed) URI and URI-like bindings (the former purely for
reasons
> of backward compatibility with 2.2).  Before we go introducing the
> possibility of many alternate bindings, I'd like to better understand
how to
> do that without creating an interoperability nightmare.  Do we really
want

> vendors trying to differentiate their products based on which CPE name
> binding(s) they support?
>
>
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
> webconference
>
>
>
> All,
>
>
>
> I won't be able to join the conference until about halfway through, so
I
> thought I'd put my concerns out in an e-mail.
>
>
>
> CPE Dictionary Specification:
>
> 1.        Is there a requirement for a CPE Dictionary specification?
The
> functionality described in the presentation distributed is not a
product the
> DoD would be interested in purchasing, nor would we expect to require
"CPE
> Dictionary" validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation
> program were set up for it, would anyone use it?
>
> 2.       The "$" appears to be an exact form/fit replacement for the
"" with
> respect to existing CPE specification.  I can't figure out what value
it
> adds, other than embodying the behavior we had previously assigned to
"".
> The down side is that it breaks backwards compatibility with 2.2 for
CPE
> consumers.  Is the benefit worth the price?  Alternatively, couldn't
we use
> the "*" symbol for that functionality?  Seems unnecessarily difficult
to
> implement a spec where "", "*", and "$" mean the same thing with
respect to

> matching.
>
>
>
> CPE Naming Specification:
>
> 1.        I'm okay with using the example shown - as an example:
>
> [a1="v1",a2="v2",.]
>
> Ex1: [part="a",vendor="adobe",.]
>
> Ex2: [part="o",version="3.*"]
>
> -          But I want to avoid having the naming specification force
us to
> use the tag-value pair transport shown in the example.  This would
force a
> CPE name to take up a full line of XML for each part of a CPE name,
which is
> very wasteful of bandwidth.  Again, please separate transport from
content
> management.
>
> 2.       I'm very much on board with the addition of separate
components for
> sw_edition, target_sw, and target_hw, but can't figure out how adding
> "other_edition" will be useful.  Seems like it would only end up being
the
> dumping place for names that should have better metadata labels (e.g.
build
> number) if we actually want to use them.  Suggest this would be a good
place
> to append an anyType or anyAttribute to allow for extensibility if we
find
> another name part we want to formally bring into CPE.
>
> 3.       With respect to prohibiting use of the "old" edition field,
I'd
> like to hear some other thought on that.  Seems like matching with CPE
2.2
> names would require you to transport both, otherwise (since there were
no
> ordering rules in effect in CPE 2.2) there would not be any way to
> concatenate the new attributes together in any known order to
consistently
> recreate the old edition information.
>
> 4.       With respect to "Bindings" this is where I would like to get
away
> from specifying transport.   I think there should be a separate
> specification governing transmission schemas/bindings for CPE.  That
way we
> can define more efficient/effective ways of transferring CPE
information and
> still claim compliance with using CPE "names."   If we can define some
> number of transport formats in a separate spec, then tools can claim
support
> for the "URI" format, "attribute-based format", "tag value pair
format",
> "binary format", or "JSON format" and we can add/deprecate transport
formats
> as requirements are better defined *** without having to change the
naming
> specification***.
>
>
>
> Backward Compatibility:
>
> 1.        I'm not really worried about this issue.  I'm not aware that
there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely
> theoretical.
>
>
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
Program

> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>
>
>
> CPE Community,
>
>
>
> I've attached three technical works in progress intended to give
everyone on
> the list a sense of the direction we're heading with CPE v2.3.
>
>
>
> As noted in the roadmap I posted on 22 April, we are planning to break
the
> monolithic CPE specification into four components, arranged in a
stack.  At
> the bottom of the stack is the Naming Specification.  I've attached a
slide
> deck that summarizes our plans for this part of the standard.
>
>
>
> The Matching Specification will be layered on top of Naming.  We are
still
> working on the technical plan for Matching.
>
>
>
> The Dictionary and CPE Language Specifications are peers at the top of
the
> specification stack.  I've attached a slide deck that summarizes plans
for
> the Dictionary.
>
>
>
> A third slide deck on backward compatibility is also attached, for
> reference.  As we prepared our designs for 2.3 we gave a lot of
thought to
> what "preserving backward compatibility" means for CPE.  The thinking
> reflected in the attached charts ultimately guided our decisions about
what
> we could and could not do in a minor release of the CPE specification.
> We've tried to thoughtfully balance the need to preserve backward
> compatibility in a minor release with the community's need to see new
> features introduced into the standard.
>
>
>
> We look forward to feedback on any or all of these materials-please
use the
> cpe-list.  As a reminder, we've scheduled an open web conference for
this
> coming Friday for anyone who wants to ask questions or provide
comments and

> feedback.  Conference information is shown below.
>
>
>
> Conference Information:
>
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
>
> Meeting ID: 273273 ("CPECPE")
>
> Meeting Password: 76466348 ("SOGOOD4U")
>
>
>
> TO ATTEND THE AUDIO CONFERENCE:
>
>
>
> Dial 781-271-6338 from the Bedford, MA region.
>
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>
>
>
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>
>
>
> 1. Go to:
> http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
>
> 2. Click on Attend Meeting.
>
>    - Accept any security warnings you receive and wait for the Meeting
Room
> to initialize.
>
> 3. If MeetingPlace Collaboration Window does not automatically open,
press

> connect.
>
>
>
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>
>
>
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser
test

> link on the page.
>
>
>
> Cheers,
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Brant Cheikes
Vlad,

So if I understand you correctly, you're advocating for requiring the 2.2 URI as the must-support protocol.  Actually, our current plan in 2.3 is to require conformant implementations to support BOTH the 2.2 URI (for backward compatibility) AND the new 2.3 formatted string.  Here's the thing: one of the features we're trying to introduce in 2.3 is support for single and multi-character wildcards.  But we can't do that in a 2.2 URI because of the requirements for percent-encoding.  If 2.3 requires only the URI binding we basically eliminate a good argument for upgrading.

Re your second point: "we must automate the addition of new entries into the dictionary".  I'm very sympathetic to this point of view, but thus far I haven't come across any reliable way to do this such that I could tweak the spec to accommodate it.

Also, I'm not sure I understand what you're suggesting re use of each system's installed-package manager.  You might be saying that we should design system-specific algorithms (as you have done) for pulling data from the system's package manager and using that to generate CPE names--FOR THE SOLE PURPOSE OF RAPIDLY POPULATING A DICTIONARY.  As I understand it, comprehensive inventory scanners need to look at everything on the hard disk, not just what a package manager says is installed.  So the RPM-oriented method cannot be a standard for doing inventory, and we cannot say that a CPE dictionary will only contain entries for products discoverable using the package manager.

I could go on, but let me leave it at this: (1) I am supportive of trying to make the generation of CPE names as automatic as possible, (2) I have yet to hear a proposal for a feasible way to do this that works across all the platforms we need to deal with, and copes with all the different ways that products are installed.  Devising such a proposal would be an excellent objective for a technical working group.  Anyone want to pull one together and prepare a detailed proposal?  I would be more than willing to advise and participate.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 10:56 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Brant.

In my first question replace "XML as the default" with "URI as the
default" and in the second replace "transform to XML" with "transform to
URI".


My 2 cents:
Personally, I am all about transforms and I will share this so every
authenticated scanner gathering software inventory can get the same
results on hosts with rpm as the package manager.  Unfortunately, I
don't think the below algorithm translates to Windows, but if there is a
WMI way to do the equivalent, let's at least share that.  For all the
special sauce ways of determining versions (file dates, versions,
hashes, etc, don't share), but for the vanilla case it is probably
published somewhere already so let's at least share that.

1.  Get the list of packages from the package database. (language works
differently on Linux)

rpm -qa --qf
'(%{URL})(%{PACKAGER})(%{NAME})(%{EPOCH})(%{VERSION})(%{RELEASE})(%{ARCH
})\n'

for each line:
  2.  If URL doesn't exist use PACKAGER and if that doesn't exist use
NAME (our special sauce is no secret)
  3.  Escape special characters (point of contention, but necessary when
names contain colons and more)
  4.  cpestring = "cpe:/a:" + name + ":" + product + ":" + version + ":"
+ update + ":" + edition + ":"
  5.  convert to lowercase
  6.  convert abbreviations (this was considered for removal but is
still in the spec as far as I know)

These RPM packages come mostly from the Operating System vendor itself
so names are authoritative enough and they are signed to boot.  A
federated dictionary of OS vendor supplied names would certainly go a
long way to solve the 80/20 of naming.  Change the algorithm if you
want, but keep it algorithmic and we can even automatically generate the
dictionary (if you must have one).  For CPE to succeed, we must automate
the addition of new entries into the dictionary.  Anything less will be
too slow and too expensive.

Can we come up with algorithms for Mac, Debian and every other major OS
Vendor's package managers?


Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


> -----Original Message-----
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Wednesday, May 19, 2010 9:44 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Vlad,
>
> The "must support protocol" in 2.2 is the URI.  In the Core Team we've
discussed making XML the
> required protocol in 2.3, and agreed that there would be benefits to
doing so.  But ultimately we have
> chosen not to do so.  A major consideration is lack of time to develop
and properly vet a new required
> binding that differs so dramatically from current practice.  If we
want to introduce any new features
> into CPE 2.3, we need to get it into final draft form by the beginning
of June--a mere couple of weeks
> away.  Consequently, we feel obliged to err on the side of caution for
2.3, make a few limited
> improvements within the available time window, then immediately start
working more deliberatively and
> openly on a major release which will have a year to mature, and will
be subjected to a much lengthier

> and more public review by the CPE user community.
>
> /Brant
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
> -----Original Message-----
> From: Vladimir Giszpenc [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 9:09 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Could we
>
> 1.  Keep XML as the must support protocol?
> 2.  Create a transform from each other protocol (JSON, binary, etc) to
XML so a CPE consumer could
> transform what they get to XML?
>
>
> Lt Col Wolfkiel posted a number of concerns worth discussing.
(Complete
> message copied below.)  Rather than responding to them all in a single
> message, I'll respond in separate messages.
>
>
>
> This message addresses this comment:
>
> "With respect to "Bindings" this is where I would like to get away
from
> specifying transport.   I think there should be a separate
specification
> governing transmission schemas/bindings for CPE.  That way we can
define
> more efficient/effective ways of transferring CPE information and
still
> claim compliance with using CPE "names."   If we can define some
number of
> transport formats in a separate spec, then tools can claim support for
the
> "URI" format, "attribute-based format", "tag value pair format",
"binary
> format", or "JSON format" and we can add/deprecate transport formats
as
> requirements are better defined *** without having to change the
naming
> specification***."
>
>
>
> Regarding the suggestion of defining bindings in a specification
document
> separate from naming, I'm quite supportive of that, at least in
principle.
> In practice it won't work for v2.3.  We simply don't have enough time
to
> write a slew of separate specs.  For the moment, naming and bindings
are
> going to have to be defined in the same specification.  In the future,
I
> think it would be a good idea to break the bindings out separately.
>
>
>
> I'm not sure I understand the suggestion that we might define "some
number
> of transport formats".  Within the Core Team we discussed the idea of
> allowing more than one binding, but this kept raising an
interoperability
> objection.  Suppose we defined and allowed 15 different formats (above
you
> hinted at least five).  Which one(s) must vendors implement?  Should a
> CPE-conformant vulnerability management tool be required to recognize
and
> accept all 15 different formats?  Our sense within the team was that
the
> vendors want us to specify a single format, rather than deal with an
> open-ended and potentially extensible set.  So for now we've chosen to
stick
> with the (flawed) URI and URI-like bindings (the former purely for
reasons
> of backward compatibility with 2.2).  Before we go introducing the
> possibility of many alternate bindings, I'd like to better understand
how to
> do that without creating an interoperability nightmare.  Do we really
want

> vendors trying to differentiate their products based on which CPE name
> binding(s) they support?
>
>
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
> webconference
>
>
>
> All,
>
>
>
> I won't be able to join the conference until about halfway through, so
I
> thought I'd put my concerns out in an e-mail.
>
>
>
> CPE Dictionary Specification:
>
> 1.        Is there a requirement for a CPE Dictionary specification?
The
> functionality described in the presentation distributed is not a
product the
> DoD would be interested in purchasing, nor would we expect to require
"CPE
> Dictionary" validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation
> program were set up for it, would anyone use it?
>
> 2.       The "$" appears to be an exact form/fit replacement for the
"" with
> respect to existing CPE specification.  I can't figure out what value
it
> adds, other than embodying the behavior we had previously assigned to
"".
> The down side is that it breaks backwards compatibility with 2.2 for
CPE
> consumers.  Is the benefit worth the price?  Alternatively, couldn't
we use
> the "*" symbol for that functionality?  Seems unnecessarily difficult
to
> implement a spec where "", "*", and "$" mean the same thing with
respect to

> matching.
>
>
>
> CPE Naming Specification:
>
> 1.        I'm okay with using the example shown - as an example:
>
> [a1="v1",a2="v2",.]
>
> Ex1: [part="a",vendor="adobe",.]
>
> Ex2: [part="o",version="3.*"]
>
> -          But I want to avoid having the naming specification force
us to
> use the tag-value pair transport shown in the example.  This would
force a
> CPE name to take up a full line of XML for each part of a CPE name,
which is
> very wasteful of bandwidth.  Again, please separate transport from
content
> management.
>
> 2.       I'm very much on board with the addition of separate
components for
> sw_edition, target_sw, and target_hw, but can't figure out how adding
> "other_edition" will be useful.  Seems like it would only end up being
the
> dumping place for names that should have better metadata labels (e.g.
build
> number) if we actually want to use them.  Suggest this would be a good
place
> to append an anyType or anyAttribute to allow for extensibility if we
find
> another name part we want to formally bring into CPE.
>
> 3.       With respect to prohibiting use of the "old" edition field,
I'd
> like to hear some other thought on that.  Seems like matching with CPE
2.2
> names would require you to transport both, otherwise (since there were
no
> ordering rules in effect in CPE 2.2) there would not be any way to
> concatenate the new attributes together in any known order to
consistently
> recreate the old edition information.
>
> 4.       With respect to "Bindings" this is where I would like to get
away
> from specifying transport.   I think there should be a separate
> specification governing transmission schemas/bindings for CPE.  That
way we
> can define more efficient/effective ways of transferring CPE
information and
> still claim compliance with using CPE "names."   If we can define some
> number of transport formats in a separate spec, then tools can claim
support
> for the "URI" format, "attribute-based format", "tag value pair
format",
> "binary format", or "JSON format" and we can add/deprecate transport
formats
> as requirements are better defined *** without having to change the
naming
> specification***.
>
>
>
> Backward Compatibility:
>
> 1.        I'm not really worried about this issue.  I'm not aware that
there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely
> theoretical.
>
>
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
Program

> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>
>
>
> CPE Community,
>
>
>
> I've attached three technical works in progress intended to give
everyone on
> the list a sense of the direction we're heading with CPE v2.3.
>
>
>
> As noted in the roadmap I posted on 22 April, we are planning to break
the
> monolithic CPE specification into four components, arranged in a
stack.  At
> the bottom of the stack is the Naming Specification.  I've attached a
slide
> deck that summarizes our plans for this part of the standard.
>
>
>
> The Matching Specification will be layered on top of Naming.  We are
still
> working on the technical plan for Matching.
>
>
>
> The Dictionary and CPE Language Specifications are peers at the top of
the
> specification stack.  I've attached a slide deck that summarizes plans
for
> the Dictionary.
>
>
>
> A third slide deck on backward compatibility is also attached, for
> reference.  As we prepared our designs for 2.3 we gave a lot of
thought to
> what "preserving backward compatibility" means for CPE.  The thinking
> reflected in the attached charts ultimately guided our decisions about
what
> we could and could not do in a minor release of the CPE specification.
> We've tried to thoughtfully balance the need to preserve backward
> compatibility in a minor release with the community's need to see new
> features introduced into the standard.
>
>
>
> We look forward to feedback on any or all of these materials-please
use the
> cpe-list.  As a reminder, we've scheduled an open web conference for
this
> coming Friday for anyone who wants to ask questions or provide
comments and

> feedback.  Conference information is shown below.
>
>
>
> Conference Information:
>
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
>
> Meeting ID: 273273 ("CPECPE")
>
> Meeting Password: 76466348 ("SOGOOD4U")
>
>
>
> TO ATTEND THE AUDIO CONFERENCE:
>
>
>
> Dial 781-271-6338 from the Bedford, MA region.
>
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>
>
>
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>
>
>
> 1. Go to:
> http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
>
> 2. Click on Attend Meeting.
>
>    - Accept any security warnings you receive and wait for the Meeting
Room
> to initialize.
>
> 3. If MeetingPlace Collaboration Window does not automatically open,
press

> connect.
>
>
>
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>
>
>
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser
test

> link on the page.
>
>
>
> Cheers,
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Wolfkiel, Joseph
I'm with Vladimir on this one.

We (the DoD) don't want to ever be in a position where we don't find out
about a new piece of software on our networks because a vendor had to wait
for the CPE dictionary to be updated prior to reporting it.

What I've asked several of our GOTS tool developers to do is to make a best
effort at populating a CPE name based on the assumption that we can then
fix/update the names via a robust deprecation and/or aliasing process.

For example, if a software product registers a vendor, product, and version
name in a Windows registry, I asked our tool developers to just convert the
given components into legal CPE names and put them in the URI format - i.e.
change upper case letters to lower, percent encode special characters, and
replace spaces with underscores.  It then becomes the problem of the central
report receiving tool to map these non-dictionary CPE names to dictionary
compliant names and maintain an alias list.

We are looking at building a CPE deprecation/management system in the future
that can send messages back to the originating sensor instructing it to
either 1) stop using the initial name and deprecate to a CPE dictionary
compliant name, or 2) not to report that name again since it isn't an
installed software product.  These messages could/can also be used to update
CPE lists as the CPE Dictionary deprecates names over time.  In ARF 0.41.2,
I added an attribute titled nameString where text that may indicate an
installed software product, but can't be identified as a CPE component can
be put, then mapped to a CPE name.  However, you could achieve a similar
effect in CPE 2.2 by just dumping all the text into the "product" field and
letting an analyst figure it out.

Something like this methodology would allow assessment tools to report
discovered software pending the process of adding them to the official CPE
dictionary, then having the vendors add the names to a tool-specific lookup
table.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700
-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:25 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Vlad,

So if I understand you correctly, you're advocating for requiring the 2.2
URI as the must-support protocol.  Actually, our current plan in 2.3 is to
require conformant implementations to support BOTH the 2.2 URI (for backward
compatibility) AND the new 2.3 formatted string.  Here's the thing: one of
the features we're trying to introduce in 2.3 is support for single and
multi-character wildcards.  But we can't do that in a 2.2 URI because of the
requirements for percent-encoding.  If 2.3 requires only the URI binding we
basically eliminate a good argument for upgrading.

Re your second point: "we must automate the addition of new entries into the
dictionary".  I'm very sympathetic to this point of view, but thus far I
haven't come across any reliable way to do this such that I could tweak the
spec to accommodate it.

Also, I'm not sure I understand what you're suggesting re use of each
system's installed-package manager.  You might be saying that we should
design system-specific algorithms (as you have done) for pulling data from
the system's package manager and using that to generate CPE names--FOR THE
SOLE PURPOSE OF RAPIDLY POPULATING A DICTIONARY.  As I understand it,
comprehensive inventory scanners need to look at everything on the hard
disk, not just what a package manager says is installed.  So the
RPM-oriented method cannot be a standard for doing inventory, and we cannot
say that a CPE dictionary will only contain entries for products
discoverable using the package manager.

I could go on, but let me leave it at this: (1) I am supportive of trying to
make the generation of CPE names as automatic as possible, (2) I have yet to
hear a proposal for a feasible way to do this that works across all the
platforms we need to deal with, and copes with all the different ways that
products are installed.  Devising such a proposal would be an excellent
objective for a technical working group.  Anyone want to pull one together
and prepare a detailed proposal?  I would be more than willing to advise and
participate.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 10:56 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Brant.

In my first question replace "XML as the default" with "URI as the
default" and in the second replace "transform to XML" with "transform to
URI".


My 2 cents:
Personally, I am all about transforms and I will share this so every
authenticated scanner gathering software inventory can get the same
results on hosts with rpm as the package manager.  Unfortunately, I
don't think the below algorithm translates to Windows, but if there is a
WMI way to do the equivalent, let's at least share that.  For all the
special sauce ways of determining versions (file dates, versions,
hashes, etc, don't share), but for the vanilla case it is probably
published somewhere already so let's at least share that.

1.  Get the list of packages from the package database. (language works
differently on Linux)

rpm -qa --qf
'(%{URL})(%{PACKAGER})(%{NAME})(%{EPOCH})(%{VERSION})(%{RELEASE})(%{ARCH
})\n'

for each line:
  2.  If URL doesn't exist use PACKAGER and if that doesn't exist use
NAME (our special sauce is no secret)
  3.  Escape special characters (point of contention, but necessary when
names contain colons and more)
  4.  cpestring = "cpe:/a:" + name + ":" + product + ":" + version + ":"
+ update + ":" + edition + ":"
  5.  convert to lowercase
  6.  convert abbreviations (this was considered for removal but is
still in the spec as far as I know)

These RPM packages come mostly from the Operating System vendor itself
so names are authoritative enough and they are signed to boot.  A
federated dictionary of OS vendor supplied names would certainly go a
long way to solve the 80/20 of naming.  Change the algorithm if you
want, but keep it algorithmic and we can even automatically generate the
dictionary (if you must have one).  For CPE to succeed, we must automate
the addition of new entries into the dictionary.  Anything less will be
too slow and too expensive.

Can we come up with algorithms for Mac, Debian and every other major OS
Vendor's package managers?


Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


> -----Original Message-----
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Wednesday, May 19, 2010 9:44 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Vlad,
>
> The "must support protocol" in 2.2 is the URI.  In the Core Team we've
discussed making XML the
> required protocol in 2.3, and agreed that there would be benefits to
doing so.  But ultimately we have
> chosen not to do so.  A major consideration is lack of time to develop
and properly vet a new required
> binding that differs so dramatically from current practice.  If we
want to introduce any new features
> into CPE 2.3, we need to get it into final draft form by the beginning
of June--a mere couple of weeks
> away.  Consequently, we feel obliged to err on the side of caution for
2.3, make a few limited
> improvements within the available time window, then immediately start
working more deliberatively and
> openly on a major release which will have a year to mature, and will
be subjected to a much lengthier

> and more public review by the CPE user community.
>
> /Brant
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
> -----Original Message-----
> From: Vladimir Giszpenc [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 9:09 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Could we
>
> 1.  Keep XML as the must support protocol?
> 2.  Create a transform from each other protocol (JSON, binary, etc) to
XML so a CPE consumer could
> transform what they get to XML?
>
>
> Lt Col Wolfkiel posted a number of concerns worth discussing.
(Complete
> message copied below.)  Rather than responding to them all in a single
> message, I'll respond in separate messages.
>
>
>
> This message addresses this comment:
>
> "With respect to "Bindings" this is where I would like to get away
from
> specifying transport.   I think there should be a separate
specification
> governing transmission schemas/bindings for CPE.  That way we can
define
> more efficient/effective ways of transferring CPE information and
still
> claim compliance with using CPE "names."   If we can define some
number of
> transport formats in a separate spec, then tools can claim support for
the
> "URI" format, "attribute-based format", "tag value pair format",
"binary
> format", or "JSON format" and we can add/deprecate transport formats
as
> requirements are better defined *** without having to change the
naming
> specification***."
>
>
>
> Regarding the suggestion of defining bindings in a specification
document
> separate from naming, I'm quite supportive of that, at least in
principle.
> In practice it won't work for v2.3.  We simply don't have enough time
to
> write a slew of separate specs.  For the moment, naming and bindings
are
> going to have to be defined in the same specification.  In the future,
I
> think it would be a good idea to break the bindings out separately.
>
>
>
> I'm not sure I understand the suggestion that we might define "some
number
> of transport formats".  Within the Core Team we discussed the idea of
> allowing more than one binding, but this kept raising an
interoperability
> objection.  Suppose we defined and allowed 15 different formats (above
you
> hinted at least five).  Which one(s) must vendors implement?  Should a
> CPE-conformant vulnerability management tool be required to recognize
and
> accept all 15 different formats?  Our sense within the team was that
the
> vendors want us to specify a single format, rather than deal with an
> open-ended and potentially extensible set.  So for now we've chosen to
stick
> with the (flawed) URI and URI-like bindings (the former purely for
reasons
> of backward compatibility with 2.2).  Before we go introducing the
> possibility of many alternate bindings, I'd like to better understand
how to
> do that without creating an interoperability nightmare.  Do we really
want

> vendors trying to differentiate their products based on which CPE name
> binding(s) they support?
>
>
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
> webconference
>
>
>
> All,
>
>
>
> I won't be able to join the conference until about halfway through, so
I
> thought I'd put my concerns out in an e-mail.
>
>
>
> CPE Dictionary Specification:
>
> 1.        Is there a requirement for a CPE Dictionary specification?
The
> functionality described in the presentation distributed is not a
product the
> DoD would be interested in purchasing, nor would we expect to require
"CPE
> Dictionary" validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation
> program were set up for it, would anyone use it?
>
> 2.       The "$" appears to be an exact form/fit replacement for the
"" with
> respect to existing CPE specification.  I can't figure out what value
it
> adds, other than embodying the behavior we had previously assigned to
"".
> The down side is that it breaks backwards compatibility with 2.2 for
CPE
> consumers.  Is the benefit worth the price?  Alternatively, couldn't
we use
> the "*" symbol for that functionality?  Seems unnecessarily difficult
to
> implement a spec where "", "*", and "$" mean the same thing with
respect to

> matching.
>
>
>
> CPE Naming Specification:
>
> 1.        I'm okay with using the example shown - as an example:
>
> [a1="v1",a2="v2",.]
>
> Ex1: [part="a",vendor="adobe",.]
>
> Ex2: [part="o",version="3.*"]
>
> -          But I want to avoid having the naming specification force
us to
> use the tag-value pair transport shown in the example.  This would
force a
> CPE name to take up a full line of XML for each part of a CPE name,
which is
> very wasteful of bandwidth.  Again, please separate transport from
content
> management.
>
> 2.       I'm very much on board with the addition of separate
components for
> sw_edition, target_sw, and target_hw, but can't figure out how adding
> "other_edition" will be useful.  Seems like it would only end up being
the
> dumping place for names that should have better metadata labels (e.g.
build
> number) if we actually want to use them.  Suggest this would be a good
place
> to append an anyType or anyAttribute to allow for extensibility if we
find
> another name part we want to formally bring into CPE.
>
> 3.       With respect to prohibiting use of the "old" edition field,
I'd
> like to hear some other thought on that.  Seems like matching with CPE
2.2
> names would require you to transport both, otherwise (since there were
no
> ordering rules in effect in CPE 2.2) there would not be any way to
> concatenate the new attributes together in any known order to
consistently
> recreate the old edition information.
>
> 4.       With respect to "Bindings" this is where I would like to get
away
> from specifying transport.   I think there should be a separate
> specification governing transmission schemas/bindings for CPE.  That
way we
> can define more efficient/effective ways of transferring CPE
information and
> still claim compliance with using CPE "names."   If we can define some
> number of transport formats in a separate spec, then tools can claim
support
> for the "URI" format, "attribute-based format", "tag value pair
format",
> "binary format", or "JSON format" and we can add/deprecate transport
formats
> as requirements are better defined *** without having to change the
naming
> specification***.
>
>
>
> Backward Compatibility:
>
> 1.        I'm not really worried about this issue.  I'm not aware that
there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely
> theoretical.
>
>
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
Program

> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>
>
>
> CPE Community,
>
>
>
> I've attached three technical works in progress intended to give
everyone on
> the list a sense of the direction we're heading with CPE v2.3.
>
>
>
> As noted in the roadmap I posted on 22 April, we are planning to break
the
> monolithic CPE specification into four components, arranged in a
stack.  At
> the bottom of the stack is the Naming Specification.  I've attached a
slide
> deck that summarizes our plans for this part of the standard.
>
>
>
> The Matching Specification will be layered on top of Naming.  We are
still
> working on the technical plan for Matching.
>
>
>
> The Dictionary and CPE Language Specifications are peers at the top of
the
> specification stack.  I've attached a slide deck that summarizes plans
for
> the Dictionary.
>
>
>
> A third slide deck on backward compatibility is also attached, for
> reference.  As we prepared our designs for 2.3 we gave a lot of
thought to
> what "preserving backward compatibility" means for CPE.  The thinking
> reflected in the attached charts ultimately guided our decisions about
what
> we could and could not do in a minor release of the CPE specification.
> We've tried to thoughtfully balance the need to preserve backward
> compatibility in a minor release with the community's need to see new
> features introduced into the standard.
>
>
>
> We look forward to feedback on any or all of these materials-please
use the
> cpe-list.  As a reminder, we've scheduled an open web conference for
this
> coming Friday for anyone who wants to ask questions or provide
comments and

> feedback.  Conference information is shown below.
>
>
>
> Conference Information:
>
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
>
> Meeting ID: 273273 ("CPECPE")
>
> Meeting Password: 76466348 ("SOGOOD4U")
>
>
>
> TO ATTEND THE AUDIO CONFERENCE:
>
>
>
> Dial 781-271-6338 from the Bedford, MA region.
>
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>
>
>
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>
>
>
> 1. Go to:
> http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
>
> 2. Click on Attend Meeting.
>
>    - Accept any security warnings you receive and wait for the Meeting
Room
> to initialize.
>
> 3. If MeetingPlace Collaboration Window does not automatically open,
press

> connect.
>
>
>
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>
>
>
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser
test

> link on the page.
>
>
>
> Cheers,
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Wolfkiel, Joseph
In reply to this post by Brant Cheikes

Response to one issue below:

 

·         With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

 

(Assume for now we’ve dropped other_edition.)  We’re not thinking of prohibiting the use of the “legacy” edition attribute—it’s stlll valid and needed for backward compatibility.  What we’re going to prohibit is the simultaneous use of both the “legacy” edition attribute and any of the newly-introduced attributes (i.e., sw_edition, target_sw, target_hw).  So if you use “legacy” edition, you can’t use any of sw_edition, target_sw, or target_hw; and if you use any of sw_edition, target_sw, or target_hw, you can’t use “legacy” edition.  In the 2.2 URI binding, if the “legacy” edition attribute is used, it is mapped into the 2.2 URI’s “edition” component.  If any of the new edition attributes are used, a “packing” operation is used to pack the three attribute values into the 2.2 URI’s “edition” component.  When creating a 2.3 formatted string binding, things work a bit differently, since the 2.3 binding does not have a place for “legacy” edition in addition to sw_edition, target_sw, and target_hw.  In this case, “legacy” edition (if used) is mapped to sw_edition and the other two attributes left blank.  Otherwise we map the specified values of sw_edition, target_sw, and target_hw to their positions in the 2.3 string binding.

 

** In this case, if you allow the “old” edition field to be used, you can preserve matching with both 2.2 CPE names and 2.3 CPE names.  If you only allow sw_edition, target_sw, and target_hw fields in 2.3, there is no way to know what order to concatenate them together to rebuild the 2.2 “edition” field.  If you allow the old “edition” field while dictating that is ONLY to be used for 2.2 backwards interoperability, then you could, potentially, preserve backwards interoperability with 2.2 while using 2.3. **

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, May 18, 2010 8:06 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

This message contains a few miscellaneous responses to Lt Col Wolfkiel’s comments.

 

·         The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification. […]

 

Point taken; we are still evaluating the issues underlying the proposal for a “$” character to represent “unknown” attribute values.

 

·         But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth. […]

 

The [a1=v1,a2=v2,…] notation is used in the specification when describing so-called “well-formed names”.  It is not a binding (aka “transport”) and is clearly distinguished in the draft specification from bindings.  The Naming specification will clearly separate the conceptual definition of a well-formed name (WFN) from the definitions of their bindings to machine-readable representations suitable for exchange among machines.

 

That said, your comment suggests that our decisions about bindings should be partly driven by bandwidth/transmission concerns.  Could you elaborate these concerns?  The CPE 2.2 specification is completely silent on this point.  At the moment, we only envisage supporting two bindings: a v2.2-conformant URI (for backward compatibility) and a “formatted string” binding that looks very similar to a URI but does not have to adhere to all the character-set restrictions imposed on URIs.  I’d like to hear more about community requirements to minimize the size/complexity of name bindings.

 

·         I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them. 

 

Point taken; we are still evaluating the rationale for “other_edition”.  It may well be dropped.

 

·         With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

 

(Assume for now we’ve dropped other_edition.)  We’re not thinking of prohibiting the use of the “legacy” edition attribute—it’s stlll valid and needed for backward compatibility.  What we’re going to prohibit is the simultaneous use of both the “legacy” edition attribute and any of the newly-introduced attributes (i.e., sw_edition, target_sw, target_hw).  So if you use “legacy” edition, you can’t use any of sw_edition, target_sw, or target_hw; and if you use any of sw_edition, target_sw, or target_hw, you can’t use “legacy” edition.  In the 2.2 URI binding, if the “legacy” edition attribute is used, it is mapped into the 2.2 URI’s “edition” component.  If any of the new edition attributes are used, a “packing” operation is used to pack the three attribute values into the 2.2 URI’s “edition” component.  When creating a 2.3 formatted string binding, things work a bit differently, since the 2.3 binding does not have a place for “legacy” edition in addition to sw_edition, target_sw, and target_hw.  In this case, “legacy” edition (if used) is mapped to sw_edition and the other two attributes left blank.  Otherwise we map the specified values of sw_edition, target_sw, and target_hw to their positions in the 2.3 string binding.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.       The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.        I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.       I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.       With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.        I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Wolfkiel, Joseph
In reply to this post by Brant Cheikes

I think this begs the question of what a specification is for.  If the whole point of having the CPE Dictionary specification is solely for NIST to describe how they plan to maintain and publish names they will map to vulnerabilities/checklists/security controls, then  I don’t understand the need for a community vetting process along with expected validation programs.  It seems like NIST can just publish the process they will use to maintain and distribute CPE dictionary names outside of the standards process.  I’m not debating the need for a dictionary at NIST/NVD we can map to, just the requirement to publish a specification governing how a single, government-owned product will manage names.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, May 18, 2010 6:31 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete message copied below.)  Rather than responding to them all in a single message, I’ll respond in separate messages.

 

This message addresses this comment:

Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

 

I’d say that there’s still a critical requirement for an authoritative source of unique product identifiers.  Whether that’s a single source (like NIST/NVD) or some federation of complementary authoritative sources is a separate question.  Heretofore, the dictionary has been the sine qua non of CPE—its indispensible ingredient.  Without a common reference for names, we don’t have an interoperability solution, just a common structure for passing around a specified but loosely defined set of attribute value pairs.  So I don’t see how we can do without a Dictionary specification—by specifying the format for dictionary entries and the rules to be used for assigning proper values to attributes, we effectively define how tool interoperability is achieved.

 

The validation point is an interesting one.  I could well imagine SCAP imposing a CPE conformance test to ensure that credentialed scanners always report products using the names listed in an “official dictionary” whenever a name for the intended product exists.  A weaker test would require that product names simply be “well formed”—this would work for non-credentialed network scanners which in effect generate patterns for matching against dictionary names.  A third validation test could confirm that patterns match the proper dictionary entries.  The details certainly need to be worked out, but the task seems quite doable—and essential if we are to ensure that CPE provides a true tool interoperability solution.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.       The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.        I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.       I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.       With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.        I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

shanford
Lt Col Wolkfiel,

I don't think that there is any dissonance between having an authoritative
dictionary and having a standard for naming and interoperability.

There doesn't seem to be anything in 2.2 or 2.3, outside of having a central
authoritative dictionary, that is capable of resolving conflicting names
from multiple dictionaries, or preventing duplication of real-world content
under various similar-but-different logical representations in multiple
dictionaries.  

It doesn't seem contrary to me at all to have NIST handle being that
authority until the specification can evolve to allow a federated dictionary
model. It also seems that NIST might be free to pass that responsibility on
to another single authority (who would assume the role and continue to use
the same specification to govern the dictionary).

But without a method to negotiate interoperability, it would appear for now
it must be enforced.

- Seth Hanford

On 5/24/10 4:12 PM, "Wolfkiel, Joseph" <[hidden email]> wrote:

> I think this begs the question of what a specification is for.  If the whole
> point of having the CPE Dictionary specification is solely for NIST to
> describe how they plan to maintain and publish names they will map to
> vulnerabilities/checklists/security controls, then  I don¹t understand the
> need for a community vetting process along with expected validation programs.
> It seems like NIST can just publish the process they will use to maintain and
> distribute CPE dictionary names outside of the standards process.  I¹m not
> debating the need for a dictionary at NIST/NVD we can map to, just the
> requirement to publish a specification governing how a single,
> government-owned product will manage names.
>  
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T) Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 6:31 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference
>  
> Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete
> message copied below.)  Rather than responding to them all in a single
> message, I¹ll respond in separate messages.
>  
> This message addresses this comment:
> ³Is there a requirement for a CPE Dictionary specification?  The functionality
> described in the presentation distributed is not a product the DoD would be
> interested in purchasing, nor would we expect to require ³CPE Dictionary²
> validation in any products we would buy.  Does anyone else perceive the
> requirement to specify this information?  If a validation program were set up
> for it, would anyone use it?²
>  
> I¹d say that there¹s still a critical requirement for an authoritative source
> of unique product identifiers.  Whether that¹s a single source (like NIST/NVD)
> or some federation of complementary authoritative sources is a separate
> question.  Heretofore, the dictionary has been the sine qua non of CPE‹its
> indispensible ingredient.  Without a common reference for names, we don¹t have
> an interoperability solution, just a common structure for passing around a
> specified but loosely defined set of attribute value pairs.  So I don¹t see
> how we can do without a Dictionary specification‹by specifying the format for
> dictionary entries and the rules to be used for assigning proper values to
> attributes, we effectively define how tool interoperability is achieved.
>  
> The validation point is an interesting one.  I could well imagine SCAP
> imposing a CPE conformance test to ensure that credentialed scanners always
> report products using the names listed in an ³official dictionary² whenever a
> name for the intended product exists.  A weaker test would require that
> product names simply be ³well formed²‹this would work for non-credentialed
> network scanners which in effect generate patterns for matching against
> dictionary names.  A third validation test could confirm that patterns match
> the proper dictionary entries.  The details certainly need to be worked out,
> but the task seems quite doable‹and essential if we are to ensure that CPE
> provides a true tool interoperability solution.
>  
> /Brant
>  
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>  
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference
>  
> All,
>  
> I won¹t be able to join the conference until about halfway through, so I
> thought I¹d put my concerns out in an e-mail.
>  
> CPE Dictionary Specification:
> 1.       Is there a requirement for a CPE Dictionary specification?  The
> functionality described in the presentation distributed is not a product the
> DoD would be interested in purchasing, nor would we expect to require ³CPE
> Dictionary² validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation program
> were set up for it, would anyone use it?
>
> 2.      The ³$² appears to be an exact form/fit replacement for the ³² with
> respect to existing CPE specification.  I can¹t figure out what value it adds,
> other than embodying the behavior we had previously assigned to ³².  The down
> side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is
> the benefit worth the price? Alternatively, couldn¹t we use the ³*² symbol for
> that functionality? Seems unnecessarily difficult to implement a spec where
> ³², ³*², and ³$² mean the same thing with respect to matching.
>
>  
> CPE Naming Specification:
> 1.       I¹m okay with using the example shown ­ as an example:
>
> [a1=³v1²,a2=³v2²,Š]
> Ex1: [part=³a²,vendor=³adobe²,Š]
> Ex2: [part=³o²,version=³3.*²]
> -         But I want to avoid having the naming specification force us to use
> the tag-value pair transport shown in the example.  This would force a CPE
> name to take up a full line of XML for each part of a CPE name, which is very
> wasteful of bandwidth. Again, please separate transport from content
> management.
>
> 2.      I¹m very much on board with the addition of separate components for
> sw_edition, target_sw, and target_hw, but can¹t figure out how adding
> ³other_edition² will be useful.  Seems like it would only end up being the
> dumping place for names that should have better metadata labels (e.g. build
> number) if we actually want to use them.  Suggest this would be a good place
> to append an anyType or anyAttribute to allow for extensibility if we find
> another name part we want to formally bring into CPE.
>
> 3.      With respect to prohibiting use of the ³old² edition field, I¹d like
> to hear some other thought on that.  Seems like matching with CPE 2.2 names
> would require you to transport both, otherwise (since there were no ordering
> rules in effect in CPE 2.2) there would not be any way to concatenate the new
> attributes together in any known order to consistently recreate the old
> edition information.
>
> 4.      With respect to ³Bindings² this is where I would like to get away from
> specifying transport.   I think there should be a separate specification
> governing transmission schemas/bindings for CPE.  That way we can define more
> efficient/effective ways of transferring CPE information and still claim
> compliance with using CPE ³names.²   If we can define some number of transport
> formats in a separate spec, then tools can claim support for the ³URI² format,
> ³attribute-based format², ³tag value pair format², ³binary format², or ³JSON
> format² and we can add/deprecate transport formats as requirements are better
> defined *** without having to change the naming specification***.
>
>  
> Backward Compatibility:
> 1.       I¹m not really worried about this issue.  I¹m not aware that there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely theoretical.
>
>  
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T) Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference
>  
> CPE Community,
>  
> I¹ve attached three technical works in progress intended to give everyone on
> the list a sense of the direction we¹re heading with CPE v2.3.
>  
> As noted in the roadmap I posted on 22 April, we are planning to break the
> monolithic CPE specification into four components, arranged in a stack.  At
> the bottom of the stack is the Naming Specification.  I¹ve attached a slide
> deck that summarizes our plans for this part of the standard.
>  
> The Matching Specification will be layered on top of Naming.  We are still
> working on the technical plan for Matching.
>  
> The Dictionary and CPE Language Specifications are peers at the top of the
> specification stack. I¹ve attached a slide deck that summarizes plans for the
> Dictionary.
>  
> A third slide deck on backward compatibility is also attached, for reference.
> As we prepared our designs for 2.3 we gave a lot of thought to what
> ³preserving backward compatibility² means for CPE.  The thinking reflected in
> the attached charts ultimately guided our decisions about what we could and
> could not do in a minor release of the CPE specification.  We¹ve tried to
> thoughtfully balance the need to preserve backward compatibility in a minor
> release with the community¹s need to see new features introduced into the
> standard.
>  
> We look forward to feedback on any or all of these materials‹please use the
> cpe-list.  As a reminder, we¹ve scheduled an open web conference for this
> coming Friday for anyone who wants to ask questions or provide comments and
> feedback. Conference information is shown below.
>  
> Conference Information:
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
> Meeting ID: 273273 (³CPECPE²)
> Meeting Password: 76466348 (³SOGOOD4U²)
>  
> TO ATTEND THE AUDIO CONFERENCE:
>  
> Dial 781-271-6338 from the Bedford, MA region.
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>  
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>  
> 1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
> 2. Click on Attend Meeting.
>    - Accept any security warnings you receive and wait for the Meeting Room to
> initialize.
> 3. If MeetingPlace Collaboration Window does not automatically open, press
> connect.
>  
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>  
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser test
> link on the page.
>  
> Cheers,
> /Brant
>  
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Wolfkiel, Joseph
I think we're talking past each other on this.  I completely agree with
everything you stated in your e-mail.  The issue is that NIST is not asking
for community input on what they plan to put in the NVD CPE Dictionary, nor
is anyone else planning to build an equivalent CPE Dictionary.  Given those
two "facts" as I understand them, I think the community's time is better
spent working on specifying the processes CPE users will follow to collect,
transport, deprecate, and share names.  I think that's also where the value
of interoperability specifications and validation programs is demonstrated.

In the DoD, we're trying to figure out, on both authenticated and
unauthenticated tools, how to report discovered software, map to CPE names
and interim CPE-like names, and manage deprecation.  As we think these
processes through, we are seeing the need for a set of standardized
interfaces and business logic emerge.  The interfaces and business logic for
managing normalized software names is where I would like to see CPE focus.

In my mind, the central concept that NIST will have a central repository of
software names in a central dictionary and then somehow new software names
will be submitted in real time, CPE names will be assigned in real time, and
network discovery tools will be updated to output CPE names in real time has
proven to be a failure.  CPE 2.x has been published for several years now
and we (i.e. the Department of Defense) have not been able to realistically
write requirements for CPE compliance into our acquisitions nor build CPE
into our government-built tools.  When we have worked with GOTS and COTS
vendors to use CPE, it has been an excessively slow, expensive, and manual
process that has effectively prevented us from using CPE in a normalized
software name management process.

Some of the problems we have encountered are being "fixed" in the CPE
version 2.3 proposals, but the core content management problems have not
been fixed and will not be fixed by any of the changes being considered.

I'm advocating that we change the emphasis for CPE to focus on an
implementable name management process that admits up front that NIST can't
keep up with all the names of all new software produced and that we need to
be able to discover, report, map/alias, and correlate on names pending
decisions on the "final" CPE names at NIST.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: shanford [mailto:[hidden email]]
Sent: Tuesday, May 25, 2010 8:40 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference

Lt Col Wolkfiel,

I don't think that there is any dissonance between having an authoritative
dictionary and having a standard for naming and interoperability.

There doesn't seem to be anything in 2.2 or 2.3, outside of having a central
authoritative dictionary, that is capable of resolving conflicting names
from multiple dictionaries, or preventing duplication of real-world content
under various similar-but-different logical representations in multiple
dictionaries.  

It doesn't seem contrary to me at all to have NIST handle being that
authority until the specification can evolve to allow a federated dictionary
model. It also seems that NIST might be free to pass that responsibility on
to another single authority (who would assume the role and continue to use
the same specification to govern the dictionary).

But without a method to negotiate interoperability, it would appear for now
it must be enforced.

- Seth Hanford

On 5/24/10 4:12 PM, "Wolfkiel, Joseph" <[hidden email]> wrote:

> I think this begs the question of what a specification is for.  If the
whole
> point of having the CPE Dictionary specification is solely for NIST to
> describe how they plan to maintain and publish names they will map to
> vulnerabilities/checklists/security controls, then  I don¹t understand the
> need for a community vetting process along with expected validation
programs.
> It seems like NIST can just publish the process they will use to maintain
and

> distribute CPE dictionary names outside of the standards process.  I¹m not
> debating the need for a dictionary at NIST/NVD we can map to, just the
> requirement to publish a specification governing how a single,
> government-owned product will manage names.
>  
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T) Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 6:31 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>  
> Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete
> message copied below.)  Rather than responding to them all in a single
> message, I¹ll respond in separate messages.
>  
> This message addresses this comment:
> ³Is there a requirement for a CPE Dictionary specification?  The
functionality
> described in the presentation distributed is not a product the DoD would
be
> interested in purchasing, nor would we expect to require ³CPE Dictionary²
> validation in any products we would buy.  Does anyone else perceive the
> requirement to specify this information?  If a validation program were set
up
> for it, would anyone use it?²
>  
> I¹d say that there¹s still a critical requirement for an authoritative
source
> of unique product identifiers.  Whether that¹s a single source (like
NIST/NVD)
> or some federation of complementary authoritative sources is a separate
> question.  Heretofore, the dictionary has been the sine qua non of CPE‹its
> indispensible ingredient.  Without a common reference for names, we don¹t
have
> an interoperability solution, just a common structure for passing around a
> specified but loosely defined set of attribute value pairs.  So I don¹t
see
> how we can do without a Dictionary specification‹by specifying the format
for
> dictionary entries and the rules to be used for assigning proper values to
> attributes, we effectively define how tool interoperability is achieved.
>  
> The validation point is an interesting one.  I could well imagine SCAP
> imposing a CPE conformance test to ensure that credentialed scanners
always
> report products using the names listed in an ³official dictionary²
whenever a
> name for the intended product exists.  A weaker test would require that
> product names simply be ³well formed²‹this would work for non-credentialed
> network scanners which in effect generate patterns for matching against
> dictionary names.  A third validation test could confirm that patterns
match
> the proper dictionary entries.  The details certainly need to be worked
out,

> but the task seems quite doable‹and essential if we are to ensure that CPE
> provides a true tool interoperability solution.
>  
> /Brant
>  
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>  
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>  
> All,
>  
> I won¹t be able to join the conference until about halfway through, so I
> thought I¹d put my concerns out in an e-mail.
>  
> CPE Dictionary Specification:
> 1.       Is there a requirement for a CPE Dictionary specification?  The
> functionality described in the presentation distributed is not a product
the
> DoD would be interested in purchasing, nor would we expect to require ³CPE
> Dictionary² validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation
program
> were set up for it, would anyone use it?
>
> 2.      The ³$² appears to be an exact form/fit replacement for the ³²
with
> respect to existing CPE specification.  I can¹t figure out what value it
adds,
> other than embodying the behavior we had previously assigned to ³².  The
down
> side is that it breaks backwards compatibility with 2.2 for CPE consumers.
Is
> the benefit worth the price? Alternatively, couldn¹t we use the ³*² symbol
for
> that functionality? Seems unnecessarily difficult to implement a spec
where

> ³², ³*², and ³$² mean the same thing with respect to matching.
>
>  
> CPE Naming Specification:
> 1.       I¹m okay with using the example shown ­ as an example:
>
> [a1=³v1²,a2=³v2²,Š]
> Ex1: [part=³a²,vendor=³adobe²,Š]
> Ex2: [part=³o²,version=³3.*²]
> -         But I want to avoid having the naming specification force us to
use
> the tag-value pair transport shown in the example.  This would force a CPE
> name to take up a full line of XML for each part of a CPE name, which is
very
> wasteful of bandwidth. Again, please separate transport from content
> management.
>
> 2.      I¹m very much on board with the addition of separate components
for
> sw_edition, target_sw, and target_hw, but can¹t figure out how adding
> ³other_edition² will be useful.  Seems like it would only end up being the
> dumping place for names that should have better metadata labels (e.g.
build
> number) if we actually want to use them.  Suggest this would be a good
place
> to append an anyType or anyAttribute to allow for extensibility if we find
> another name part we want to formally bring into CPE.
>
> 3.      With respect to prohibiting use of the ³old² edition field, I¹d
like
> to hear some other thought on that.  Seems like matching with CPE 2.2
names
> would require you to transport both, otherwise (since there were no
ordering
> rules in effect in CPE 2.2) there would not be any way to concatenate the
new
> attributes together in any known order to consistently recreate the old
> edition information.
>
> 4.      With respect to ³Bindings² this is where I would like to get away
from
> specifying transport.   I think there should be a separate specification
> governing transmission schemas/bindings for CPE.  That way we can define
more
> efficient/effective ways of transferring CPE information and still claim
> compliance with using CPE ³names.²   If we can define some number of
transport
> formats in a separate spec, then tools can claim support for the ³URI²
format,
> ³attribute-based format², ³tag value pair format², ³binary format², or
³JSON
> format² and we can add/deprecate transport formats as requirements are
better
> defined *** without having to change the naming specification***.
>
>  
> Backward Compatibility:
> 1.       I¹m not really worried about this issue.  I¹m not aware that
there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely
theoretical.

>
>  
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T) Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference
>  
> CPE Community,
>  
> I¹ve attached three technical works in progress intended to give everyone
on
> the list a sense of the direction we¹re heading with CPE v2.3.
>  
> As noted in the roadmap I posted on 22 April, we are planning to break the
> monolithic CPE specification into four components, arranged in a stack.
At
> the bottom of the stack is the Naming Specification.  I¹ve attached a
slide
> deck that summarizes our plans for this part of the standard.
>  
> The Matching Specification will be layered on top of Naming.  We are still
> working on the technical plan for Matching.
>  
> The Dictionary and CPE Language Specifications are peers at the top of the
> specification stack. I¹ve attached a slide deck that summarizes plans for
the
> Dictionary.
>  
> A third slide deck on backward compatibility is also attached, for
reference.
> As we prepared our designs for 2.3 we gave a lot of thought to what
> ³preserving backward compatibility² means for CPE.  The thinking reflected
in
> the attached charts ultimately guided our decisions about what we could
and
> could not do in a minor release of the CPE specification.  We¹ve tried to
> thoughtfully balance the need to preserve backward compatibility in a
minor
> release with the community¹s need to see new features introduced into the
> standard.
>  
> We look forward to feedback on any or all of these materials‹please use
the
> cpe-list.  As a reminder, we¹ve scheduled an open web conference for this
> coming Friday for anyone who wants to ask questions or provide comments
and

> feedback. Conference information is shown below.
>  
> Conference Information:
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
> Meeting ID: 273273 (³CPECPE²)
> Meeting Password: 76466348 (³SOGOOD4U²)
>  
> TO ATTEND THE AUDIO CONFERENCE:
>  
> Dial 781-271-6338 from the Bedford, MA region.
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>  
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>  
> 1. Go to:
http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
> 2. Click on Attend Meeting.
>    - Accept any security warnings you receive and wait for the Meeting
Room to
> initialize.
> 3. If MeetingPlace Collaboration Window does not automatically open, press
> connect.
>  
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>  
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser
test

> link on the page.
>  
> Cheers,
> /Brant
>  
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>  
>

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Brant Cheikes
I would like to comment on two separate points, one concerning the business
need(s) which we can support in v2.3, and the other concerning why we're
spending time and effort on a dictionary specification.

On the first point, I agree that there is a demonstrated business need for,
as you describe it, "an implementable name management process that admits up
front that NIST can't keep up with all the names of all new software
produced and that we need to be able to discover, report, map/alias, and
correlate on names pending decisions on the 'final' CPE names at NIST.".

Rightly or wrongly, CPE 2.2 (and prior) never envisaged this business need.
The problem you've defined differs in crucial respects from the problem that
CPE was designed to address.  As the CPE 2.2 spec explains, CPE was intended
to support three use cases: (1) creation and use of "common names" (modeled
after CVEs), (2) "matching" to allow comparison of common names, and (3)
"reporting" through the use of common names (and their prefixes).  The 2.2
design assumptions don't account for, e.g., scanners generating ambiguous
"interim CPE-like names", or matching being applied to support the complex,
partly human-in-the-loop process you're calling mapping.

As we've been working through v2.3, we've been trying to "bolt on" various
new features in the hope that we'll be able to address new business needs
(including yours) without breaking all the other business needs that CPE 2.2
was originally designed to solve.  This has turned out to be exceedingly
difficult, I'm not sure yet we'll succeed, and I'm concerned our efforts
might yield an unduly complex specification with bugs and inconsistencies.
The community will soon get a chance to see the results of our efforts and
tell us what they think.

On the second point, regarding why we're crafting a dictionary spec despite
all your very reasonable points: there are at least four reasons.  The first
reason is this: a lot of what we're doing in 2.3 is driven by rather simple
logic about what we must do to preserve backward compatibility.  In brief,
the logic goes like this: if 2.2 specified a "capability", we can't drop it
in 2.3, since that would mean that a previously supported capability is no
longer supported.  That's why we must support 2.2 URIs, 2.2 matching
semantics (at least when comparing URIs), the CPE language, and so forth.
The team's consensus has been that the 2.2 specification defined (to some
loose degree) an official dictionary, provided an XML schema for dictionary
entries, and also to some degree provided guidance for how to choose
"correct" values for name components.  Consequently, we have concluded we
need to provide at least the same level of "capability" in the 2.3
specification suite.  It's that simple.

The second reason is that we've been trying to grapple with the very problem
you've pointed out--the difficulty with maintaining a comprehensive and
up-to-date dictionary of discoverable products.  We felt that we needed an
official document that would explain what NIST would and would not put in a
dictionary, because we assessed that constraining dictionary contents (e.g.,
just to so-called "identifier names") would result in a more manageable and
efficient process.

The third reason relates to the second.  We've heard a clear desire for
support for multiple dictionaries (central/official vs. "private"), and
eventually a federated process for managing dictionary content.  But that
idea raises lots of questions needing answers.  Again, the team felt that we
needed to publish a document that addresses the questions.

Fourth, one of the complaints we hear a lot about the CPE dictionary is that
users want more, not less, guidance re what to do in various content
management cases.  That also argues for creating a tangible "dictionary
specification" document in the 2.3 stack.

The "dictionary specification" may or may not ultimately have the same
character as the more technically detailed Naming and Matching
specifications, which are actually defining data models, formats for machine
exchange, and algorithms.  Regardless of what we call it (specification,
implementation guidance, or something else) it still needs to be written and
released along with the other specification documents otherwise consumers
won't have a complete picture of how all the parts are combined to solve
real problems.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Wednesday, May 26, 2010 1:20 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference

I think we're talking past each other on this.  I completely agree with
everything you stated in your e-mail.  The issue is that NIST is not asking
for community input on what they plan to put in the NVD CPE Dictionary, nor
is anyone else planning to build an equivalent CPE Dictionary.  Given those
two "facts" as I understand them, I think the community's time is better
spent working on specifying the processes CPE users will follow to collect,
transport, deprecate, and share names.  I think that's also where the value
of interoperability specifications and validation programs is demonstrated.

In the DoD, we're trying to figure out, on both authenticated and
unauthenticated tools, how to report discovered software, map to CPE names
and interim CPE-like names, and manage deprecation.  As we think these
processes through, we are seeing the need for a set of standardized
interfaces and business logic emerge.  The interfaces and business logic for
managing normalized software names is where I would like to see CPE focus.

In my mind, the central concept that NIST will have a central repository of
software names in a central dictionary and then somehow new software names
will be submitted in real time, CPE names will be assigned in real time, and
network discovery tools will be updated to output CPE names in real time has
proven to be a failure.  CPE 2.x has been published for several years now
and we (i.e. the Department of Defense) have not been able to realistically
write requirements for CPE compliance into our acquisitions nor build CPE
into our government-built tools.  When we have worked with GOTS and COTS
vendors to use CPE, it has been an excessively slow, expensive, and manual
process that has effectively prevented us from using CPE in a normalized
software name management process.

Some of the problems we have encountered are being "fixed" in the CPE
version 2.3 proposals, but the core content management problems have not
been fixed and will not be fixed by any of the changes being considered.

I'm advocating that we change the emphasis for CPE to focus on an
implementable name management process that admits up front that NIST can't
keep up with all the names of all new software produced and that we need to
be able to discover, report, map/alias, and correlate on names pending
decisions on the "final" CPE names at NIST.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: shanford [mailto:[hidden email]]
Sent: Tuesday, May 25, 2010 8:40 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference

Lt Col Wolkfiel,

I don't think that there is any dissonance between having an authoritative
dictionary and having a standard for naming and interoperability.

There doesn't seem to be anything in 2.2 or 2.3, outside of having a central
authoritative dictionary, that is capable of resolving conflicting names
from multiple dictionaries, or preventing duplication of real-world content
under various similar-but-different logical representations in multiple
dictionaries.  

It doesn't seem contrary to me at all to have NIST handle being that
authority until the specification can evolve to allow a federated dictionary
model. It also seems that NIST might be free to pass that responsibility on
to another single authority (who would assume the role and continue to use
the same specification to govern the dictionary).

But without a method to negotiate interoperability, it would appear for now
it must be enforced.

- Seth Hanford

On 5/24/10 4:12 PM, "Wolfkiel, Joseph" <[hidden email]> wrote:

> I think this begs the question of what a specification is for.  If the
whole
> point of having the CPE Dictionary specification is solely for NIST to
> describe how they plan to maintain and publish names they will map to
> vulnerabilities/checklists/security controls, then  I don¹t understand the
> need for a community vetting process along with expected validation
programs.
> It seems like NIST can just publish the process they will use to maintain
and

> distribute CPE dictionary names outside of the standards process.  I¹m not
> debating the need for a dictionary at NIST/NVD we can map to, just the
> requirement to publish a specification governing how a single,
> government-owned product will manage names.
>  
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T) Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 6:31 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>  
> Lt Col Wolfkiel posted a number of concerns worth discussing.  (Complete
> message copied below.)  Rather than responding to them all in a single
> message, I¹ll respond in separate messages.
>  
> This message addresses this comment:
> ³Is there a requirement for a CPE Dictionary specification?  The
functionality
> described in the presentation distributed is not a product the DoD would
be
> interested in purchasing, nor would we expect to require ³CPE Dictionary²
> validation in any products we would buy.  Does anyone else perceive the
> requirement to specify this information?  If a validation program were set
up
> for it, would anyone use it?²
>  
> I¹d say that there¹s still a critical requirement for an authoritative
source
> of unique product identifiers.  Whether that¹s a single source (like
NIST/NVD)
> or some federation of complementary authoritative sources is a separate
> question.  Heretofore, the dictionary has been the sine qua non of CPE‹its
> indispensible ingredient.  Without a common reference for names, we don¹t
have
> an interoperability solution, just a common structure for passing around a
> specified but loosely defined set of attribute value pairs.  So I don¹t
see
> how we can do without a Dictionary specification‹by specifying the format
for
> dictionary entries and the rules to be used for assigning proper values to
> attributes, we effectively define how tool interoperability is achieved.
>  
> The validation point is an interesting one.  I could well imagine SCAP
> imposing a CPE conformance test to ensure that credentialed scanners
always
> report products using the names listed in an ³official dictionary²
whenever a
> name for the intended product exists.  A weaker test would require that
> product names simply be ³well formed²‹this would work for non-credentialed
> network scanners which in effect generate patterns for matching against
> dictionary names.  A third validation test could confirm that patterns
match
> the proper dictionary entries.  The details certainly need to be worked
out,

> but the task seems quite doable‹and essential if we are to ensure that CPE
> provides a true tool interoperability solution.
>  
> /Brant
>  
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>  
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>  
> All,
>  
> I won¹t be able to join the conference until about halfway through, so I
> thought I¹d put my concerns out in an e-mail.
>  
> CPE Dictionary Specification:
> 1.       Is there a requirement for a CPE Dictionary specification?  The
> functionality described in the presentation distributed is not a product
the
> DoD would be interested in purchasing, nor would we expect to require ³CPE
> Dictionary² validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation
program
> were set up for it, would anyone use it?
>
> 2.      The ³$² appears to be an exact form/fit replacement for the ³²
with
> respect to existing CPE specification.  I can¹t figure out what value it
adds,
> other than embodying the behavior we had previously assigned to ³².  The
down
> side is that it breaks backwards compatibility with 2.2 for CPE consumers.
Is
> the benefit worth the price? Alternatively, couldn¹t we use the ³*² symbol
for
> that functionality? Seems unnecessarily difficult to implement a spec
where

> ³², ³*², and ³$² mean the same thing with respect to matching.
>
>  
> CPE Naming Specification:
> 1.       I¹m okay with using the example shown ­ as an example:
>
> [a1=³v1²,a2=³v2²,Š]
> Ex1: [part=³a²,vendor=³adobe²,Š]
> Ex2: [part=³o²,version=³3.*²]
> -         But I want to avoid having the naming specification force us to
use
> the tag-value pair transport shown in the example.  This would force a CPE
> name to take up a full line of XML for each part of a CPE name, which is
very
> wasteful of bandwidth. Again, please separate transport from content
> management.
>
> 2.      I¹m very much on board with the addition of separate components
for
> sw_edition, target_sw, and target_hw, but can¹t figure out how adding
> ³other_edition² will be useful.  Seems like it would only end up being the
> dumping place for names that should have better metadata labels (e.g.
build
> number) if we actually want to use them.  Suggest this would be a good
place
> to append an anyType or anyAttribute to allow for extensibility if we find
> another name part we want to formally bring into CPE.
>
> 3.      With respect to prohibiting use of the ³old² edition field, I¹d
like
> to hear some other thought on that.  Seems like matching with CPE 2.2
names
> would require you to transport both, otherwise (since there were no
ordering
> rules in effect in CPE 2.2) there would not be any way to concatenate the
new
> attributes together in any known order to consistently recreate the old
> edition information.
>
> 4.      With respect to ³Bindings² this is where I would like to get away
from
> specifying transport.   I think there should be a separate specification
> governing transmission schemas/bindings for CPE.  That way we can define
more
> efficient/effective ways of transferring CPE information and still claim
> compliance with using CPE ³names.²   If we can define some number of
transport
> formats in a separate spec, then tools can claim support for the ³URI²
format,
> ³attribute-based format², ³tag value pair format², ³binary format², or
³JSON
> format² and we can add/deprecate transport formats as requirements are
better
> defined *** without having to change the naming specification***.
>
>  
> Backward Compatibility:
> 1.       I¹m not really worried about this issue.  I¹m not aware that
there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely
theoretical.

>
>  
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T) Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference
>  
> CPE Community,
>  
> I¹ve attached three technical works in progress intended to give everyone
on
> the list a sense of the direction we¹re heading with CPE v2.3.
>  
> As noted in the roadmap I posted on 22 April, we are planning to break the
> monolithic CPE specification into four components, arranged in a stack.
At
> the bottom of the stack is the Naming Specification.  I¹ve attached a
slide
> deck that summarizes our plans for this part of the standard.
>  
> The Matching Specification will be layered on top of Naming.  We are still
> working on the technical plan for Matching.
>  
> The Dictionary and CPE Language Specifications are peers at the top of the
> specification stack. I¹ve attached a slide deck that summarizes plans for
the
> Dictionary.
>  
> A third slide deck on backward compatibility is also attached, for
reference.
> As we prepared our designs for 2.3 we gave a lot of thought to what
> ³preserving backward compatibility² means for CPE.  The thinking reflected
in
> the attached charts ultimately guided our decisions about what we could
and
> could not do in a minor release of the CPE specification.  We¹ve tried to
> thoughtfully balance the need to preserve backward compatibility in a
minor
> release with the community¹s need to see new features introduced into the
> standard.
>  
> We look forward to feedback on any or all of these materials‹please use
the
> cpe-list.  As a reminder, we¹ve scheduled an open web conference for this
> coming Friday for anyone who wants to ask questions or provide comments
and

> feedback. Conference information is shown below.
>  
> Conference Information:
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
> Meeting ID: 273273 (³CPECPE²)
> Meeting Password: 76466348 (³SOGOOD4U²)
>  
> TO ATTEND THE AUDIO CONFERENCE:
>  
> Dial 781-271-6338 from the Bedford, MA region.
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>  
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>  
> 1. Go to:
http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
> 2. Click on Attend Meeting.
>    - Accept any security warnings you receive and wait for the Meeting
Room to
> initialize.
> 3. If MeetingPlace Collaboration Window does not automatically open, press
> connect.
>  
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>  
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser
test

> link on the page.
>  
> Cheers,
> /Brant
>  
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>  
>

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.3 technical drafts; CPE webconference

Brant Cheikes
In reply to this post by Wolfkiel, Joseph

For these and other reasons, the “legacy” edition attribute appears overtly in the 2.3 formatted string binding along with the so-called “extended attributes” (sw_edition, target_sw, target_hw, and other).  When encoding into a 2.2 URI, if any of the extended attributes are used, a “packed” form of the 2.2 edition component is created with *all five attribute values* (value of legacy edition plus the extended attribute values) collected together.  If only the legacy edition attribute is used, no packing occurs and it becomes the value of the edition component in the 2.2 URI.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, May 24, 2010 4:05 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

Response to one issue below:

 

·         With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

 

(Assume for now we’ve dropped other_edition.)  We’re not thinking of prohibiting the use of the “legacy” edition attribute—it’s stlll valid and needed for backward compatibility.  What we’re going to prohibit is the simultaneous use of both the “legacy” edition attribute and any of the newly-introduced attributes (i.e., sw_edition, target_sw, target_hw).  So if you use “legacy” edition, you can’t use any of sw_edition, target_sw, or target_hw; and if you use any of sw_edition, target_sw, or target_hw, you can’t use “legacy” edition.  In the 2.2 URI binding, if the “legacy” edition attribute is used, it is mapped into the 2.2 URI’s “edition” component.  If any of the new edition attributes are used, a “packing” operation is used to pack the three attribute values into the 2.2 URI’s “edition” component.  When creating a 2.3 formatted string binding, things work a bit differently, since the 2.3 binding does not have a place for “legacy” edition in addition to sw_edition, target_sw, and target_hw.  In this case, “legacy” edition (if used) is mapped to sw_edition and the other two attributes left blank.  Otherwise we map the specified values of sw_edition, target_sw, and target_hw to their positions in the 2.3 string binding.

 

** In this case, if you allow the “old” edition field to be used, you can preserve matching with both 2.2 CPE names and 2.3 CPE names.  If you only allow sw_edition, target_sw, and target_hw fields in 2.3, there is no way to know what order to concatenate them together to rebuild the 2.2 “edition” field.  If you allow the old “edition” field while dictating that is ONLY to be used for 2.2 backwards interoperability, then you could, potentially, preserve backwards interoperability with 2.2 while using 2.3. **

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, May 18, 2010 8:06 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

This message contains a few miscellaneous responses to Lt Col Wolfkiel’s comments.

 

·         The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification. […]

 

Point taken; we are still evaluating the issues underlying the proposal for a “$” character to represent “unknown” attribute values.

 

·         But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth. […]

 

The [a1=v1,a2=v2,…] notation is used in the specification when describing so-called “well-formed names”.  It is not a binding (aka “transport”) and is clearly distinguished in the draft specification from bindings.  The Naming specification will clearly separate the conceptual definition of a well-formed name (WFN) from the definitions of their bindings to machine-readable representations suitable for exchange among machines.

 

That said, your comment suggests that our decisions about bindings should be partly driven by bandwidth/transmission concerns.  Could you elaborate these concerns?  The CPE 2.2 specification is completely silent on this point.  At the moment, we only envisage supporting two bindings: a v2.2-conformant URI (for backward compatibility) and a “formatted string” binding that looks very similar to a URI but does not have to adhere to all the character-set restrictions imposed on URIs.  I’d like to hear more about community requirements to minimize the size/complexity of name bindings.

 

·         I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them. 

 

Point taken; we are still evaluating the rationale for “other_edition”.  It may well be dropped.

 

·         With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

 

(Assume for now we’ve dropped other_edition.)  We’re not thinking of prohibiting the use of the “legacy” edition attribute—it’s stlll valid and needed for backward compatibility.  What we’re going to prohibit is the simultaneous use of both the “legacy” edition attribute and any of the newly-introduced attributes (i.e., sw_edition, target_sw, target_hw).  So if you use “legacy” edition, you can’t use any of sw_edition, target_sw, or target_hw; and if you use any of sw_edition, target_sw, or target_hw, you can’t use “legacy” edition.  In the 2.2 URI binding, if the “legacy” edition attribute is used, it is mapped into the 2.2 URI’s “edition” component.  If any of the new edition attributes are used, a “packing” operation is used to pack the three attribute values into the 2.2 URI’s “edition” component.  When creating a 2.3 formatted string binding, things work a bit differently, since the 2.3 binding does not have a place for “legacy” edition in addition to sw_edition, target_sw, and target_hw.  In this case, “legacy” edition (if used) is mapped to sw_edition and the other two attributes left blank.  Otherwise we map the specified values of sw_edition, target_sw, and target_hw to their positions in the 2.3 string binding.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, May 13, 2010 6:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

All,

 

I won’t be able to join the conference until about halfway through, so I thought I’d put my concerns out in an e-mail.

 

CPE Dictionary Specification:

1.        Is there a requirement for a CPE Dictionary specification?  The functionality described in the presentation distributed is not a product the DoD would be interested in purchasing, nor would we expect to require “CPE Dictionary” validation in any products we would buy.  Does anyone else perceive the requirement to specify this information?  If a validation program were set up for it, would anyone use it?

2.       The “$” appears to be an exact form/fit replacement for the “” with respect to existing CPE specification.  I can’t figure out what value it adds, other than embodying the behavior we had previously assigned to “”.  The down side is that it breaks backwards compatibility with 2.2 for CPE consumers.  Is the benefit worth the price?  Alternatively, couldn’t we use the “*” symbol for that functionality?  Seems unnecessarily difficult to implement a spec where “”, “*”, and “$” mean the same thing with respect to matching.

 

CPE Naming Specification:

1.        I’m okay with using the example shown – as an example:

[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]

-          But I want to avoid having the naming specification force us to use the tag-value pair transport shown in the example.  This would force a CPE name to take up a full line of XML for each part of a CPE name, which is very wasteful of bandwidth.  Again, please separate transport from content management.

2.       I’m very much on board with the addition of separate components for sw_edition, target_sw, and target_hw, but can’t figure out how adding “other_edition” will be useful.  Seems like it would only end up being the dumping place for names that should have better metadata labels (e.g. build number) if we actually want to use them.  Suggest this would be a good place to append an anyType or anyAttribute to allow for extensibility if we find another name part we want to formally bring into CPE.

3.       With respect to prohibiting use of the “old” edition field, I’d like to hear some other thought on that.  Seems like matching with CPE 2.2 names would require you to transport both, otherwise (since there were no ordering rules in effect in CPE 2.2) there would not be any way to concatenate the new attributes together in any known order to consistently recreate the old edition information.

4.       With respect to “Bindings” this is where I would like to get away from specifying transport.   I think there should be a separate specification governing transmission schemas/bindings for CPE.  That way we can define more efficient/effective ways of transferring CPE information and still claim compliance with using CPE “names.”   If we can define some number of transport formats in a separate spec, then tools can claim support for the “URI” format, “attribute-based format”, “tag value pair format”, “binary format”, or “JSON format” and we can add/deprecate transport formats as requirements are better defined *** without having to change the naming specification***.

 

Backward Compatibility:

1.        I’m not really worried about this issue.  I’m not aware that there are any known consumers of the current CPE dictionary built into any commercial or government products, so these issues may be largely theoretical.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, May 10, 2010 2:02 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE webconference

 

CPE Community,

 

I’ve attached three technical works in progress intended to give everyone on the list a sense of the direction we’re heading with CPE v2.3.

 

As noted in the roadmap I posted on 22 April, we are planning to break the monolithic CPE specification into four components, arranged in a stack.  At the bottom of the stack is the Naming Specification.  I’ve attached a slide deck that summarizes our plans for this part of the standard.

 

The Matching Specification will be layered on top of Naming.  We are still working on the technical plan for Matching.

 

The Dictionary and CPE Language Specifications are peers at the top of the specification stack.  I’ve attached a slide deck that summarizes plans for the Dictionary.

 

A third slide deck on backward compatibility is also attached, for reference.  As we prepared our designs for 2.3 we gave a lot of thought to what “preserving backward compatibility” means for CPE.  The thinking reflected in the attached charts ultimately guided our decisions about what we could and could not do in a minor release of the CPE specification.  We’ve tried to thoughtfully balance the need to preserve backward compatibility in a minor release with the community’s need to see new features introduced into the standard.

 

We look forward to feedback on any or all of these materials—please use the cpe-list.  As a reminder, we’ve scheduled an open web conference for this coming Friday for anyone who wants to ask questions or provide comments and feedback.  Conference information is shown below.

 

Conference Information:

Date/Time:  May 14, 2010 at 01:00 PM America/New_York

Meeting ID: 273273 (“CPECPE”)

Meeting Password: 76466348 (“SOGOOD4U”)

 

TO ATTEND THE AUDIO CONFERENCE:

 

Dial 781-271-6338 from the Bedford, MA region.

Dial 703-983-6338 from the Washington DC region, Nationally or Internationally.

 

TO ATTEND THE MeetingPlace Collaboration CONFERENCE:

 

1. Go to: http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314

2. Click on Attend Meeting.

   - Accept any security warnings you receive and wait for the Meeting Room to initialize.

3. If MeetingPlace Collaboration Window does not automatically open, press connect.

 

TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE

 

Visit http://audioconference.mitre.org to test your web browser for compatibility with the web conference. Follow this link to the browser test link on the page.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Brant Cheikes
In reply to this post by Wolfkiel, Joseph
Could you clarify what you mean when you say "you're with Vladimir on this
one"?  Vlad proposed, inter alia, that 2.3 require the 2.2 URI binding, in
which case we lose embedded wildcards, have to continue to percent-encode
most non-alphanumerics, etc.  He also proposed populating CPE dictionaries
automatically by exploiting OS-specific package managers.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, May 24, 2010 4:00 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

I'm with Vladimir on this one.

We (the DoD) don't want to ever be in a position where we don't find out
about a new piece of software on our networks because a vendor had to wait
for the CPE dictionary to be updated prior to reporting it.

What I've asked several of our GOTS tool developers to do is to make a best
effort at populating a CPE name based on the assumption that we can then
fix/update the names via a robust deprecation and/or aliasing process.

For example, if a software product registers a vendor, product, and version
name in a Windows registry, I asked our tool developers to just convert the
given components into legal CPE names and put them in the URI format - i.e.
change upper case letters to lower, percent encode special characters, and
replace spaces with underscores.  It then becomes the problem of the central
report receiving tool to map these non-dictionary CPE names to dictionary
compliant names and maintain an alias list.

We are looking at building a CPE deprecation/management system in the future
that can send messages back to the originating sensor instructing it to
either 1) stop using the initial name and deprecate to a CPE dictionary
compliant name, or 2) not to report that name again since it isn't an
installed software product.  These messages could/can also be used to update
CPE lists as the CPE Dictionary deprecates names over time.  In ARF 0.41.2,
I added an attribute titled nameString where text that may indicate an
installed software product, but can't be identified as a CPE component can
be put, then mapped to a CPE name.  However, you could achieve a similar
effect in CPE 2.2 by just dumping all the text into the "product" field and
letting an analyst figure it out.

Something like this methodology would allow assessment tools to report
discovered software pending the process of adding them to the official CPE
dictionary, then having the vendors add the names to a tool-specific lookup
table.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700
-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:25 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Vlad,

So if I understand you correctly, you're advocating for requiring the 2.2
URI as the must-support protocol.  Actually, our current plan in 2.3 is to
require conformant implementations to support BOTH the 2.2 URI (for backward
compatibility) AND the new 2.3 formatted string.  Here's the thing: one of
the features we're trying to introduce in 2.3 is support for single and
multi-character wildcards.  But we can't do that in a 2.2 URI because of the
requirements for percent-encoding.  If 2.3 requires only the URI binding we
basically eliminate a good argument for upgrading.

Re your second point: "we must automate the addition of new entries into the
dictionary".  I'm very sympathetic to this point of view, but thus far I
haven't come across any reliable way to do this such that I could tweak the
spec to accommodate it.

Also, I'm not sure I understand what you're suggesting re use of each
system's installed-package manager.  You might be saying that we should
design system-specific algorithms (as you have done) for pulling data from
the system's package manager and using that to generate CPE names--FOR THE
SOLE PURPOSE OF RAPIDLY POPULATING A DICTIONARY.  As I understand it,
comprehensive inventory scanners need to look at everything on the hard
disk, not just what a package manager says is installed.  So the
RPM-oriented method cannot be a standard for doing inventory, and we cannot
say that a CPE dictionary will only contain entries for products
discoverable using the package manager.

I could go on, but let me leave it at this: (1) I am supportive of trying to
make the generation of CPE names as automatic as possible, (2) I have yet to
hear a proposal for a feasible way to do this that works across all the
platforms we need to deal with, and copes with all the different ways that
products are installed.  Devising such a proposal would be an excellent
objective for a technical working group.  Anyone want to pull one together
and prepare a detailed proposal?  I would be more than willing to advise and
participate.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 10:56 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Brant.

In my first question replace "XML as the default" with "URI as the
default" and in the second replace "transform to XML" with "transform to
URI".


My 2 cents:
Personally, I am all about transforms and I will share this so every
authenticated scanner gathering software inventory can get the same
results on hosts with rpm as the package manager.  Unfortunately, I
don't think the below algorithm translates to Windows, but if there is a
WMI way to do the equivalent, let's at least share that.  For all the
special sauce ways of determining versions (file dates, versions,
hashes, etc, don't share), but for the vanilla case it is probably
published somewhere already so let's at least share that.

1.  Get the list of packages from the package database. (language works
differently on Linux)

rpm -qa --qf
'(%{URL})(%{PACKAGER})(%{NAME})(%{EPOCH})(%{VERSION})(%{RELEASE})(%{ARCH
})\n'

for each line:
  2.  If URL doesn't exist use PACKAGER and if that doesn't exist use
NAME (our special sauce is no secret)
  3.  Escape special characters (point of contention, but necessary when
names contain colons and more)
  4.  cpestring = "cpe:/a:" + name + ":" + product + ":" + version + ":"
+ update + ":" + edition + ":"
  5.  convert to lowercase
  6.  convert abbreviations (this was considered for removal but is
still in the spec as far as I know)

These RPM packages come mostly from the Operating System vendor itself
so names are authoritative enough and they are signed to boot.  A
federated dictionary of OS vendor supplied names would certainly go a
long way to solve the 80/20 of naming.  Change the algorithm if you
want, but keep it algorithmic and we can even automatically generate the
dictionary (if you must have one).  For CPE to succeed, we must automate
the addition of new entries into the dictionary.  Anything less will be
too slow and too expensive.

Can we come up with algorithms for Mac, Debian and every other major OS
Vendor's package managers?


Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


> -----Original Message-----
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Wednesday, May 19, 2010 9:44 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Vlad,
>
> The "must support protocol" in 2.2 is the URI.  In the Core Team we've
discussed making XML the
> required protocol in 2.3, and agreed that there would be benefits to
doing so.  But ultimately we have
> chosen not to do so.  A major consideration is lack of time to develop
and properly vet a new required
> binding that differs so dramatically from current practice.  If we
want to introduce any new features
> into CPE 2.3, we need to get it into final draft form by the beginning
of June--a mere couple of weeks
> away.  Consequently, we feel obliged to err on the side of caution for
2.3, make a few limited
> improvements within the available time window, then immediately start
working more deliberatively and
> openly on a major release which will have a year to mature, and will
be subjected to a much lengthier

> and more public review by the CPE user community.
>
> /Brant
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
> -----Original Message-----
> From: Vladimir Giszpenc [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 9:09 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Could we
>
> 1.  Keep XML as the must support protocol?
> 2.  Create a transform from each other protocol (JSON, binary, etc) to
XML so a CPE consumer could
> transform what they get to XML?
>
>
> Lt Col Wolfkiel posted a number of concerns worth discussing.
(Complete
> message copied below.)  Rather than responding to them all in a single
> message, I'll respond in separate messages.
>
>
>
> This message addresses this comment:
>
> "With respect to "Bindings" this is where I would like to get away
from
> specifying transport.   I think there should be a separate
specification
> governing transmission schemas/bindings for CPE.  That way we can
define
> more efficient/effective ways of transferring CPE information and
still
> claim compliance with using CPE "names."   If we can define some
number of
> transport formats in a separate spec, then tools can claim support for
the
> "URI" format, "attribute-based format", "tag value pair format",
"binary
> format", or "JSON format" and we can add/deprecate transport formats
as
> requirements are better defined *** without having to change the
naming
> specification***."
>
>
>
> Regarding the suggestion of defining bindings in a specification
document
> separate from naming, I'm quite supportive of that, at least in
principle.
> In practice it won't work for v2.3.  We simply don't have enough time
to
> write a slew of separate specs.  For the moment, naming and bindings
are
> going to have to be defined in the same specification.  In the future,
I
> think it would be a good idea to break the bindings out separately.
>
>
>
> I'm not sure I understand the suggestion that we might define "some
number
> of transport formats".  Within the Core Team we discussed the idea of
> allowing more than one binding, but this kept raising an
interoperability
> objection.  Suppose we defined and allowed 15 different formats (above
you
> hinted at least five).  Which one(s) must vendors implement?  Should a
> CPE-conformant vulnerability management tool be required to recognize
and
> accept all 15 different formats?  Our sense within the team was that
the
> vendors want us to specify a single format, rather than deal with an
> open-ended and potentially extensible set.  So for now we've chosen to
stick
> with the (flawed) URI and URI-like bindings (the former purely for
reasons
> of backward compatibility with 2.2).  Before we go introducing the
> possibility of many alternate bindings, I'd like to better understand
how to
> do that without creating an interoperability nightmare.  Do we really
want

> vendors trying to differentiate their products based on which CPE name
> binding(s) they support?
>
>
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
> webconference
>
>
>
> All,
>
>
>
> I won't be able to join the conference until about halfway through, so
I
> thought I'd put my concerns out in an e-mail.
>
>
>
> CPE Dictionary Specification:
>
> 1.        Is there a requirement for a CPE Dictionary specification?
The
> functionality described in the presentation distributed is not a
product the
> DoD would be interested in purchasing, nor would we expect to require
"CPE
> Dictionary" validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation
> program were set up for it, would anyone use it?
>
> 2.       The "$" appears to be an exact form/fit replacement for the
"" with
> respect to existing CPE specification.  I can't figure out what value
it
> adds, other than embodying the behavior we had previously assigned to
"".
> The down side is that it breaks backwards compatibility with 2.2 for
CPE
> consumers.  Is the benefit worth the price?  Alternatively, couldn't
we use
> the "*" symbol for that functionality?  Seems unnecessarily difficult
to
> implement a spec where "", "*", and "$" mean the same thing with
respect to

> matching.
>
>
>
> CPE Naming Specification:
>
> 1.        I'm okay with using the example shown - as an example:
>
> [a1="v1",a2="v2",.]
>
> Ex1: [part="a",vendor="adobe",.]
>
> Ex2: [part="o",version="3.*"]
>
> -          But I want to avoid having the naming specification force
us to
> use the tag-value pair transport shown in the example.  This would
force a
> CPE name to take up a full line of XML for each part of a CPE name,
which is
> very wasteful of bandwidth.  Again, please separate transport from
content
> management.
>
> 2.       I'm very much on board with the addition of separate
components for
> sw_edition, target_sw, and target_hw, but can't figure out how adding
> "other_edition" will be useful.  Seems like it would only end up being
the
> dumping place for names that should have better metadata labels (e.g.
build
> number) if we actually want to use them.  Suggest this would be a good
place
> to append an anyType or anyAttribute to allow for extensibility if we
find
> another name part we want to formally bring into CPE.
>
> 3.       With respect to prohibiting use of the "old" edition field,
I'd
> like to hear some other thought on that.  Seems like matching with CPE
2.2
> names would require you to transport both, otherwise (since there were
no
> ordering rules in effect in CPE 2.2) there would not be any way to
> concatenate the new attributes together in any known order to
consistently
> recreate the old edition information.
>
> 4.       With respect to "Bindings" this is where I would like to get
away
> from specifying transport.   I think there should be a separate
> specification governing transmission schemas/bindings for CPE.  That
way we
> can define more efficient/effective ways of transferring CPE
information and
> still claim compliance with using CPE "names."   If we can define some
> number of transport formats in a separate spec, then tools can claim
support
> for the "URI" format, "attribute-based format", "tag value pair
format",
> "binary format", or "JSON format" and we can add/deprecate transport
formats
> as requirements are better defined *** without having to change the
naming
> specification***.
>
>
>
> Backward Compatibility:
>
> 1.        I'm not really worried about this issue.  I'm not aware that
there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely
> theoretical.
>
>
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
Program

> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>
>
>
> CPE Community,
>
>
>
> I've attached three technical works in progress intended to give
everyone on
> the list a sense of the direction we're heading with CPE v2.3.
>
>
>
> As noted in the roadmap I posted on 22 April, we are planning to break
the
> monolithic CPE specification into four components, arranged in a
stack.  At
> the bottom of the stack is the Naming Specification.  I've attached a
slide
> deck that summarizes our plans for this part of the standard.
>
>
>
> The Matching Specification will be layered on top of Naming.  We are
still
> working on the technical plan for Matching.
>
>
>
> The Dictionary and CPE Language Specifications are peers at the top of
the
> specification stack.  I've attached a slide deck that summarizes plans
for
> the Dictionary.
>
>
>
> A third slide deck on backward compatibility is also attached, for
> reference.  As we prepared our designs for 2.3 we gave a lot of
thought to
> what "preserving backward compatibility" means for CPE.  The thinking
> reflected in the attached charts ultimately guided our decisions about
what
> we could and could not do in a minor release of the CPE specification.
> We've tried to thoughtfully balance the need to preserve backward
> compatibility in a minor release with the community's need to see new
> features introduced into the standard.
>
>
>
> We look forward to feedback on any or all of these materials-please
use the
> cpe-list.  As a reminder, we've scheduled an open web conference for
this
> coming Friday for anyone who wants to ask questions or provide
comments and

> feedback.  Conference information is shown below.
>
>
>
> Conference Information:
>
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
>
> Meeting ID: 273273 ("CPECPE")
>
> Meeting Password: 76466348 ("SOGOOD4U")
>
>
>
> TO ATTEND THE AUDIO CONFERENCE:
>
>
>
> Dial 781-271-6338 from the Bedford, MA region.
>
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>
>
>
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>
>
>
> 1. Go to:
> http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
>
> 2. Click on Attend Meeting.
>
>    - Accept any security warnings you receive and wait for the Meeting
Room
> to initialize.
>
> 3. If MeetingPlace Collaboration Window does not automatically open,
press

> connect.
>
>
>
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>
>
>
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser
test

> link on the page.
>
>
>
> Cheers,
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Wolfkiel, Joseph
Hmmm....  Guess I should have been more clear.  My apologies.

My intent was to affirm Vladimir's statement that we need to be able to
populate CPE names automatically.  

I do know of several use cases (mostly using unauthenticated scanners) that
require embedded wildcards to capture ambiguity in discovered names, so I'm
not in a position to agree on that one.  This is particularly true of values
in the "version" field.

I think we'll need to support percent encoding to allow for automated CPE
population.  This allows for the simplest business logic to go from
discovered names to CPE-compliant names (e.g. the process I described
below).  I've seen at least one example of a version that contained a colon,
so that would require either deleting the colon or percent encoding.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, May 26, 2010 5:31 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Could you clarify what you mean when you say "you're with Vladimir on this
one"?  Vlad proposed, inter alia, that 2.3 require the 2.2 URI binding, in
which case we lose embedded wildcards, have to continue to percent-encode
most non-alphanumerics, etc.  He also proposed populating CPE dictionaries
automatically by exploiting OS-specific package managers.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, May 24, 2010 4:00 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

I'm with Vladimir on this one.

We (the DoD) don't want to ever be in a position where we don't find out
about a new piece of software on our networks because a vendor had to wait
for the CPE dictionary to be updated prior to reporting it.

What I've asked several of our GOTS tool developers to do is to make a best
effort at populating a CPE name based on the assumption that we can then
fix/update the names via a robust deprecation and/or aliasing process.

For example, if a software product registers a vendor, product, and version
name in a Windows registry, I asked our tool developers to just convert the
given components into legal CPE names and put them in the URI format - i.e.
change upper case letters to lower, percent encode special characters, and
replace spaces with underscores.  It then becomes the problem of the central
report receiving tool to map these non-dictionary CPE names to dictionary
compliant names and maintain an alias list.

We are looking at building a CPE deprecation/management system in the future
that can send messages back to the originating sensor instructing it to
either 1) stop using the initial name and deprecate to a CPE dictionary
compliant name, or 2) not to report that name again since it isn't an
installed software product.  These messages could/can also be used to update
CPE lists as the CPE Dictionary deprecates names over time.  In ARF 0.41.2,
I added an attribute titled nameString where text that may indicate an
installed software product, but can't be identified as a CPE component can
be put, then mapped to a CPE name.  However, you could achieve a similar
effect in CPE 2.2 by just dumping all the text into the "product" field and
letting an analyst figure it out.

Something like this methodology would allow assessment tools to report
discovered software pending the process of adding them to the official CPE
dictionary, then having the vendors add the names to a tool-specific lookup
table.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700
-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:25 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Vlad,

So if I understand you correctly, you're advocating for requiring the 2.2
URI as the must-support protocol.  Actually, our current plan in 2.3 is to
require conformant implementations to support BOTH the 2.2 URI (for backward
compatibility) AND the new 2.3 formatted string.  Here's the thing: one of
the features we're trying to introduce in 2.3 is support for single and
multi-character wildcards.  But we can't do that in a 2.2 URI because of the
requirements for percent-encoding.  If 2.3 requires only the URI binding we
basically eliminate a good argument for upgrading.

Re your second point: "we must automate the addition of new entries into the
dictionary".  I'm very sympathetic to this point of view, but thus far I
haven't come across any reliable way to do this such that I could tweak the
spec to accommodate it.

Also, I'm not sure I understand what you're suggesting re use of each
system's installed-package manager.  You might be saying that we should
design system-specific algorithms (as you have done) for pulling data from
the system's package manager and using that to generate CPE names--FOR THE
SOLE PURPOSE OF RAPIDLY POPULATING A DICTIONARY.  As I understand it,
comprehensive inventory scanners need to look at everything on the hard
disk, not just what a package manager says is installed.  So the
RPM-oriented method cannot be a standard for doing inventory, and we cannot
say that a CPE dictionary will only contain entries for products
discoverable using the package manager.

I could go on, but let me leave it at this: (1) I am supportive of trying to
make the generation of CPE names as automatic as possible, (2) I have yet to
hear a proposal for a feasible way to do this that works across all the
platforms we need to deal with, and copes with all the different ways that
products are installed.  Devising such a proposal would be an excellent
objective for a technical working group.  Anyone want to pull one together
and prepare a detailed proposal?  I would be more than willing to advise and
participate.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 10:56 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport

Brant.

In my first question replace "XML as the default" with "URI as the
default" and in the second replace "transform to XML" with "transform to
URI".


My 2 cents:
Personally, I am all about transforms and I will share this so every
authenticated scanner gathering software inventory can get the same
results on hosts with rpm as the package manager.  Unfortunately, I
don't think the below algorithm translates to Windows, but if there is a
WMI way to do the equivalent, let's at least share that.  For all the
special sauce ways of determining versions (file dates, versions,
hashes, etc, don't share), but for the vanilla case it is probably
published somewhere already so let's at least share that.

1.  Get the list of packages from the package database. (language works
differently on Linux)

rpm -qa --qf
'(%{URL})(%{PACKAGER})(%{NAME})(%{EPOCH})(%{VERSION})(%{RELEASE})(%{ARCH
})\n'

for each line:
  2.  If URL doesn't exist use PACKAGER and if that doesn't exist use
NAME (our special sauce is no secret)
  3.  Escape special characters (point of contention, but necessary when
names contain colons and more)
  4.  cpestring = "cpe:/a:" + name + ":" + product + ":" + version + ":"
+ update + ":" + edition + ":"
  5.  convert to lowercase
  6.  convert abbreviations (this was considered for removal but is
still in the spec as far as I know)

These RPM packages come mostly from the Operating System vendor itself
so names are authoritative enough and they are signed to boot.  A
federated dictionary of OS vendor supplied names would certainly go a
long way to solve the 80/20 of naming.  Change the algorithm if you
want, but keep it algorithmic and we can even automatically generate the
dictionary (if you must have one).  For CPE to succeed, we must automate
the addition of new entries into the dictionary.  Anything less will be
too slow and too expensive.

Can we come up with algorithms for Mac, Debian and every other major OS
Vendor's package managers?


Cheers,

Vladimir Giszpenc
Armadillo Technical Lead
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


> -----Original Message-----
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Wednesday, May 19, 2010 9:44 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Vlad,
>
> The "must support protocol" in 2.2 is the URI.  In the Core Team we've
discussed making XML the
> required protocol in 2.3, and agreed that there would be benefits to
doing so.  But ultimately we have
> chosen not to do so.  A major consideration is lack of time to develop
and properly vet a new required
> binding that differs so dramatically from current practice.  If we
want to introduce any new features
> into CPE 2.3, we need to get it into final draft form by the beginning
of June--a mere couple of weeks
> away.  Consequently, we feel obliged to err on the side of caution for
2.3, make a few limited
> improvements within the available time window, then immediately start
working more deliberatively and
> openly on a major release which will have a year to mature, and will
be subjected to a much lengthier

> and more public review by the CPE user community.
>
> /Brant
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
> -----Original Message-----
> From: Vladimir Giszpenc [mailto:[hidden email]]
> Sent: Tuesday, May 18, 2010 9:09 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
>
> Could we
>
> 1.  Keep XML as the must support protocol?
> 2.  Create a transform from each other protocol (JSON, binary, etc) to
XML so a CPE consumer could
> transform what they get to XML?
>
>
> Lt Col Wolfkiel posted a number of concerns worth discussing.
(Complete
> message copied below.)  Rather than responding to them all in a single
> message, I'll respond in separate messages.
>
>
>
> This message addresses this comment:
>
> "With respect to "Bindings" this is where I would like to get away
from
> specifying transport.   I think there should be a separate
specification
> governing transmission schemas/bindings for CPE.  That way we can
define
> more efficient/effective ways of transferring CPE information and
still
> claim compliance with using CPE "names."   If we can define some
number of
> transport formats in a separate spec, then tools can claim support for
the
> "URI" format, "attribute-based format", "tag value pair format",
"binary
> format", or "JSON format" and we can add/deprecate transport formats
as
> requirements are better defined *** without having to change the
naming
> specification***."
>
>
>
> Regarding the suggestion of defining bindings in a specification
document
> separate from naming, I'm quite supportive of that, at least in
principle.
> In practice it won't work for v2.3.  We simply don't have enough time
to
> write a slew of separate specs.  For the moment, naming and bindings
are
> going to have to be defined in the same specification.  In the future,
I
> think it would be a good idea to break the bindings out separately.
>
>
>
> I'm not sure I understand the suggestion that we might define "some
number
> of transport formats".  Within the Core Team we discussed the idea of
> allowing more than one binding, but this kept raising an
interoperability
> objection.  Suppose we defined and allowed 15 different formats (above
you
> hinted at least five).  Which one(s) must vendors implement?  Should a
> CPE-conformant vulnerability management tool be required to recognize
and
> accept all 15 different formats?  Our sense within the team was that
the
> vendors want us to specify a single format, rather than deal with an
> open-ended and potentially extensible set.  So for now we've chosen to
stick
> with the (flawed) URI and URI-like bindings (the former purely for
reasons
> of backward compatibility with 2.2).  Before we go introducing the
> possibility of many alternate bindings, I'd like to better understand
how to
> do that without creating an interoperability nightmare.  Do we really
want

> vendors trying to differentiate their products based on which CPE name
> binding(s) they support?
>
>
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>
>
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Thursday, May 13, 2010 6:30 PM
> To: cpe-discussion-list CPE Community Forum
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
> webconference
>
>
>
> All,
>
>
>
> I won't be able to join the conference until about halfway through, so
I
> thought I'd put my concerns out in an e-mail.
>
>
>
> CPE Dictionary Specification:
>
> 1.        Is there a requirement for a CPE Dictionary specification?
The
> functionality described in the presentation distributed is not a
product the
> DoD would be interested in purchasing, nor would we expect to require
"CPE
> Dictionary" validation in any products we would buy.  Does anyone else
> perceive the requirement to specify this information?  If a validation
> program were set up for it, would anyone use it?
>
> 2.       The "$" appears to be an exact form/fit replacement for the
"" with
> respect to existing CPE specification.  I can't figure out what value
it
> adds, other than embodying the behavior we had previously assigned to
"".
> The down side is that it breaks backwards compatibility with 2.2 for
CPE
> consumers.  Is the benefit worth the price?  Alternatively, couldn't
we use
> the "*" symbol for that functionality?  Seems unnecessarily difficult
to
> implement a spec where "", "*", and "$" mean the same thing with
respect to

> matching.
>
>
>
> CPE Naming Specification:
>
> 1.        I'm okay with using the example shown - as an example:
>
> [a1="v1",a2="v2",.]
>
> Ex1: [part="a",vendor="adobe",.]
>
> Ex2: [part="o",version="3.*"]
>
> -          But I want to avoid having the naming specification force
us to
> use the tag-value pair transport shown in the example.  This would
force a
> CPE name to take up a full line of XML for each part of a CPE name,
which is
> very wasteful of bandwidth.  Again, please separate transport from
content
> management.
>
> 2.       I'm very much on board with the addition of separate
components for
> sw_edition, target_sw, and target_hw, but can't figure out how adding
> "other_edition" will be useful.  Seems like it would only end up being
the
> dumping place for names that should have better metadata labels (e.g.
build
> number) if we actually want to use them.  Suggest this would be a good
place
> to append an anyType or anyAttribute to allow for extensibility if we
find
> another name part we want to formally bring into CPE.
>
> 3.       With respect to prohibiting use of the "old" edition field,
I'd
> like to hear some other thought on that.  Seems like matching with CPE
2.2
> names would require you to transport both, otherwise (since there were
no
> ordering rules in effect in CPE 2.2) there would not be any way to
> concatenate the new attributes together in any known order to
consistently
> recreate the old edition information.
>
> 4.       With respect to "Bindings" this is where I would like to get
away
> from specifying transport.   I think there should be a separate
> specification governing transmission schemas/bindings for CPE.  That
way we
> can define more efficient/effective ways of transferring CPE
information and
> still claim compliance with using CPE "names."   If we can define some
> number of transport formats in a separate spec, then tools can claim
support
> for the "URI" format, "attribute-based format", "tag value pair
format",
> "binary format", or "JSON format" and we can add/deprecate transport
formats
> as requirements are better defined *** without having to change the
naming
> specification***.
>
>
>
> Backward Compatibility:
>
> 1.        I'm not really worried about this issue.  I'm not aware that
there
> are any known consumers of the current CPE dictionary built into any
> commercial or government products, so these issues may be largely
> theoretical.
>
>
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
Program

> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> From: Cheikes, Brant A. [mailto:[hidden email]]
> Sent: Monday, May 10, 2010 2:02 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
webconference
>
>
>
> CPE Community,
>
>
>
> I've attached three technical works in progress intended to give
everyone on
> the list a sense of the direction we're heading with CPE v2.3.
>
>
>
> As noted in the roadmap I posted on 22 April, we are planning to break
the
> monolithic CPE specification into four components, arranged in a
stack.  At
> the bottom of the stack is the Naming Specification.  I've attached a
slide
> deck that summarizes our plans for this part of the standard.
>
>
>
> The Matching Specification will be layered on top of Naming.  We are
still
> working on the technical plan for Matching.
>
>
>
> The Dictionary and CPE Language Specifications are peers at the top of
the
> specification stack.  I've attached a slide deck that summarizes plans
for
> the Dictionary.
>
>
>
> A third slide deck on backward compatibility is also attached, for
> reference.  As we prepared our designs for 2.3 we gave a lot of
thought to
> what "preserving backward compatibility" means for CPE.  The thinking
> reflected in the attached charts ultimately guided our decisions about
what
> we could and could not do in a minor release of the CPE specification.
> We've tried to thoughtfully balance the need to preserve backward
> compatibility in a minor release with the community's need to see new
> features introduced into the standard.
>
>
>
> We look forward to feedback on any or all of these materials-please
use the
> cpe-list.  As a reminder, we've scheduled an open web conference for
this
> coming Friday for anyone who wants to ask questions or provide
comments and

> feedback.  Conference information is shown below.
>
>
>
> Conference Information:
>
> Date/Time:  May 14, 2010 at 01:00 PM America/New_York
>
> Meeting ID: 273273 ("CPECPE")
>
> Meeting Password: 76466348 ("SOGOOD4U")
>
>
>
> TO ATTEND THE AUDIO CONFERENCE:
>
>
>
> Dial 781-271-6338 from the Bedford, MA region.
>
> Dial 703-983-6338 from the Washington DC region, Nationally or
> Internationally.
>
>
>
> TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
>
>
>
> 1. Go to:
> http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
>
> 2. Click on Attend Meeting.
>
>    - Accept any security warnings you receive and wait for the Meeting
Room
> to initialize.
>
> 3. If MeetingPlace Collaboration Window does not automatically open,
press

> connect.
>
>
>
> TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
>
>
>
> Visit http://audioconference.mitre.org to test your web browser for
> compatibility with the web conference. Follow this link to the browser
test

> link on the page.
>
>
>
> Cheers,
>
> /Brant
>
>
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
>

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bindings specifying transport

Robert Hollis
In most CPE discussions I've observed at various developer days, there seems
to have been a consensus that the CPE Name must *not* carry self-defining
information.  I apologize for missing recent logic that counters that point,
however I think that it was a good basic premise.

That said, I'm in complete agreement that there needs to be a well-known way
to determine a CPE name from field data (like vendor, product name,
version).

I think this could be accomplished as follows:

1) Provide a web-service that generates new CPE IDs
2) Use vendor/product/version strings that are returned by local software
tracking repositories (registry keys, RPM, swdepot, pkg, etc.)
3) Publish the CPE Dictionary *with* a built-in look-up table
        -- or --
3) Use the natural hierarchical structure of XML for the dictionary.

Re: the CPE IDs
I like the MAC address approach.  Have a manufacturer segment, product
segment, and version segment.  Perhaps something like this...

        CPE-1093-1010-1003

A couple things to note:
1) fixed length
2) arbitrary, yet sequential segment values


From here if we used a hierarchical look-up table, it could be structured
something like this:
<cpe-lookup>
    <vendor name="vendor-a" id="1001">
        <product name="super product x" id="1001">
            <alias>nickname 1</alias>
            <alias>nickname 2</alias>
            <alias>nickname 3</alias>
            <version name="1.0" id="1001"/>
            <version name="2.1" id="1002"/>
            <version name="3.0" id="1003"/>
        </product>
        <product name="legacy product l" id="1002">
            <alias>nickname 1</alias>
            <alias>nickname 2</alias>
            <version name="5.1" id="1001"/>
            <version name="5.1.5" id="1002"/>
        </product>
        <product name="beta product b" id="1003">
            <version name="1.0" id="1001"/>
            <version name="2.1" id="1002"/>
        </product>
    </vendor>
</cpe-lookup>

NOTE: vendor, product, etc. names are deliberately *not* mixed case.  If
various interrogation techniques return different strings, use the <alias/>
elements to capture alternatives.

With this, it would be simple to look up vendor-a's legacy product 1,
version 5.1.5 to be

        CPE-1001-1002-1002

And if you're working with an alias, or part of an alias for the product,
you can programmatically run regex comparisons on a vendor's product names
and respective aliases to get a list of matching CPE IDs.  Like, "vendor-a's
nickname 2, version 5.1*" would yield

        CPE-1001-1002-1001
        CPE-1001-1002-1002



Re: drop the current flat structure of the dictionary an go hierarchical

As I consider the look-up table above, I start to wonder why we would need a
flat structure at all.  If that look-up table was *the* dictionary, it would
be pretty simple to construct an XPath query from the CPE ID, and straight
forward to find matching IDs from field data.  Furthermore, the
product/version does not need to be exact to have a reasonable chance of
determining the CPE ID (or a set of matching CPE IDs).  The key would be
using names (and aliases) that match the strings our products would receive
on interrogation.


        -rob




.  -----Original Message-----
.  From: Wolfkiel, Joseph [mailto:[hidden email]]
.  Sent: Wednesday, May 26, 2010 4:53 PM
.  To: [hidden email]
.  Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
.  
.  Hmmm....  Guess I should have been more clear.  My apologies.
.  
.  My intent was to affirm Vladimir's statement that we need to be able to
.  populate CPE names automatically.
.  
.  I do know of several use cases (mostly using unauthenticated scanners)
.  that
.  require embedded wildcards to capture ambiguity in discovered names, so
.  I'm
.  not in a position to agree on that one.  This is particularly true of
.  values
.  in the "version" field.
.  
.  I think we'll need to support percent encoding to allow for automated CPE
.  population.  This allows for the simplest business logic to go from
.  discovered names to CPE-compliant names (e.g. the process I described
.  below).  I've seen at least one example of a version that contained a
.  colon,
.  so that would require either deleting the colon or percent encoding.
.  
.  Lt Col Joseph L. Wolfkiel
.  Director, Computer Network Defense Research & Technology (CND R&T)
.  Program
.  Management Office
.  9800 Savage Rd Ste 6767
.  Ft Meade, MD 20755-6767
.  Commercial 410-854-5401 DSN 244-5401
.  Fax 410-854-6700
.  
.  -----Original Message-----
.  From: Cheikes, Brant A. [mailto:[hidden email]]
.  Sent: Wednesday, May 26, 2010 5:31 PM
.  To: [hidden email]
.  Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
.  
.  Could you clarify what you mean when you say "you're with Vladimir on
.  this
.  one"?  Vlad proposed, inter alia, that 2.3 require the 2.2 URI binding,
.  in
.  which case we lose embedded wildcards, have to continue to percent-encode
.  most non-alphanumerics, etc.  He also proposed populating CPE
.  dictionaries
.  automatically by exploiting OS-specific package managers.
.  
.  /Brant
.  
.  Brant A. Cheikes
.  The MITRE Corporation
.  202 Burlington Road, M/S K302
.  Bedford, MA 01730-1420
.  Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
.  
.  
.  -----Original Message-----
.  From: Wolfkiel, Joseph [mailto:[hidden email]]
.  Sent: Monday, May 24, 2010 4:00 PM
.  To: cpe-discussion-list CPE Community Forum
.  Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
.  
.  I'm with Vladimir on this one.
.  
.  We (the DoD) don't want to ever be in a position where we don't find out
.  about a new piece of software on our networks because a vendor had to
.  wait
.  for the CPE dictionary to be updated prior to reporting it.
.  
.  What I've asked several of our GOTS tool developers to do is to make a
.  best
.  effort at populating a CPE name based on the assumption that we can then
.  fix/update the names via a robust deprecation and/or aliasing process.
.  
.  For example, if a software product registers a vendor, product, and
.  version
.  name in a Windows registry, I asked our tool developers to just convert
.  the
.  given components into legal CPE names and put them in the URI format -
.  i.e.
.  change upper case letters to lower, percent encode special characters,
.  and
.  replace spaces with underscores.  It then becomes the problem of the
.  central
.  report receiving tool to map these non-dictionary CPE names to dictionary
.  compliant names and maintain an alias list.
.  
.  We are looking at building a CPE deprecation/management system in the
.  future
.  that can send messages back to the originating sensor instructing it to
.  either 1) stop using the initial name and deprecate to a CPE dictionary
.  compliant name, or 2) not to report that name again since it isn't an
.  installed software product.  These messages could/can also be used to
.  update
.  CPE lists as the CPE Dictionary deprecates names over time.  In ARF
.  0.41.2,
.  I added an attribute titled nameString where text that may indicate an
.  installed software product, but can't be identified as a CPE component
.  can
.  be put, then mapped to a CPE name.  However, you could achieve a similar
.  effect in CPE 2.2 by just dumping all the text into the "product" field
.  and
.  letting an analyst figure it out.
.  
.  Something like this methodology would allow assessment tools to report
.  discovered software pending the process of adding them to the official
.  CPE
.  dictionary, then having the vendors add the names to a tool-specific
.  lookup
.  table.
.  
.  Lt Col Joseph L. Wolfkiel
.  Director, Computer Network Defense Research & Technology (CND R&T)
.  Program
.  Management Office
.  9800 Savage Rd Ste 6767
.  Ft Meade, MD 20755-6767
.  Commercial 410-854-5401 DSN 244-5401
.  Fax 410-854-6700
.  -----Original Message-----
.  From: Cheikes, Brant A. [mailto:[hidden email]]
.  Sent: Thursday, May 20, 2010 9:25 AM
.  To: [hidden email]
.  Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
.  
.  Vlad,
.  
.  So if I understand you correctly, you're advocating for requiring the 2.2
.  URI as the must-support protocol.  Actually, our current plan in 2.3 is
.  to
.  require conformant implementations to support BOTH the 2.2 URI (for
.  backward
.  compatibility) AND the new 2.3 formatted string.  Here's the thing: one
.  of
.  the features we're trying to introduce in 2.3 is support for single and
.  multi-character wildcards.  But we can't do that in a 2.2 URI because of
.  the
.  requirements for percent-encoding.  If 2.3 requires only the URI binding
.  we
.  basically eliminate a good argument for upgrading.
.  
.  Re your second point: "we must automate the addition of new entries into
.  the
.  dictionary".  I'm very sympathetic to this point of view, but thus far I
.  haven't come across any reliable way to do this such that I could tweak
.  the
.  spec to accommodate it.
.  
.  Also, I'm not sure I understand what you're suggesting re use of each
.  system's installed-package manager.  You might be saying that we should
.  design system-specific algorithms (as you have done) for pulling data
.  from
.  the system's package manager and using that to generate CPE names--FOR
.  THE
.  SOLE PURPOSE OF RAPIDLY POPULATING A DICTIONARY.  As I understand it,
.  comprehensive inventory scanners need to look at everything on the hard
.  disk, not just what a package manager says is installed.  So the
.  RPM-oriented method cannot be a standard for doing inventory, and we
.  cannot
.  say that a CPE dictionary will only contain entries for products
.  discoverable using the package manager.
.  
.  I could go on, but let me leave it at this: (1) I am supportive of trying
.  to
.  make the generation of CPE names as automatic as possible, (2) I have yet
.  to
.  hear a proposal for a feasible way to do this that works across all the
.  platforms we need to deal with, and copes with all the different ways
.  that
.  products are installed.  Devising such a proposal would be an excellent
.  objective for a technical working group.  Anyone want to pull one
.  together
.  and prepare a detailed proposal?  I would be more than willing to advise
.  and
.  participate.
.  
.  /Brant
.  
.  Brant A. Cheikes
.  The MITRE Corporation
.  202 Burlington Road, M/S K302
.  Bedford, MA 01730-1420
.  Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
.  
.  
.  -----Original Message-----
.  From: Vladimir Giszpenc [mailto:[hidden email]]
.  Sent: Wednesday, May 19, 2010 10:56 AM
.  To: cpe-discussion-list CPE Community Forum
.  Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
.  
.  Brant.
.  
.  In my first question replace "XML as the default" with "URI as the
.  default" and in the second replace "transform to XML" with "transform to
.  URI".
.  
.  
.  My 2 cents:
.  Personally, I am all about transforms and I will share this so every
.  authenticated scanner gathering software inventory can get the same
.  results on hosts with rpm as the package manager.  Unfortunately, I
.  don't think the below algorithm translates to Windows, but if there is a
.  WMI way to do the equivalent, let's at least share that.  For all the
.  special sauce ways of determining versions (file dates, versions,
.  hashes, etc, don't share), but for the vanilla case it is probably
.  published somewhere already so let's at least share that.
.  
.  1.  Get the list of packages from the package database. (language works
.  differently on Linux)
.  
.  rpm -qa --qf
.  '(%{URL})(%{PACKAGER})(%{NAME})(%{EPOCH})(%{VERSION})(%{RELEASE})(%{ARCH
.  })\n'
.  
.  for each line:
.    2.  If URL doesn't exist use PACKAGER and if that doesn't exist use
.  NAME (our special sauce is no secret)
.    3.  Escape special characters (point of contention, but necessary when
.  names contain colons and more)
.    4.  cpestring = "cpe:/a:" + name + ":" + product + ":" + version + ":"
.  + update + ":" + edition + ":"
.    5.  convert to lowercase
.    6.  convert abbreviations (this was considered for removal but is
.  still in the spec as far as I know)
.  
.  These RPM packages come mostly from the Operating System vendor itself
.  so names are authoritative enough and they are signed to boot.  A
.  federated dictionary of OS vendor supplied names would certainly go a
.  long way to solve the 80/20 of naming.  Change the algorithm if you
.  want, but keep it algorithmic and we can even automatically generate the
.  dictionary (if you must have one).  For CPE to succeed, we must automate
.  the addition of new entries into the dictionary.  Anything less will be
.  too slow and too expensive.
.  
.  Can we come up with algorithms for Mac, Debian and every other major OS
.  Vendor's package managers?
.  
.  
.  Cheers,
.  
.  Vladimir Giszpenc
.  Armadillo Technical Lead
.  DSCI Contractor Supporting
.  US Army CERDEC S&TCD IAD Tactical Network Protection Branch
.  (732) 532-8959
.  
.  
.  > -----Original Message-----
.  > From: Cheikes, Brant A. [mailto:[hidden email]]
.  > Sent: Wednesday, May 19, 2010 9:44 AM
.  > To: [hidden email]
.  > Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
.  >
.  > Vlad,
.  >
.  > The "must support protocol" in 2.2 is the URI.  In the Core Team we've
.  discussed making XML the
.  > required protocol in 2.3, and agreed that there would be benefits to
.  doing so.  But ultimately we have
.  > chosen not to do so.  A major consideration is lack of time to develop
.  and properly vet a new required
.  > binding that differs so dramatically from current practice.  If we
.  want to introduce any new features
.  > into CPE 2.3, we need to get it into final draft form by the beginning
.  of June--a mere couple of weeks
.  > away.  Consequently, we feel obliged to err on the side of caution for
.  2.3, make a few limited
.  > improvements within the available time window, then immediately start
.  working more deliberatively and
.  > openly on a major release which will have a year to mature, and will
.  be subjected to a much lengthier
.  > and more public review by the CPE user community.
.  >
.  > /Brant
.  >
.  > Brant A. Cheikes
.  > The MITRE Corporation
.  > 202 Burlington Road, M/S K302
.  > Bedford, MA 01730-1420
.  > Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
.  >
.  >
.  > -----Original Message-----
.  > From: Vladimir Giszpenc [mailto:[hidden email]]
.  > Sent: Tuesday, May 18, 2010 9:09 PM
.  > To: cpe-discussion-list CPE Community Forum
.  > Subject: Re: [CPE-DISCUSSION-LIST] Bindings specifying transport
.  >
.  > Could we
.  >
.  > 1.  Keep XML as the must support protocol?
.  > 2.  Create a transform from each other protocol (JSON, binary, etc) to
.  XML so a CPE consumer could
.  > transform what they get to XML?
.  >
.  >
.  > Lt Col Wolfkiel posted a number of concerns worth discussing.
.  (Complete
.  > message copied below.)  Rather than responding to them all in a single
.  > message, I'll respond in separate messages.
.  >
.  >
.  >
.  > This message addresses this comment:
.  >
.  > "With respect to "Bindings" this is where I would like to get away
.  from
.  > specifying transport.   I think there should be a separate
.  specification
.  > governing transmission schemas/bindings for CPE.  That way we can
.  define
.  > more efficient/effective ways of transferring CPE information and
.  still
.  > claim compliance with using CPE "names."   If we can define some
.  number of
.  > transport formats in a separate spec, then tools can claim support for
.  the
.  > "URI" format, "attribute-based format", "tag value pair format",
.  "binary
.  > format", or "JSON format" and we can add/deprecate transport formats
.  as
.  > requirements are better defined *** without having to change the
.  naming
.  > specification***."
.  >
.  >
.  >
.  > Regarding the suggestion of defining bindings in a specification
.  document
.  > separate from naming, I'm quite supportive of that, at least in
.  principle.
.  > In practice it won't work for v2.3.  We simply don't have enough time
.  to
.  > write a slew of separate specs.  For the moment, naming and bindings
.  are
.  > going to have to be defined in the same specification.  In the future,
.  I
.  > think it would be a good idea to break the bindings out separately.
.  >
.  >
.  >
.  > I'm not sure I understand the suggestion that we might define "some
.  number
.  > of transport formats".  Within the Core Team we discussed the idea of
.  > allowing more than one binding, but this kept raising an
.  interoperability
.  > objection.  Suppose we defined and allowed 15 different formats (above
.  you
.  > hinted at least five).  Which one(s) must vendors implement?  Should a
.  > CPE-conformant vulnerability management tool be required to recognize
.  and
.  > accept all 15 different formats?  Our sense within the team was that
.  the
.  > vendors want us to specify a single format, rather than deal with an
.  > open-ended and potentially extensible set.  So for now we've chosen to
.  stick
.  > with the (flawed) URI and URI-like bindings (the former purely for
.  reasons
.  > of backward compatibility with 2.2).  Before we go introducing the
.  > possibility of many alternate bindings, I'd like to better understand
.  how to
.  > do that without creating an interoperability nightmare.  Do we really
.  want
.  > vendors trying to differentiate their products based on which CPE name
.  > binding(s) they support?
.  >
.  >
.  >
.  > /Brant
.  >
.  >
.  >
.  > Brant A. Cheikes
.  > The MITRE Corporation
.  > 202 Burlington Road, M/S K302
.  > Bedford, MA 01730-1420
.  > Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
.  >
.  >
.  >
.  > From: Wolfkiel, Joseph [mailto:[hidden email]]
.  > Sent: Thursday, May 13, 2010 6:30 PM
.  > To: cpe-discussion-list CPE Community Forum
.  > Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
.  > webconference
.  >
.  >
.  >
.  > All,
.  >
.  >
.  >
.  > I won't be able to join the conference until about halfway through, so
.  I
.  > thought I'd put my concerns out in an e-mail.
.  >
.  >
.  >
.  > CPE Dictionary Specification:
.  >
.  > 1.        Is there a requirement for a CPE Dictionary specification?
.  The
.  > functionality described in the presentation distributed is not a
.  product the
.  > DoD would be interested in purchasing, nor would we expect to require
.  "CPE
.  > Dictionary" validation in any products we would buy.  Does anyone else
.  > perceive the requirement to specify this information?  If a validation
.  > program were set up for it, would anyone use it?
.  >
.  > 2.       The "$" appears to be an exact form/fit replacement for the
.  "" with
.  > respect to existing CPE specification.  I can't figure out what value
.  it
.  > adds, other than embodying the behavior we had previously assigned to
.  "".
.  > The down side is that it breaks backwards compatibility with 2.2 for
.  CPE
.  > consumers.  Is the benefit worth the price?  Alternatively, couldn't
.  we use
.  > the "*" symbol for that functionality?  Seems unnecessarily difficult
.  to
.  > implement a spec where "", "*", and "$" mean the same thing with
.  respect to
.  > matching.
.  >
.  >
.  >
.  > CPE Naming Specification:
.  >
.  > 1.        I'm okay with using the example shown - as an example:
.  >
.  > [a1="v1",a2="v2",.]
.  >
.  > Ex1: [part="a",vendor="adobe",.]
.  >
.  > Ex2: [part="o",version="3.*"]
.  >
.  > -          But I want to avoid having the naming specification force
.  us to
.  > use the tag-value pair transport shown in the example.  This would
.  force a
.  > CPE name to take up a full line of XML for each part of a CPE name,
.  which is
.  > very wasteful of bandwidth.  Again, please separate transport from
.  content
.  > management.
.  >
.  > 2.       I'm very much on board with the addition of separate
.  components for
.  > sw_edition, target_sw, and target_hw, but can't figure out how adding
.  > "other_edition" will be useful.  Seems like it would only end up being
.  the
.  > dumping place for names that should have better metadata labels (e.g.
.  build
.  > number) if we actually want to use them.  Suggest this would be a good
.  place
.  > to append an anyType or anyAttribute to allow for extensibility if we
.  find
.  > another name part we want to formally bring into CPE.
.  >
.  > 3.       With respect to prohibiting use of the "old" edition field,
.  I'd
.  > like to hear some other thought on that.  Seems like matching with CPE
.  2.2
.  > names would require you to transport both, otherwise (since there were
.  no
.  > ordering rules in effect in CPE 2.2) there would not be any way to
.  > concatenate the new attributes together in any known order to
.  consistently
.  > recreate the old edition information.
.  >
.  > 4.       With respect to "Bindings" this is where I would like to get
.  away
.  > from specifying transport.   I think there should be a separate
.  > specification governing transmission schemas/bindings for CPE.  That
.  way we
.  > can define more efficient/effective ways of transferring CPE
.  information and
.  > still claim compliance with using CPE "names."   If we can define some
.  > number of transport formats in a separate spec, then tools can claim
.  support
.  > for the "URI" format, "attribute-based format", "tag value pair
.  format",
.  > "binary format", or "JSON format" and we can add/deprecate transport
.  formats
.  > as requirements are better defined *** without having to change the
.  naming
.  > specification***.
.  >
.  >
.  >
.  > Backward Compatibility:
.  >
.  > 1.        I'm not really worried about this issue.  I'm not aware that
.  there
.  > are any known consumers of the current CPE dictionary built into any
.  > commercial or government products, so these issues may be largely
.  > theoretical.
.  >
.  >
.  >
.  > Lt Col Joseph L. Wolfkiel
.  > Director, Computer Network Defense Research & Technology (CND R&T)
.  Program
.  > Management Office
.  > 9800 Savage Rd Ste 6767
.  > Ft Meade, MD 20755-6767
.  > Commercial 410-854-5401 DSN 244-5401
.  > Fax 410-854-6700
.  >
.  > From: Cheikes, Brant A. [mailto:[hidden email]]
.  > Sent: Monday, May 10, 2010 2:02 PM
.  > To: [hidden email]
.  > Subject: [CPE-DISCUSSION-LIST] CPE 2.3 technical drafts; CPE
.  webconference
.  >
.  >
.  >
.  > CPE Community,
.  >
.  >
.  >
.  > I've attached three technical works in progress intended to give
.  everyone on
.  > the list a sense of the direction we're heading with CPE v2.3.
.  >
.  >
.  >
.  > As noted in the roadmap I posted on 22 April, we are planning to break
.  the
.  > monolithic CPE specification into four components, arranged in a
.  stack.  At
.  > the bottom of the stack is the Naming Specification.  I've attached a
.  slide
.  > deck that summarizes our plans for this part of the standard.
.  >
.  >
.  >
.  > The Matching Specification will be layered on top of Naming.  We are
.  still
.  > working on the technical plan for Matching.
.  >
.  >
.  >
.  > The Dictionary and CPE Language Specifications are peers at the top of
.  the
.  > specification stack.  I've attached a slide deck that summarizes plans
.  for
.  > the Dictionary.
.  >
.  >
.  >
.  > A third slide deck on backward compatibility is also attached, for
.  > reference.  As we prepared our designs for 2.3 we gave a lot of
.  thought to
.  > what "preserving backward compatibility" means for CPE.  The thinking
.  > reflected in the attached charts ultimately guided our decisions about
.  what
.  > we could and could not do in a minor release of the CPE specification.
.  > We've tried to thoughtfully balance the need to preserve backward
.  > compatibility in a minor release with the community's need to see new
.  > features introduced into the standard.
.  >
.  >
.  >
.  > We look forward to feedback on any or all of these materials-please
.  use the
.  > cpe-list.  As a reminder, we've scheduled an open web conference for
.  this
.  > coming Friday for anyone who wants to ask questions or provide
.  comments and
.  > feedback.  Conference information is shown below.
.  >
.  >
.  >
.  > Conference Information:
.  >
.  > Date/Time:  May 14, 2010 at 01:00 PM America/New_York
.  >
.  > Meeting ID: 273273 ("CPECPE")
.  >
.  > Meeting Password: 76466348 ("SOGOOD4U")
.  >
.  >
.  >
.  > TO ATTEND THE AUDIO CONFERENCE:
.  >
.  >
.  >
.  > Dial 781-271-6338 from the Bedford, MA region.
.  >
.  > Dial 703-983-6338 from the Washington DC region, Nationally or
.  > Internationally.
.  >
.  >
.  >
.  > TO ATTEND THE MeetingPlace Collaboration CONFERENCE:
.  >
.  >
.  >
.  > 1. Go to:
.  > http://audioconference.mitre.org/a/44c175a8ca35dbdbb4038d6641f46314
.  >
.  > 2. Click on Attend Meeting.
.  >
.  >    - Accept any security warnings you receive and wait for the Meeting
.  Room
.  > to initialize.
.  >
.  > 3. If MeetingPlace Collaboration Window does not automatically open,
.  press
.  > connect.
.  >
.  >
.  >
.  > TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
.  >
.  >
.  >
.  > Visit http://audioconference.mitre.org to test your web browser for
.  > compatibility with the web conference. Follow this link to the browser
.  test
.  > link on the page.
.  >
.  >
.  >
.  > Cheers,
.  >
.  > /Brant
.  >
.  >
.  >
.  > Brant A. Cheikes
.  > The MITRE Corporation
.  > 202 Burlington Road, M/S K302
.  > Bedford, MA 01730-1420
.  > Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
.  >
.  >
12