CPE values for generic systems

[Eric Fredericksen]

Some javascript/style in this post has been disabled (why?)

During discovery our network scan engine will identify systems to varying levels of accuracy. If we have credentials then everything is good. However, without credentials the fingerprinting algorithm will gather data and categorize the target. There are four categories that we support for OS/system types that are not present in the existing CPE definitions.

I would like to request addition of cpe identifiers for these system categories so that we don’t need private representations of them. My suggestions are added below but I am open to suggestions from those more familiar with this specification.

• cpe:/o:osunknown - Unable to uniquely identify the operating system
• cpe:/o:osprinter - Generic network-attached printer device
• cpe:/o:osrouter  - Generic network-attached router device, CISCO or other vendor
• cpe:/o:osunix    - Generic network-attached Posix-like device.
  

Best regards,
Eric

Eric Fredericksen, PhD
Solutions Architect
Risk and Compliance Business Unit
McAfee, Inc.

949.297.5600 Main
949.297.5574 Direct
949.466.5196 Mobile
949.297.5575 Fax
[hidden email]
www.mcafee.com

This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you.

[ilo--]

Hi Eric, hi list.

IMHO, osrouter osunix and osprinter are indeed more accurate than  
generic, where 'embedded' or 'unknown' will grant the 'uncategorized'  
status when talking about identification.

I'm not sure at all but cpe is about identifying elements, not just a  
category dissector, where the absence of the cpe identifier clearly  
states the 'not identified' status of the element.

Although, I completely agree having an 'unkown' category ('o' type  
identifies it's an OS so 'uknown' should be enough instead of  
'osunkown') for not cleary identified vendors. I'm not sure about  
having 'types' of unkown operating system vendor names. osrouter and  
osunix will collide most of the times for unidentified unix-based  
routers, and also for Cisco routers there's a cisco vendor name. Also,  
printer, router or.. fax, pbx, and so are types of application for  
that OS, not the OS itself, neither a 'vendor' name. I guess, if  
osrouter and os printer join the cpe definition as vendor names, get  
ready to add other 'types' in a short future (I'm thinking just in a  
few of them: osPBX, osSAN, osworkstation, osserver, osxxxxx...) and  
the more I think about it, the more I guess they are not vendor names,  
but applications of the systems being identified. This is the reason I  
don't agree with the other cpe names.

In any case, I guess it's not a bad idea to have this 'type concept'  
as an extension within the cpe format definition in the next version  
of the standard. Just using 'e' for embedded or 'u' (unknown) instead  
of 'o', and then the figured application of the system?

I hope this 'short' answer helps!

PD: just as a note, which should be the exact cpe mapping for a tpc/ip  
stack controlling an intell network card? the card vendor's name? an  
unkown os? and what if the network card is a cisco? would this turn  
the cpe mapping from 'unknown' to 'osrouter'?



Quoting Eric Fredericksen <[hidden email]>:

>
> During discovery our network scan engine will identify systems to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target. There are four categories that we
> support for OS/system types that are not present in the existing CPE
> definitions.
> I would like to request addition of cpe identifiers for these system
> categories so that we don't need private representations of them. My
> suggestions are added below but I am open to suggestions from those more
> familiar with this specification.
> * cpe:/o:osunknown - Unable to uniquely identify the operating
> system
> * cpe:/o:osprinter - Generic network-attached printer device
> * cpe:/o:osrouter  - Generic network-attached router device, CISCO
> or other vendor
> * cpe:/o:osunix    - Generic network-attached Posix-like device.
>
> Best regards,
> Eric
>
> Eric Fredericksen, PhD
> Solutions Architect
> Risk and Compliance Business Unit
> McAfee, Inc.
>
> 949.297.5600 Main
> 949.297.5574 Direct
> 949.466.5196 Mobile
> 949.297.5575 Fax
> [hidden email]
> www.mcafee.com
>
> This email may contain confidential and privileged information for the
> sole use of the intended recipient. Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies of this message. Thank you.
>
>
>

Best regards, ilo--

--
http://www.reversing.org  -- [hidden email]
--

[Wolfkiel, Joseph]

Some javascript/style in this post has been disabled (why?)

I think these values should get put into the same hopper with support for null values.  Maybe we could support unknowns with [??] values and nulls with [null].  I agree that returning scan results in some sort of CPE format is important to the DoD, and we do want to be able to communicate that we weren't able to determine the value, so I agree the ability to support unknowns seems like a necessary function.

 

I know our internal DoD efforts have been looking at adding role and function values to CPE more as a tag, than as a field.  Our standard list of functions would include printer and router. 

 

As for LIN/UN/POS-IX issues, isn't this the same sort of "family" problem we have at a different level with office encompassing word, excel, & powerpoint.  Maybe we can find a solution that deals with the family issue some other way.  Maybe we could have a [family=] as a legal value in each field.  Looks like this would be somewhat complex, but maybe we need that.

 

examples:

 

cpe:/o:[??]

 

cpe:/:[??]

<role="printer">

 

cpe:/:[??]

<role="router">

 

cpe:/o::[family=IX][??]

 

cpe:/a:ms:[family=office]word

 

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 [phone]

-----Original Message-----
From: Eric Fredericksen [mailto:[hidden email]]
Sent: Thursday, August 14, 2008 6:31 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE values for generic systems

During discovery our network scan engine will identify systems to varying levels of accuracy. If we have credentials then everything is good. However, without credentials the fingerprinting algorithm will gather data and categorize the target. There are four categories that we support for OS/system types that are not present in the existing CPE definitions.

I would like to request addition of cpe identifiers for these system categories so that we don't need private representations of them. My suggestions are added below but I am open to suggestions from those more familiar with this specification.

• cpe:/o:osunknown - Unable to uniquely identify the operating system
• cpe:/o:osprinter - Generic network-attached printer device
• cpe:/o:osrouter  - Generic network-attached router device, CISCO or other vendor
• cpe:/o:osunix    - Generic network-attached Posix-like device.
  

Best regards,
Eric

Eric Fredericksen, PhD
Solutions Architect
Risk and Compliance Business Unit
McAfee, Inc.

949.297.5600 Main
949.297.5574 Direct
949.466.5196 Mobile
949.297.5575 Fax
[hidden email]
www.mcafee.com

This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you.

[Mann, Dave]

Eric Fredericksen wrote:
> During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customrs.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.  

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================

[Sheldon Malm]

I think we may need to be careful about throwing the baby out with the bath water here.  My team works in 3 of the 4 scenarios that you've outlined above and I think the fundamentals of CPE in concept can work.

The basic problem that started this thread was in handling unknowns and I want to make sure that we think through this problem with focus and clarity.

It is important for CPE to accommodate an "unknown" state, but applying sub-categories to unknowns is an instance of scope creep that stalls the progression of this important standard.  This is primarily a problem of detection accuracy and should not muddy the waters of enumeration.  The notion of parents and children in a tree like structure allows us to stop at the level of assured accuracy.  If that stops at "UNIX", then there is room for detection accuracy improvement but should not require new "unknown" classes to the enumeration standard.  Either "unknown" or "UNIX" is sufficient information for scanning vendors to take action to improve accuracy.  Unknown findings are inherently an effect of incomplete or inaccurate information at scan time.  Building classes based on incomplete or inaccurate information is problematic and a slippery slope as indicated in a previous post (ie: PBX, etc).

I am also concerned from this thread that OS values are proposed to distinguish printers from routers (if I'm indeed reading that part of the thread correctly).  This is not what the OS value is for; it is for determination of the operating system.  If a printer or router vendor customizes an OS, it creates a new OS that must be enumerated and likely becomes a child to the parent OS from which it originated.  If Ironport customizes the BSD kernel and essentially creates their own OS, I don't see an issue with their OS being enumerated as a child of BSD (in this case, FreeBSD iirc).


So, two fundamental issues imho:
1. Enumeration should be based solely on complete and accurate information with a single "catch all" for conditions where even a top level parent can't be identified

2. It's essential that the OS value is used to identify Operating Systems; not the hardware or application software that runs on it.

If these guidelines limit certain use cases, then there may be winners and losers, but there is a set of value here that is available to all of us.  I believe it was Kissinger that said (to paraphrase) the key to international diplomacy is not to please everyone but to ensure equally distributed displeasure.  :)
--------------------------
Sheldon Malm
Director
Security Research and Development
nCircle VERT

Sent from my BlackBerry Wireless Handheld


----- Original Message -----
From: Mann, Dave <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Fri Aug 15 06:16:52 2008
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases  WAS: CPE values for generic systems

Eric Fredericksen wrote:
> During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customrs.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.  

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================

[Sheldon Malm]

I should also be clear that my response is to the thread and not to
Dave's last post.  Chalk this up to BlackBerry expediency.  :)

Sorry for any confusion.

Sheldon Malm
Director
Security Research and Development
nCircle Network Security

http://blog.ncircle.com 



-----Original Message-----
From: Sheldon Malm
Sent: Friday, August 15, 2008 9:42 AM
To: '[hidden email]'
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

I think we may need to be careful about throwing the baby out with the
bath water here.  My team works in 3 of the 4 scenarios that you've
outlined above and I think the fundamentals of CPE in concept can work.

The basic problem that started this thread was in handling unknowns and
I want to make sure that we think through this problem with focus and
clarity.

It is important for CPE to accommodate an "unknown" state, but applying
sub-categories to unknowns is an instance of scope creep that stalls the
progression of this important standard.  This is primarily a problem of
detection accuracy and should not muddy the waters of enumeration.  The
notion of parents and children in a tree like structure allows us to
stop at the level of assured accuracy.  If that stops at "UNIX", then
there is room for detection accuracy improvement but should not require
new "unknown" classes to the enumeration standard.  Either "unknown" or
"UNIX" is sufficient information for scanning vendors to take action to
improve accuracy.  Unknown findings are inherently an effect of
incomplete or inaccurate information at scan time.  Building classes
based on incomplete or inaccurate information is problematic and a
slippery slope as indicated in a previous post (ie: PBX, etc).

I am also concerned from this thread that OS values are proposed to
distinguish printers from routers (if I'm indeed reading that part of
the thread correctly).  This is not what the OS value is for; it is for
determination of the operating system.  If a printer or router vendor
customizes an OS, it creates a new OS that must be enumerated and likely
becomes a child to the parent OS from which it originated.  If Ironport
customizes the BSD kernel and essentially creates their own OS, I don't
see an issue with their OS being enumerated as a child of BSD (in this
case, FreeBSD iirc).


So, two fundamental issues imho:
1. Enumeration should be based solely on complete and accurate
information with a single "catch all" for conditions where even a top
level parent can't be identified

2. It's essential that the OS value is used to identify Operating
Systems; not the hardware or application software that runs on it.

If these guidelines limit certain use cases, then there may be winners
and losers, but there is a set of value here that is available to all of
us.  I believe it was Kissinger that said (to paraphrase) the key to
international diplomacy is not to please everyone but to ensure equally
distributed displeasure.  :)
--------------------------
Sheldon Malm
Director
Security Research and Development
nCircle VERT

Sent from my BlackBerry Wireless Handheld


----- Original Message -----
From: Mann, Dave <[hidden email]>
To: [hidden email]
<[hidden email]>
Sent: Fri Aug 15 06:16:52 2008
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases  WAS: CPE
values for generic systems

Eric Fredericksen wrote:
> During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customrs.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.  

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================

[ilo--]

After reading Sheldon and Dave, I guess Joseph viewpoint meets a goal  
if we start considering the 'component' part about identification.

He sampled 'word' as a part of the 'office' family, but I think a more  
interesting approach is to consider office as a product (already it's)  
and word as a product component. Even if word is a product itself, all  
of we will find cpe insufficient in a short future if we try to  
identify the endpoint:  "report building component of the oracle 10g  
application server". For this we will meet the oracle AS, but we will  
not be able to go one step further to specify the exact component  
identified, just because the report generator of the O10gAS is not a  
product itself. So I think including the component part to the cpe  
format would help a lot to improve the granularity of element  
identification. Finally, if component part is not to be included in  
the URI format of the CPE, we can always use the cpe language with an  
AND operator to attach more information to the identificated element.

About the unknown or 'type' of element identified, as I stated before,  
I agree to include the 'unkown' vendor as a generic one, but totaly  
disagree with the others.

Also, I guess from your email you're trying to use the cpe string as  
the default value for system identification in a form of replacement  
for the old identifying system you were using. I think cpe would add  
some information to the currently identified system as a new  
information field. And of course, I think cpe is a format used to  
identify specific products, not to be used as a categorization of  
unidentified elements.

Talking about uses, I've found the same problem when trying to  
represent unkown systems using the cpe format, but I finally decided  
that the absence of cpe already states it's not yet identified,  
providing the rest of fingerprinting information as the un-resolved  
status of identification.

What I totaly disagree is tagging product name, as it makes difficult  
a simple field filter and I think it's a more interesting aproach to  
improve the cpe format supporting the 'component' field (winword would  
be the interesting component of the "Microsoft Office" package).  
Remember that "Winword" is a valid product name in the cpe dictionary  
(even if outside of the office familiy). If tagging is to be free, we  
could be overloaded of personal interesing tags based on different use  
cases, and if tagging is not free, it's interesting enough to be  
considered as part of the cpe format..

cpe is a really simple format, and is in use for small systems as an  
embedded DSL router and for big and complex as application servers  
(including different elements as web server, many different services,  
and so..). It's going to be difficult to find the 'definitive'  
solution to state all of them, but current status works pretty well  
for now.

It's a very interesting discussion, not to be finished yet, I hope!


  Quoting "Wolfkiel, Joseph" <[hidden email]>:

> I think these values should get put into the same hopper with support
> for null values.  Maybe we could support unknowns with [??] values and
> nulls with [null].  I agree that returning scan results in some sort of
> CPE format is important to the DoD, and we do want to be able to
> communicate that we weren't able to determine the value, so I agree the
> ability to support unknowns seems like a necessary function.
>
> I know our internal DoD efforts have been looking at adding role and
> function values to CPE more as a tag, than as a field.  Our standard
> list of functions would include printer and router.
>
> As for LIN/UN/POS-IX issues, isn't this the same sort of "family"
> problem we have at a different level with office encompassing word,
> excel, & powerpoint.  Maybe we can find a solution that deals with the
> family issue some other way.  Maybe we could have a [family=] as a legal
> value in each field.  Looks like this would be somewhat complex, but
> maybe we need that.
>
> examples:
>
> cpe:/o:[??]
>
> cpe:/:[??]
> <role="printer">
>
> cpe:/:[??]
> <role="router">
>
> cpe:/o::[family=IX][??]
>
> cpe:/a:ms:[family=office]word
>
> 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 [phone]
>
> -----Original Message-----
> From: Eric Fredericksen [mailto:[hidden email]]
> Sent: Thursday, August 14, 2008 6:31 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE values for generic systems
>
>
>
>
> During discovery our network scan engine will identify systems to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target. There are four categories that we
> support for OS/system types that are not present in the existing CPE
> definitions.
>
> I would like to request addition of cpe identifiers for these system
> categories so that we don’t need private representations of them. My
> suggestions are added below but I am open to suggestions from those more
> familiar with this specification.
>
> * cpe:/o:osunknown - Unable to uniquely identify the operating
> system
>
> * cpe:/o:osprinter - Generic network-attached printer device
>
> * cpe:/o:osrouter  - Generic network-attached router device, CISCO
> or other vendor
>
> * cpe:/o:osunix    - Generic network-attached Posix-like device.
>
>
> Best regards,
> Eric
>
> Eric Fredericksen, PhD
> Solutions Architect
> Risk and Compliance Business Unit
> McAfee, Inc.
>
> 949.297.5600 Main
> 949.297.5574 Direct
> 949.466.5196 Mobile
> 949.297.5575 Fax
>  <mailto:[hidden email]> [hidden email]
>  <http://www.mcafee.com> www.mcafee.com
>
> This email may contain confidential and privileged information for the
> sole use of the intended recipient. Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies of this message. Thank you.
>
>
>

Best regards, ilo--

--
http://www.reversing.org  -- [hidden email]
--

[ilo--]

Also, I have to say..

  Sorry about my english, I'm spanish and sometimes I write slower  
than I think so in the process of 'runtime' translation I miss things  
sometimes.. To make things easier, my 15 months daughter has an  
incredible skill in her little fingers to bump out the keys of the  
laptop, and an amazing superhero power to be faster than any of us at  
home to avoid her using her habilities, so my writting would be  
confuse for all.

Security getting funny should not be this way, but actually it is :)

Quoting ilo-- <[hidden email]>:

-...

[Ernest Park-2]

In response to Dave's comments, I want to add some thoughts:

 

CPE provides a dictionary, not an encyclopedia.

 

 

Another apt comparison is that CPE is merely the phonebook, not the yellow pages.

 

The point is that we have to build applications that understand these "phone numbers", not change a phone number to include a ZIP code.

 

 

CPE is not a database. We have talked about aliases and type entries. I see in this thread the mention of role. These are all valid, and need to be embedded in applications, not the CPE string.

 

 

As far as an unresolved value return, do we need to add more "parts"?  Currently, if you return cpe:/o, you have an OS that cannot be resolved further than this. It is currently possible to segment general hardware from OS from apps. There are areas where hardware and OS is hard to distinguish. Perhaps we need more part classification for OS, since an OS may exist for most parts anyway.

 

 

On Fri, Aug 15, 2008 at 9:16 AM, Mann, Dave <[hidden email]> wrote:

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

[Waltermire, David]

All,

A fundamental disagreement within the CPE community is the notion of
"platform" and "product".  I would define these terms as follows:

Platform - a collection of software and hardware products that define one or
more systems.

System - A discrete collection of products that together represent a
functional unit of operational capability.  For example: a server,
workstation, network device, etc.

Product - A discrete unit of software or hardware that can be purchased
downloaded, installed, configured and/or licensed.  A product may consist of
multiple components.

Abstract Product - A reference to a group of products

Component - A unit of function which may be one or more shared libraries,
configuration files, executables, scripts, compiled code, etc.

Like Sheldon I am also concerned about throwing the baby out with the bath
water.  One of the primary reasons for an enumeration standard such as CPE
is that information about products needs to be shared between the various
use cases in a use case agnostic way.  For example the result of a network
scan would feed into an asset management tool to populate known assets or
discover unknown assets, and the asset management information would feed
into a vulnerability management tool to discover what vulnerabilities exists
for a given set of assets.  I believe a source of our problem is the level
of abstraction we are choosing to think about CPEs.  An earlier thread on
this list
(http://n2.nabble.com/Abstract-and-Concrete-CPE-Names-in-the-Dictionary-tt88
234.html) also discussed this issue, with no final resolution.  I would
suggest that CPE attempt to define the most granular pieces of information
necessary to identify a product, while specifying a mechanism for
referencing or querying collections of products.  Taking this approach would
allow each of the use cases to interact with CPEs at their preferred level
of abstraction, while encouraging interoperability amongst the various use
cases.

I see the CPE language as the means through which products are joined
together to create platforms.  The CPE language construct is a powerful
mechanism to bridge the gap between product and platform levels of
abstraction.

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

Requires discrete and abstract product references:

Part of climbing up the stack is identifying meta information about products
that are responding to requests.  In unauthenticated scenarios protocols,
behaviors, and banners are examined to determine facts about the system and
its constituent products.  Generally, only partial product information is
able to be discovered.  To support this use case we need to be able to
reference collections of potential products that may be installed on the
system.

Categorization of products is helpful to satisfying this use case.  There is
a need to relate specific products to broad categories.  It is also equally
important to be able to query which discrete products belong to a category.
Categorization is also an open issue.

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

Requires discrete and abstract product references:

In this use case the "units of management" in a more granular sense are
products.  Asset/Configuration/License management requires knowledge of
discrete products installed on an asset and the ability to query these
assets using both discrete and abstract product representations.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared .dlls)

Uses of this view generally interact with "components" or discrete product
references.  Abstract product references may be useful to provide querying
capabilities.  An ability to go from a known "component" to a product is
helpful when dealing with this use case.  This remains an unresolved issue
with CPE that has been discussed many times before.

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customers.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

In addition to an overlap with the end point management view, there is
probably some overlay with the forensic/architecture view.

Uses of this view have references to discrete products with meta-data
associations.  Some development organizations may also choose to interact
with "components" to provide more detailed internal tracking.

It seems to me that it is possible to satisfy all of these use cases, we
just need to spend the time on modifying and clarifying the specification to
support them.  The first change I would suggest would be to switch our
thinking from talking about platforms to talking about products as our basic
building block.

Dave

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 9:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
> During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customrs.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.  

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================

[ilo--]

Totally agree..

Also..  This is a mix between one of my scan scripts output and the  
chapter 6.2 of the cpe espcification 2.0, actually the 'platform' part  
of the cpe language..

I guess network mapping engines could go to this ending results  
without problem..

-------------
<?xml version="1.0" encoding="UTF-8"?>
<cpe:platform-specification xmlns:cpe="http://cpe.mitre.org/language/2.0">

   <cpe:platform id="xxx">
     <cpe:title>Unknown router device</cpe:title>
     <cpe:logical-test operator="OR" negate="FALSE">
       <cpe:fact-ref name="cpe:/o:linux" accuracy="99%"/>
       <cpe:fact-ref name="cpe:/o:unix" accuracy="99%"/>
       <cpe:fact-ref name="cpe:/o:embedded" accuracy="97%"/>
     </cpe:logical-test>
   </cpe:platform>

   <cpe:platform id="yyy">
     <cpe:title>Unknown printer device</cpe:title>
     <cpe:logical-test operator="OR" negate="FALSE">
       <cpe:fact-ref name="cpe:/o" />
     </cpe:logical-test>
   </cpe:platform>

</cpe:platform-specification>
---------

  The first one could have also the nmap accuracy noticed in the xml  
with xml validation, and the second, using the Ernest's solution for  
unidentified operating systems.

.

Quoting David Waltermire <[hidden email]>:

> All,
>
> A fundamental disagreement within the CPE community is the notion of
> "platform" and "product".  I would define these terms as follows:
>
> Platform - a collection of software and hardware products that define one or
> more systems.
>
> System - A discrete collection of products that together represent a
> functional unit of operational capability.  For example: a server,
> workstation, network device, etc.
>
> Product - A discrete unit of software or hardware that can be purchased
> downloaded, installed, configured and/or licensed.  A product may consist of
> multiple components.
>
> Abstract Product - A reference to a group of products
>
> Component - A unit of function which may be one or more shared libraries,
> configuration files, executables, scripts, compiled code, etc.
>
> Like Sheldon I am also concerned about throwing the baby out with the bath
> water.  One of the primary reasons for an enumeration standard such as CPE
> is that information about products needs to be shared between the various
> use cases in a use case agnostic way.  For example the result of a network
> scan would feed into an asset management tool to populate known assets or
> discover unknown assets, and the asset management information would feed
> into a vulnerability management tool to discover what vulnerabilities exists
> for a given set of assets.  I believe a source of our problem is the level
> of abstraction we are choosing to think about CPEs.  An earlier thread on
> this list
> (http://n2.nabble.com/Abstract-and-Concrete-CPE-Names-in-the-Dictionary-tt88
> 234.html) also discussed this issue, with no final resolution.  I would
> suggest that CPE attempt to define the most granular pieces of information
> necessary to identify a product, while specifying a mechanism for
> referencing or querying collections of products.  Taking this approach would
> allow each of the use cases to interact with CPEs at their preferred level
> of abstraction, while encouraging interoperability amongst the various use
> cases.
>
> I see the CPE language as the means through which products are joined
> together to create platforms.  The CPE language construct is a powerful
> mechanism to bridge the gap between product and platform levels of
> abstraction.
>
> + NETWORK CENTRIC - Seen among network scanners.  Evidence
>   for identifications starts with IP and climbs the network
>   stack model to try to discover "platforms".
>
> Requires discrete and abstract product references:
>
> Part of climbing up the stack is identifying meta information about products
> that are responding to requests.  In unauthenticated scenarios protocols,
> behaviors, and banners are examined to determine facts about the system and
> its constituent products.  Generally, only partial product information is
> able to be discovered.  To support this use case we need to be able to
> reference collections of potential products that may be installed on the
> system.
>
> Categorization of products is helpful to satisfying this use case.  There is
> a need to relate specific products to broad categories.  It is also equally
> important to be able to query which discrete products belong to a category.
> Categorization is also an open issue.
>
> + CREDENTIALED END POINT MANAGEMENT - Seen among configuration
>   audit, end point management and asset inventory tools.
>   Sees "platforms" as "units of management".   Typically
>   needs OSes and applications to be seen as peer concepts.
>
> Requires discrete and abstract product references:
>
> In this use case the "units of management" in a more granular sense are
> products.  Asset/Configuration/License management requires knowledge of
> discrete products installed on an asset and the ability to query these
> assets using both discrete and abstract product representations.
>
> + FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
>   and vulnerability analysis.  Typically views platforms
>   and applications as a part of shipping OS.  Needs to identify
>   system sub-components (files, librarys, shared .dlls)
>
> Uses of this view generally interact with "components" or discrete product
> references.  Abstract product references may be useful to provide querying
> capabilities.  An ability to go from a known "component" to a product is
> helpful when dealing with this use case.  This remains an unresolved issue
> with CPE that has been discussed many times before.
>
> + OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
>   and their customers.  Sees "platforms" in terms of development
>   efforts with requirements, schedules, gold dates, licenses
>   and inventory numbers.  Must deal with suite and components
>   issues (e.g. Office vs Word, what is "Tivioli"?).  This view
>   may overlap with the end point management view.
>
> In addition to an overlap with the end point management view, there is
> probably some overlay with the forensic/architecture view.
>
> Uses of this view have references to discrete products with meta-data
> associations.  Some development organizations may also choose to interact
> with "components" to provide more detailed internal tracking.
>
> It seems to me that it is possible to satisfy all of these use cases, we
> just need to spend the time on modifying and clarifying the specification to
> support them.  The first change I would suggest would be to switch our
> thinking from talking about platforms to talking about products as our basic
> building block.
>
> Dave
>
> -----Original Message-----
> From: Mann, Dave [mailto:[hidden email]]
> Sent: Friday, August 15, 2008 9:17 AM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
> values for generic systems
>
> Eric Fredericksen wrote:
>> During discovery our network scan engine will identify systems
> to
>> varying levels of accuracy. If we have credentials then everything is
>> good. However, without credentials the fingerprinting algorithm will
>> gather data and categorize the target.
>
> Wolfkiel, Joseph wrote:
>> I agree that returning scan results in some
>> sort of CPE format is important to the DoD, and we do want to be able
>> to communicate that we weren't able to determine the value, so I
>> agree the ability to support unknowns seems like a necessary
> function.
>
>
>
> Eric, Joe et al,
>
> I think we must open ourselves up to the very real possibility
> that there are sets of technical use cases in which "platform"
> information needs to be managed but that the ways of expressing
> platform information in these cases will be fundementally different
> from each other.  That is, we may need to consider more than one
> way to express platform information.   Or, putting it yet another
> way, we may need to accept that there are going to be sets of
> use cases that CPE will not apply to.
>
> I think that the situation may be analagous to how we think
> about colors.   We all agree that there are colors.   I'm
> wearing a maroon fleece sweater right now, for example.  But
> what are colors?   How would we stuff "color" into our data
> models so that we could effectively share color information?
>
> For example, imagine that you taken by the color of my old
> fleece sweater and decided that you wish to use it as the
> main color in your branding.  You would need to be able to
> specify this exact color to both your printer and
> your web gurus so that your literature and web site would
> both have the same "colors".  And if you wanted to paint your
> barn or car the same color, you would need to specify the
> color to the painter.
>
> What's interesting here is that print, light display and paint
> all use different encodings (called color spaces) to represent
> colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
> starting point.   So here we have the same fleece jacket.
> Agreement by all parties that it has the same color but different
> ways of representing that color.   More deeply, the different
> technical use cases (print, web, paint) demand these different
> representations and worse, sometimes color spaces are non-comparable.
>
>
>
> What I'm suggesting may be farily radical.  As I understood it,
> the original goal of Neil Ziring's (NSA) XCCDF-P was to create
> a scheme that would allows platforms to be identified in a
> universal way and I believe that CPE has been trying to stay
> true to that vision.   However, if I am correct and if the
> concept of "platform" is similar to the concept of "color"
> we may need to admit that CPE will be tremendously useful for
> some technical uses but not for others and, in fact, that
> other use cases might only be satisfied by a different,
> perhaps incomparable "platform spaces".
>
> Several weeks ago we posted an appeal for people to volunteer
> to be interviewed regarding their own technical use cases.
> We have interviewed many of you (huge thanks) and are still
> actively seeking to interview others (please send me e-mail
> if you are interested).   It is still too early for me to
> give definitive results as we are still processing the information
> as a team but given this thread, it might be useful for
> me to share my current working hypothesis.
>
> I think I'm hearing 4 different and largely incomparable
> frames of reference for thinking about "platform":
>
> + NETWORK CENTRIC - Seen among network scanners.  Evidence
>   for identifications starts with IP and climbs the network
>   stack model to try to discover "platforms".
>
> + CREDENTIALED END POINT MANAGEMENT - Seen among configuration
>   audit, end point management and asset inventory tools.
>   Sees "platforms" as "units of management".   Typically
>   needs OSes and applications to be seen as peer concepts.
>
> + FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
>   and vulnerability analysis.  Typically views platforms
>   and applications as a part of shipping OS.  Needs to identify
>   system sub-components (files, librarys, shared dlls)
>
> + OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
>   and their customrs.  Sees "platforms" in terms of development
>   efforts with requirements, schedules, gold dates, licenses
>   and inventory numbers.  Must deal with suite and components
>   issues (e.g. Office vs Word, what is "Tivioli"?).  This view
>   may overlap with the end point management view.
>
> My sense is that CPE will be the most closely aligned with
> the "Credentialed End Point Management" view, as I think that
> is the view that was largely driving the XCCDF issues that
> ultimately gave birth to CPE.
>
> I recognize that the implication of I'm suggesting means
> that there will be winners and losers with respect to
> CPE utility.  But if I'm correct, it will be impossible for
> us to construct a "platform space" that will satisfy all
> technical use cases.  If this is true, the best we will
> be able to do is to a) identify those technical use cases
> that CPE is good for and b) consider the possible need for
> other platform encodings for other technical use cases if
> the demand is big enough.
>
> I'll close with one last observation.   Many, many, many
> objects in our day to day lives have (by necessity) multiple
> identification schemes associated with them.  Our cars have
> both VINs and License Plates.  Books cary ISBNs, Library of
> Congress IDs and UPCs.  My laptop has 4 different serial
> numbers on it and a MITRE inventory number.   We may need
> to accept that "platforms" are going to require multiple
> "platform spaces" in the same way.
>
> Feedback very much wanted on this...
>
> -Dave
> =================================================================
>      e-mail:[hidden email]    |      cell:781.424.6003
> =================================================================
>

Best regards, ilo--

--
http://www.reversing.org  -- [hidden email]
--

[Tim Keanini]

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk



-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
> During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customrs.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.  

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================

[Ernest Park-2]

ilo -

 

This is well done, and your schema means that you build your extended schema to manage and deliver additional metadata. In this case, looks like the CPE does NOT need to change.

 

 

A recommendation for schema implementations like this is that ALL solutions that we build MUST be fully backward compatible to 1.x. On the surface, this means little things like support for the different URI prefix, and no NULL or blank elements in CPE 1 output.

 

Looks like we have a need for architecture -

 

 

proprietary app ->

query interface ->

CPE Name ->

extended metadata repository

<- Business Intelligence and Data mining using CPE Names

CPE 1.x & 2.x name compliant report with additional metadata

 

 

 

So, we need to either store backward compatibility in the schema, or resolve the URI as an output string from querying the schema or database.

 

What this shows is that ilo used the CPE so that we all know what he is talking about, but layered use specific metadata that allows him to extend CPE while not requiring CPE to do everything.

 

 

Remember, if we try to modify CPE to do everything, it may lose the capability to do important things well. CPE should not try to be a Leatherman. If we start to understand how to read a CPE string, and if we understand how to layer our proprietary data onto that string, CPE becomes a valuable and distinct phonebook, not another vague and only average encyclopedia.

 

Let the commercial market drive the delivery of layered metadata and value ontop of CPE, but CPE should stay very distinctly true to its mission.

 

 

Ernest

On Fri, Aug 15, 2008 at 1:06 PM, ilo-- <[hidden email]> wrote:

Totally agree..

Also..  This is a mix between one of my scan scripts output and the chapter 6.2 of the cpe espcification 2.0, actually the 'platform' part of the cpe language..

I guess network mapping engines could go to this ending results without problem..

-------------
<?xml version="1.0" encoding="UTF-8"?>
<cpe:platform-specification xmlns:cpe="http://cpe.mitre.org/language/2.0">

 <cpe:platform id="xxx">
   <cpe:title>Unknown router device</cpe:title>
   <cpe:logical-test operator="OR" negate="FALSE">
     <cpe:fact-ref name="cpe:/o:linux" accuracy="99%"/>
     <cpe:fact-ref name="cpe:/o:unix" accuracy="99%"/>
     <cpe:fact-ref name="cpe:/o:embedded" accuracy="97%"/>
   </cpe:logical-test>
 </cpe:platform>

 <cpe:platform id="yyy">
   <cpe:title>Unknown printer device</cpe:title>
   <cpe:logical-test operator="OR" negate="FALSE">
     <cpe:fact-ref name="cpe:/o" />
   </cpe:logical-test>
 </cpe:platform>

</cpe:platform-specification>
---------

 The first one could have also the nmap accuracy noticed in the xml with xml validation, and the second, using the Ernest's solution for unidentified operating systems.

.

Quoting David Waltermire <[hidden email]>:

All,

A fundamental disagreement within the CPE community is the notion of
"platform" and "product".  I would define these terms as follows:

Platform - a collection of software and hardware products that define one or
more systems.

System - A discrete collection of products that together represent a
functional unit of operational capability.  For example: a server,
workstation, network device, etc.

Product - A discrete unit of software or hardware that can be purchased
downloaded, installed, configured and/or licensed.  A product may consist of
multiple components.

Abstract Product - A reference to a group of products

Component - A unit of function which may be one or more shared libraries,
configuration files, executables, scripts, compiled code, etc.

Like Sheldon I am also concerned about throwing the baby out with the bath
water.  One of the primary reasons for an enumeration standard such as CPE
is that information about products needs to be shared between the various
use cases in a use case agnostic way.  For example the result of a network
scan would feed into an asset management tool to populate known assets or
discover unknown assets, and the asset management information would feed
into a vulnerability management tool to discover what vulnerabilities exists
for a given set of assets.  I believe a source of our problem is the level
of abstraction we are choosing to think about CPEs.  An earlier thread on
this list
(http://n2.nabble.com/Abstract-and-Concrete-CPE-Names-in-the-Dictionary-tt88
234.html) also discussed this issue, with no final resolution.  I would
suggest that CPE attempt to define the most granular pieces of information
necessary to identify a product, while specifying a mechanism for
referencing or querying collections of products.  Taking this approach would
allow each of the use cases to interact with CPEs at their preferred level
of abstraction, while encouraging interoperability amongst the various use
cases.

I see the CPE language as the means through which products are joined
together to create platforms.  The CPE language construct is a powerful
mechanism to bridge the gap between product and platform levels of
abstraction.

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

Requires discrete and abstract product references:

Part of climbing up the stack is identifying meta information about products
that are responding to requests.  In unauthenticated scenarios protocols,
behaviors, and banners are examined to determine facts about the system and
its constituent products.  Generally, only partial product information is
able to be discovered.  To support this use case we need to be able to
reference collections of potential products that may be installed on the
system.

Categorization of products is helpful to satisfying this use case.  There is
a need to relate specific products to broad categories.  It is also equally
important to be able to query which discrete products belong to a category.
Categorization is also an open issue.

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

Requires discrete and abstract product references:

In this use case the "units of management" in a more granular sense are
products.  Asset/Configuration/License management requires knowledge of
discrete products installed on an asset and the ability to query these
assets using both discrete and abstract product representations.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared .dlls)

Uses of this view generally interact with "components" or discrete product
references.  Abstract product references may be useful to provide querying
capabilities.  An ability to go from a known "component" to a product is
helpful when dealing with this use case.  This remains an unresolved issue
with CPE that has been discussed many times before.

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customers.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

In addition to an overlap with the end point management view, there is
probably some overlay with the forensic/architecture view.

Uses of this view have references to discrete products with meta-data
associations.  Some development organizations may also choose to interact
with "components" to provide more detailed internal tracking.

It seems to me that it is possible to satisfy all of these use cases, we
just need to spend the time on modifying and clarifying the specification to
support them.  The first change I would suggest would be to switch our
thinking from talking about platforms to talking about products as our basic
building block.

Dave

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 9:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:

       During discovery our network scan engine will identify systems

to

varying levels of accuracy. If we have credentials then everything is
good. However, without credentials the fingerprinting algorithm will
gather data and categorize the target.

Wolfkiel, Joseph wrote:

I agree that returning scan results in some
sort of CPE format is important to the DoD, and we do want to be able
to communicate that we weren't able to determine the value, so I
agree the ability to support unknowns seems like a necessary

function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

Best regards, ilo--

--
http://www.reversing.org  -- [hidden email]
--

[Ernest Park-2]

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

[Wolfkiel, Joseph]

Some javascript/style in this post has been disabled (why?)

For what it's worth, I'm working in the DoD requirements community and, if I'm successful, you will have at least one potential customer who will say "Provide your platform discovery data in CPE or we'll buy something else."

 

Certainly the OMB memos guiding Federal acquisitions that mandate SCAP compliance will move all the Federal Government toward CPE compliance.

 

I've already started the process of rebuilding at least one of our internally-built tools to speak CPE.

 

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 [phone]

-----Original Message-----
From: Ernest Park [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:45 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

[Kent_Landfield]

Some javascript/style in this post has been disabled (why?)

I think the initial request was a way to report unknown information in CPE format for exchanging information between products.  I don’t think the original requestor said they wanted to use CPE as discovery tool.  I agree with Joe that we need to have a means to do this if CPE is going to be used as a means to convey information about systems between differing security and network products.  This really was a simple request so that proprietary info did not need to be used and agreed on between products.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:13 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

For what it's worth, I'm working in the DoD requirements community and, if I'm successful, you will have at least one potential customer who will say "Provide your platform discovery data in CPE or we'll buy something else."

 

Certainly the OMB memos guiding Federal acquisitions that mandate SCAP compliance will move all the Federal Government toward CPE compliance.

 

I've already started the process of rebuilding at least one of our internally-built tools to speak CPE.

 

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 [phone]

-----Original Message-----
From: Ernest Park [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:45 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

 

[Tim Keanini]

Some javascript/style in this post has been disabled (why?)

Kent, as you point out, the original subject matter was branched as indicated by the subject line but not everyone made the jump.

 

My post was directed at Dave Mann’s comments and I hope nothing in my post suggested that I was calling CPE a discovery tool – I was simply pointing out a relationship that supported Dave’s hunch that  based on CPE’s origin and SCAP market drivers, the CREDENTIALED END POINT MANAGEMENT mindset is dominant. 

 

To sum it up:  CPE’s primary objective is to meet the needs of SCAP and the Federal market it serves.   You can only have one primary objective so if any decision being made on this list compromises the primary objective, it is not valid.  If CPE’s primary objective is to serve many different markets, then we have a much different set of requirements.

 

 

--tk

 

From: Kent Landfield [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

I think the initial request was a way to report unknown information in CPE format for exchanging information between products.  I don’t think the original requestor said they wanted to use CPE as discovery tool.  I agree with Joe that we need to have a means to do this if CPE is going to be used as a means to convey information about systems between differing security and network products.  This really was a simple request so that proprietary info did not need to be used and agreed on between products.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:13 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

For what it's worth, I'm working in the DoD requirements community and, if I'm successful, you will have at least one potential customer who will say "Provide your platform discovery data in CPE or we'll buy something else."

 

Certainly the OMB memos guiding Federal acquisitions that mandate SCAP compliance will move all the Federal Government toward CPE compliance.

 

I've already started the process of rebuilding at least one of our internally-built tools to speak CPE.

 

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 [phone]

-----Original Message-----
From: Ernest Park [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:45 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

 

[Wolfkiel, Joseph]

Some javascript/style in this post has been disabled (why?)

All,

 

Conveniently, if you go to https://www.fbo.gov/index?s=opportunity&mode=form&id=cf101c39618b4dc9c19a735ee6bac6ca&tab=core&_cview=0, the DoD has released an RFI describing the types of capabilities we'll be looking for in a SCAP compliant host-based assessment tool.  We intend to use CPE to report findings for OS and application inventories conducted by SCAP assessment tools we purchase.  I would expect this requirement to show up in network-based scanner acquisition-related documentation in the future too.

 

I'll leave you to draw your own conclusions about whether the described intent is the XCCDF-P use case or a different one.

 

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 [phone]

-----Original Message-----
From: Tim Keanini [mailto:[hidden email]]
Sent: Friday, August 15, 2008 3:26 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

Kent, as you point out, the original subject matter was branched as indicated by the subject line but not everyone made the jump.

 

My post was directed at Dave Mann's comments and I hope nothing in my post suggested that I was calling CPE a discovery tool - I was simply pointing out a relationship that supported Dave's hunch that  based on CPE's origin and SCAP market drivers, the CREDENTIALED END POINT MANAGEMENT mindset is dominant. 

 

To sum it up:  CPE's primary objective is to meet the needs of SCAP and the Federal market it serves.   You can only have one primary objective so if any decision being made on this list compromises the primary objective, it is not valid.  If CPE's primary objective is to serve many different markets, then we have a much different set of requirements.

 

 

--tk

 

From: Kent Landfield [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

I think the initial request was a way to report unknown information in CPE format for exchanging information between products.  I don't think the original requestor said they wanted to use CPE as discovery tool.  I agree with Joe that we need to have a means to do this if CPE is going to be used as a means to convey information about systems between differing security and network products.  This really was a simple request so that proprietary info did not need to be used and agreed on between products.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:13 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

For what it's worth, I'm working in the DoD requirements community and, if I'm successful, you will have at least one potential customer who will say "Provide your platform discovery data in CPE or we'll buy something else."

 

Certainly the OMB memos guiding Federal acquisitions that mandate SCAP compliance will move all the Federal Government toward CPE compliance.

 

I've already started the process of rebuilding at least one of our internally-built tools to speak CPE.

 

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 [phone]

-----Original Message-----
From: Ernest Park [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:45 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

 

[Tim Keanini]

Some javascript/style in this post has been disabled (why?)

Excellent.   This looks to be right out of the oven.

Thanks,

--tk

 

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, August 15, 2008 3:21 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD Releases RFI for Host-Based SCAP Assessment Tool

 

All,

 

Conveniently, if you go to https://www.fbo.gov/index?s=opportunity&mode=form&id=cf101c39618b4dc9c19a735ee6bac6ca&tab=core&_cview=0, the DoD has released an RFI describing the types of capabilities we'll be looking for in a SCAP compliant host-based assessment tool.  We intend to use CPE to report findings for OS and application inventories conducted by SCAP assessment tools we purchase.  I would expect this requirement to show up in network-based scanner acquisition-related documentation in the future too.

 

I'll leave you to draw your own conclusions about whether the described intent is the XCCDF-P use case or a different one.

 

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 [phone]

-----Original Message-----
From: Tim Keanini [mailto:[hidden email]]
Sent: Friday, August 15, 2008 3:26 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

Kent, as you point out, the original subject matter was branched as indicated by the subject line but not everyone made the jump.

 

My post was directed at Dave Mann's comments and I hope nothing in my post suggested that I was calling CPE a discovery tool - I was simply pointing out a relationship that supported Dave's hunch that  based on CPE's origin and SCAP market drivers, the CREDENTIALED END POINT MANAGEMENT mindset is dominant. 

 

To sum it up:  CPE's primary objective is to meet the needs of SCAP and the Federal market it serves.   You can only have one primary objective so if any decision being made on this list compromises the primary objective, it is not valid.  If CPE's primary objective is to serve many different markets, then we have a much different set of requirements.

 

 

--tk

 

From: Kent Landfield [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

I think the initial request was a way to report unknown information in CPE format for exchanging information between products.  I don't think the original requestor said they wanted to use CPE as discovery tool.  I agree with Joe that we need to have a means to do this if CPE is going to be used as a means to convey information about systems between differing security and network products.  This really was a simple request so that proprietary info did not need to be used and agreed on between products.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:13 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

For what it's worth, I'm working in the DoD requirements community and, if I'm successful, you will have at least one potential customer who will say "Provide your platform discovery data in CPE or we'll buy something else."

 

Certainly the OMB memos guiding Federal acquisitions that mandate SCAP compliance will move all the Federal Government toward CPE compliance.

 

I've already started the process of rebuilding at least one of our internally-built tools to speak CPE.

 

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 [phone]

-----Original Message-----
From: Ernest Park [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:45 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

 

[Kent_Landfield]

Some javascript/style in this post has been disabled (why?)

:-) I guess I was one of them…

 

I really look at the component standards in different ways that might be useful to consider… I don’t want component standards to serve one master…

 

CPE is a standalone standard for exchanging structured naming information. This information can be used between products as in passing system information to another application. This assures the applications can “speak the same language” and know what the type of system the target was to the level of specificity passed.  CPE can be used in databases to relate “Affected Platforms” and system information in a consistent way.  CPEs can also be used to stitch the other five component standards that make up SCAP together.  This allows XCCDF and maybe one day OVAL to target checking to the indicated platforms.

 

CPE came about because of a problem that occurred during the initial OVAL certification testing when two seemingly OVAL compatible products could not exchange system information. One called it Win2k and the other called it Windows 2000 Professional. When the system ID tables were updated to reflect the same system representation, everything worked as expected…  The need to properly exchange a standard representation of a system name (as we know it for this thread) was born, grew into XCCDF-P and morphed into CPE. This was not SCAP centered; this is structured system naming centered. How it is applied is dependent on the usage. CPE should not be developed solely for a single use case.  We could have done that with CVE nine years ago but we did not. We wanted it to be generic, simple and not targeted at a specific usage.  I’d call CVE a success today considering its wide ranging usage.  A usage I might make clear is far beyond what it was initially considered and targeted for.  If we had not taken the simple approach, it would not have found its way into as many security products, databases, and alert communications and inter-applications uses as it has.  We need CPE to be robust but at the same time not target it towards a single use case.  

 

What started this conversation was a request to add a few entries to the CPE dictionary that would allow applications to exchange a state of “unknown” to another application or consumer in CPE format.  CPE needs that ability in the dictionary as a natural extension for inter-application / product communications of structured naming information. This is not inconsistent with CPE and its usage.

 

Keeping it simple has succeeded in the past. Let’s not complicate it.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Tim Keanini [mailto:[hidden email]]
Sent: Friday, August 15, 2008 2:26 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

Kent, as you point out, the original subject matter was branched as indicated by the subject line but not everyone made the jump.

 

My post was directed at Dave Mann’s comments and I hope nothing in my post suggested that I was calling CPE a discovery tool – I was simply pointing out a relationship that supported Dave’s hunch that  based on CPE’s origin and SCAP market drivers, the CREDENTIALED END POINT MANAGEMENT mindset is dominant. 

 

To sum it up:  CPE’s primary objective is to meet the needs of SCAP and the Federal market it serves.   You can only have one primary objective so if any decision being made on this list compromises the primary objective, it is not valid.  If CPE’s primary objective is to serve many different markets, then we have a much different set of requirements.

 

 

--tk

 

From: Kent Landfield [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

I think the initial request was a way to report unknown information in CPE format for exchanging information between products.  I don’t think the original requestor said they wanted to use CPE as discovery tool.  I agree with Joe that we need to have a means to do this if CPE is going to be used as a means to convey information about systems between differing security and network products.  This really was a simple request so that proprietary info did not need to be used and agreed on between products.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:13 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

For what it's worth, I'm working in the DoD requirements community and, if I'm successful, you will have at least one potential customer who will say "Provide your platform discovery data in CPE or we'll buy something else."

 

Certainly the OMB memos guiding Federal acquisitions that mandate SCAP compliance will move all the Federal Government toward CPE compliance.

 

I've already started the process of rebuilding at least one of our internally-built tools to speak CPE.

 

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 [phone]

-----Original Message-----
From: Ernest Park [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:45 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================