Making Security Measurable › CPE - Common Platform Enumeration

Functional Goals and Design Principles of CPE

20 messages

Tim Keanini Sr.

Functional Goals and Design Principles of CPE

Reply Threaded

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

Greetings,

I’ve read through the mailing-list archives and the latest CPE specification document and feel that I am up to speed with the group’s discussion. Language theory, Set theory, classification, vulnerabilities, and checklists, this is my kind of party! J In my tardiness to join the discussion, I was able to read everything discussed in one sitting and share my observation with you now.

While I do have some specific questions for discussion, I am trying to make sure I understand the game itself: what are the goals and objectives of CPE? In other words, what problem do we consider solved either in whole or in part when the design is said to be ready? Given the history of CPE (XCCDF-P), the specification document does much more to describe the current design than it does the functional objectives and design principles.

If the goal of CPE is to provide a common naming scheme, like CVE, then why does it specify a method for constructing combinations of elements, rather than focusing on the specification of elements themselves? [I'll address this in more detail in a subsequent email subject: Faceted Vocabulary]

In my humble opinion, without an explicit shared understanding of the success criteria of CPE, all we can do is continue to throw things at the current design and see where it breaks. If this is the way it should go, I have a large list and we can take things case by case.

I’m happy to work on the success criteria. Alternatively, if this is just considered noise set me straight so that I may add some value to the discussion.

--tk

Timothy 'TK' Keanini. CTO

101 Second Street, Suite 400

San Francisco, CA 94105

Office: +1 415 625 5939

Mobile: +1 415 328 2722

Fax: +1 415 625 5984

http://www.ncircle.com/

Check out our Blog: http://blog.ncircle.com/patterns

Andrew Buttner

Re: Functional Goals and Design Principles of CPE

Reply Threaded

>While I do have some specific questions for discussion, I am
>trying to make sure I understand the game itself: what are the
>goals and objectives of CPE? In other words, what problem do
>we consider solved either in whole or in part when the design
>is said to be ready? Given the history of CPE (XCCDF-P), the
>specification document does much more to describe the current
>design than it does the functional objectives and design principles.

I have tried to spell out my thoughts on this below. I am interested
in what others think.

objective
-----------
The primary objective of CPE is to provide a unique name for a given
platform. The need for this is well documented within the community
and such a name will help vendors and tools share necessary
information.

In addition to providing a unique name, CPE is attempting to support
the application of matching. When a checking or analysis tool tests a
real IT target system, it must be able to decide whether any given CPE
Name corresponds to that system, and vice-versa. This is called
matching.

The challenge for both of these objectives as opposed to other
enumerations present within the community is that the number of
platforms is infinite. Since a platform is a combination of hardware,
os, and applications, there are any number of combinations out there.
It is impossible to enumerate every one. Therefore, the structure of a
CPE name must be such that new names can be created without the CPE
moderator in the loop. This calls for a defined structure that can be
understood an used to create new names.

Since new names can be created by the user, matching algorithms must be
able to under some amount of meaning from the name in order to perform
its task.

Tim Erlin-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

Buttner, Drew wrote:

> objective
> -----------
> The primary objective of CPE is to provide a unique name for a given
> platform. The need for this is well documented within the community
> and such a name will help vendors and tools share necessary
> information.
>
> In addition to providing a unique name, CPE is attempting to support
> the application of matching. When a checking or analysis tool tests a
> real IT target system, it must be able to decide whether any given CPE
> Name corresponds to that system, and vice-versa. This is called
> matching.

Perhaps this is where some of the confusion lies. These two objectives
are both ostensibly addressed by something called CPE, but they really
require two distinct information structures. Let me be more specific;
we're really talking about CPE URIs and CPE Elements. The CPE Element
aims at the first objective, the unique name. The CPE URI aims to
support 'matching' or describe a set. A set is not a unique name, and
it's confusing to refer to both as CPEs.

It's not that both objectives aren't worthwhile, but more that they're
distinct.

That first objective, providing a unique name, is mutually exclusive
with describing a platform, where a platform is defined as a set of
hardware, os and applications. If the goal is to uniquely describe an
object, it must be done at the most atomic level (e.g. a unique name
describes a unique object).

A CVE describes a single, unique vulnerability.
A CCE describes a single, unique configuration item.
A CPE describes a single, unique platform.

If 'platform' refers to a set, then it cannot be the object to which a
unique name refers. It would be more accurate to state:

A CPE Element describes a single, unique piece of hardware, operating
system, or application.
A CPE URI describes a set of CPE Elements.

Does that make sense in the context here?

--Tim Erlin

--
------------------------------
-| Tim Erlin, CISSP
-| Principal Product Manager
-| nCircle Network Security
-| 101 2nd Street, Suite 400
-| San Francisco, CA 94105
-| Office: +1 415 625 5971
-| www.ncircle.com
-| blog.ncircle.com
-------------------------------

Waltermire, Dave [USA]

Re: Functional Goals and Design Principles of CPE

Reply Threaded

Thank you Tim. This is very concisely stated and frames the discussion
well.

Dave

-----Original Message-----
From: Tim Erlin [mailto:[hidden email]]
Sent: Thursday, May 24, 2007 12:55 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Buttner, Drew wrote:

Ken Lassesen-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Tim Erlin-2

I agree with Tim here, but the term "Platform" should likely be called a
"Product". An OS is typically a small core of essential files, i.e.
DLL's and a large number of optional files which provides add on
services to this core. The core could be defined as the smallest subset
of files required to get the OS up. Open up windows and you will see in
the administrative control panels a list of services. Most (if not all)
of the listed services can be disabled, thus they are not part of the
core.
The optional files may define one or more products, in some
cases, the same identical files may be involved but because of registry
entries or magic-keys somewhere, we have a different edition of the
product (SQL Server editions are one example). The technical enumeration
should be to that fine level.

There is also a management advantage to being able to say something like
"Windows Vista Basic" which is a collection of two parts: that which
will be there and that which may be there. These are aggregations.

May I toss out the following suggestion for discussion, define things in
this type of LANGUAGE --- yes, we are likely needing to define a
language to get this issue resolved:

<cpe id="element:os:WinXP"/> -- core OS
<cpe id="element:service:DCOM"/> -- a product
<cpe id="element:application:Microsoft Word"/> -- a product, core
(absolute min install)

And for aggregation we have something like this
<cpe id="aggregation:os:Win XP Home">
<cpe id="element:os:WinXP" required="true"/>
<cpe id="element:service:DCOM" required="false">
<cpe id="element:service:RemoteDCOM" required="false">
</cpe>
</cpe>

With dependencies being nested. Thus we have the higher level
'abstractions' available, with the fuzz indicated (i.e. required is
unclear).... This does make it easy to know is a high level name
contains any technical items of interest....

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Tim Erlin [mailto:[hidden email]]
Sent: Thursday, May 24, 2007 9:55 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Buttner, Drew wrote:
> objective
> -----------
> The primary objective of CPE is to provide a unique name for a given
> platform. The need for this is well documented within the community
> and such a name will help vendors and tools share necessary
> information.
>
> In addition to providing a unique name, CPE is attempting to support
> the application of matching. When a checking or analysis tool tests a

> real IT target system, it must be able to decide whether any given CPE

> Name corresponds to that system, and vice-versa. This is called
> matching.

Perhaps this is where some of the confusion lies. These two objectives
are both ostensibly addressed by something called CPE, but they really
require two distinct information structures. Let me be more specific;
we're really talking about CPE URIs and CPE Elements. The CPE Element
aims at the first objective, the unique name. The CPE URI aims to
support 'matching' or describe a set. A set is not a unique name, and
it's confusing to refer to both as CPEs.

It's not that both objectives aren't worthwhile, but more that they're
distinct.

That first objective, providing a unique name, is mutually exclusive
with describing a platform, where a platform is defined as a set of
hardware, os and applications. If the goal is to uniquely describe an
object, it must be done at the most atomic level (e.g. a unique name
describes a unique object).

A CVE describes a single, unique vulnerability.
A CCE describes a single, unique configuration item.
A CPE describes a single, unique platform.

If 'platform' refers to a set, then it cannot be the object to which a
unique name refers. It would be more accurate to state:

A CPE Element describes a single, unique piece of hardware, operating
system, or application.
A CPE URI describes a set of CPE Elements.

Does that make sense in the context here?

--Tim Erlin

--
------------------------------
-| Tim Erlin, CISSP
-| Principal Product Manager
-| nCircle Network Security
-| 101 2nd Street, Suite 400
-| San Francisco, CA 94105
-| Office: +1 415 625 5971
-| www.ncircle.com
-| blog.ncircle.com
-------------------------------

Andrew Buttner

Re: Functional Goals and Design Principles of CPE

Reply Threaded

Just a quick note regarding the idea of a language, I agree that this
would be easier and probably more powerful, but I think we need our
enumeration to be of a single line variety as the reality of the
community is that this is how it is currently implemented. We are
looking to replace the 'winxp' and 'windows xp' strings that are out
there with a standardized string. I think it would be a hard sell to
tools to get them to change their single line reference to an XML
structure.

Maybe what I am hearing is that we need both.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 1:30 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>I agree with Tim here, but the term "Platform" should likely
>be called a
>"Product". An OS is typically a small core of essential files, i.e.
>DLL's and a large number of optional files which provides add on
>services to this core. The core could be defined as the smallest

subset
>of files required to get the OS up. Open up windows and you will see
in
>the administrative control panels a list of services. Most (if not
all)
>of the listed services can be disabled, thus they are not part of the
>core.
> The optional files may define one or more products, in some
>cases, the same identical files may be involved but because of
registry

>entries or magic-keys somewhere, we have a different edition of the
>product (SQL Server editions are one example). The technical
>enumeration
>should be to that fine level.
>
>There is also a management advantage to being able to say
>something like
>"Windows Vista Basic" which is a collection of two parts: that which
>will be there and that which may be there. These are aggregations.
>
>May I toss out the following suggestion for discussion, define
>things in
>this type of LANGUAGE --- yes, we are likely needing to define a
>language to get this issue resolved:
>
><cpe id="element:os:WinXP"/> -- core OS
><cpe id="element:service:DCOM"/> -- a product
><cpe id="element:application:Microsoft Word"/> -- a product,

core

>(absolute min install)
>
>And for aggregation we have something like this
><cpe id="aggregation:os:Win XP Home">
> <cpe id="element:os:WinXP" required="true"/>
> <cpe id="element:service:DCOM" required="false">
> <cpe id="element:service:RemoteDCOM" required="false">
> </cpe>
></cpe>
>
>With dependencies being nested. Thus we have the higher level
>'abstractions' available, with the fuzz indicated (i.e. required is
>unclear).... This does make it easy to know is a high level name
>contains any technical items of interest....
>
>
>
>
>Ken Lassesen,
>HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
>IM: [hidden email] [hidden email]
>mailto:[hidden email]
>CONFIDENTIALITY NOTICE
>The information contained in this electronic message may contain
>confidential and privileged information and is intended only for use

>the individual(s) or entity(ies) to whom it was addressed. Any
>unauthorized review, use, disclosure, or distribution of this
>communication is strictly prohibited. If you are not the intended
>recipient, please contact the sender by reply email and permanently
>delete and destroy the original message.
>
>
>-----Original Message-----
>From: Tim Erlin [mailto:[hidden email]]
>Sent: Thursday, May 24, 2007 9:55 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>Buttner, Drew wrote:
>> objective
>> -----------
>> The primary objective of CPE is to provide a unique name for a given

>> platform. The need for this is well documented within the community

>> and such a name will help vendors and tools share necessary
>> information.
>>
>> In addition to providing a unique name, CPE is attempting to support

>> the application of matching. When a checking or analysis
>tool tests a
>
>> real IT target system, it must be able to decide whether any
>given CPE
>
>> Name corresponds to that system, and vice-versa. This is called
>> matching.
>
>Perhaps this is where some of the confusion lies. These two objectives
>are both ostensibly addressed by something called CPE, but they really
>require two distinct information structures. Let me be more specific;
>we're really talking about CPE URIs and CPE Elements. The CPE Element
>aims at the first objective, the unique name. The CPE URI aims to
>support 'matching' or describe a set. A set is not a unique name, and
>it's confusing to refer to both as CPEs.
>
>It's not that both objectives aren't worthwhile, but more that they're
>distinct.
>
>That first objective, providing a unique name, is mutually exclusive
>with describing a platform, where a platform is defined as a set of
>hardware, os and applications. If the goal is to uniquely describe an
>object, it must be done at the most atomic level (e.g. a unique name
>describes a unique object).
>
>A CVE describes a single, unique vulnerability.
>A CCE describes a single, unique configuration item.
>A CPE describes a single, unique platform.
>
>If 'platform' refers to a set, then it cannot be the object to which a
>unique name refers. It would be more accurate to state:
>
>A CPE Element describes a single, unique piece of hardware, operating
>system, or application.
>A CPE URI describes a set of CPE Elements.
>
>Does that make sense in the context here?
>
>--Tim Erlin
>
>--
>------------------------------
>-| Tim Erlin, CISSP
>-| Principal Product Manager
>-| nCircle Network Security
>-| 101 2nd Street, Suite 400
>-| San Francisco, CA 94105
>-| Office: +1 415 625 5971
>-| www.ncircle.com
>-| blog.ncircle.com
>-------------------------------
>

Wolfkiel, Joseph

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Tim Keanini Sr.

I'd really like to hear some feedback on this one. Is it really any easier
to store, transmit, and parse a single line CPE than a normal XML
representation of the same thing?

While it is smaller, the CPE format we're using now doesn't lend itself to
easy XML parsing (correct me if I'm wrong), and if size/bandwidth is the
real issue, we could probably save space by indexing the CPE names and
sending index numbers instead of entire text strings.

Thoughts?

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, May 25, 2007 7:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Just a quick note regarding the idea of a language, I agree that this
would be easier and probably more powerful, but I think we need our
enumeration to be of a single line variety as the reality of the
community is that this is how it is currently implemented. We are
looking to replace the 'winxp' and 'windows xp' strings that are out
there with a standardized string. I think it would be a hard sell to
tools to get them to change their single line reference to an XML
structure.

Maybe what I am hearing is that we need both.

Thanks
Drew

core

Waltermire, Dave [USA]

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Andrew Buttner

Drew,

Would you provide more detail illustrating what you mean by "both"?

Dave

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, May 25, 2007 7:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Just a quick note regarding the idea of a language, I agree that this
would be easier and probably more powerful, but I think we need our
enumeration to be of a single line variety as the reality of the
community is that this is how it is currently implemented. We are
looking to replace the 'winxp' and 'windows xp' strings that are out
there with a standardized string. I think it would be a hard sell to
tools to get them to change their single line reference to an XML
structure.

Maybe what I am hearing is that we need both.

Thanks
Drew

core

Ken Lassesen-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Andrew Buttner

If you look below, you can keep the single line reference, just cite
idref="aggregation:os:Win XP Home"

This is a pointer to a CPE-Definition file the provides the
breakdown/specifics. The CPE becomes an identifier, with the CPE.XML
providing the technical definitions

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, May 25, 2007 4:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Just a quick note regarding the idea of a language, I agree that this
would be easier and probably more powerful, but I think we need our
enumeration to be of a single line variety as the reality of the
community is that this is how it is currently implemented. We are
looking to replace the 'winxp' and 'windows xp' strings that are out
there with a standardized string. I think it would be a hard sell to
tools to get them to change their single line reference to an XML
structure.

Maybe what I am hearing is that we need both.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 1:30 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>I agree with Tim here, but the term "Platform" should likely be called
>a "Product". An OS is typically a small core of essential files, i.e.
>DLL's and a large number of optional files which provides add on
>services to this core. The core could be defined as the smallest

>entries or magic-keys somewhere, we have a different edition of the
>product (SQL Server editions are one example). The technical
>enumeration should be to that fine level.
>
>There is also a management advantage to being able to say something
>like "Windows Vista Basic" which is a collection of two parts: that
>which will be there and that which may be there. These are
>aggregations.
>
>May I toss out the following suggestion for discussion, define things
>in this type of LANGUAGE --- yes, we are likely needing to define a
>language to get this issue resolved:
>
><cpe id="element:os:WinXP"/> -- core OS
><cpe id="element:service:DCOM"/> -- a product
><cpe id="element:application:Microsoft Word"/> -- a product,

core

>(absolute min install)
>
>And for aggregation we have something like this <cpe
>id="aggregation:os:Win XP Home">
> <cpe id="element:os:WinXP" required="true"/>
> <cpe id="element:service:DCOM" required="false">
> <cpe id="element:service:RemoteDCOM" required="false">
> </cpe>
></cpe>
>
>With dependencies being nested. Thus we have the higher level
>'abstractions' available, with the fuzz indicated (i.e. required is
>unclear).... This does make it easy to know is a high level name
>contains any technical items of interest....
>
>
>
>
>Ken Lassesen,
>HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
>IM: [hidden email] [hidden email] mailto:[hidden email]
>CONFIDENTIALITY NOTICE The information contained in this electronic
>message may contain confidential and privileged information and is
>intended only for use

Andrew Buttner

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Waltermire, Dave [USA]

I was thinking of one effort trying to create standard names for the
known and somewhat stable building blocks. (I think this was mentioned
on this list) And a second effort to create a language to combining
the building blocks into complex descriptions. This language would be
lighter weight than OVAL and not able to support automated checking,
but could be used to do the matching part of CPE. This language would
look like the suggestions on this list and what Neal originally had in
XCCDF-p

Thanks
Drew

>-----Original Message-----
>From: Waltermire, Dave [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 10:10 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>Drew,
>
>Would you provide more detail illustrating what you mean by "both"?
>
>Dave
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 7:45 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>Just a quick note regarding the idea of a language, I agree that this
>would be easier and probably more powerful, but I think we need our
>enumeration to be of a single line variety as the reality of the
>community is that this is how it is currently implemented. We are
>looking to replace the 'winxp' and 'windows xp' strings that are out
>there with a standardized string. I think it would be a hard sell to
>tools to get them to change their single line reference to an XML
>structure.
>
>Maybe what I am hearing is that we need both.
>
>Thanks
>Drew
>
>>-----Original Message-----
>>From: Ken Lassesen [mailto:[hidden email]]
>>Sent: Friday, May 25, 2007 1:30 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>>Principles of CPE
>>
>>I agree with Tim here, but the term "Platform" should likely
>>be called a
>>"Product". An OS is typically a small core of essential files, i.e.
>>DLL's and a large number of optional files which provides add on
>>services to this core. The core could be defined as the smallest
>subset
>>of files required to get the OS up. Open up windows and you will see
>in
>>the administrative control panels a list of services. Most (if not
>all)
>>of the listed services can be disabled, thus they are not part of the
>>core.
>> The optional files may define one or more products, in some
>>cases, the same identical files may be involved but because of
>registry
>>entries or magic-keys somewhere, we have a different edition of the
>>product (SQL Server editions are one example). The technical
>>enumeration
>>should be to that fine level.
>>
>>There is also a management advantage to being able to say
>>something like
>>"Windows Vista Basic" which is a collection of two parts: that which
>>will be there and that which may be there. These are aggregations.
>>
>>May I toss out the following suggestion for discussion, define
>>things in
>>this type of LANGUAGE --- yes, we are likely needing to define a
>>language to get this issue resolved:
>>
>><cpe id="element:os:WinXP"/> -- core OS
>><cpe id="element:service:DCOM"/> -- a product
>><cpe id="element:application:Microsoft Word"/> -- a product,
>core
>>(absolute min install)
>>
>>And for aggregation we have something like this
>><cpe id="aggregation:os:Win XP Home">
>> <cpe id="element:os:WinXP" required="true"/>
>> <cpe id="element:service:DCOM" required="false">
>> <cpe id="element:service:RemoteDCOM" required="false">
>> </cpe>
>></cpe>
>>
>>With dependencies being nested. Thus we have the higher level
>>'abstractions' available, with the fuzz indicated (i.e. required is
>>unclear).... This does make it easy to know is a high level name
>>contains any technical items of interest....
>>
>>
>>
>>
>>Ken Lassesen,
>>HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
>>IM: [hidden email] [hidden email]
>>mailto:[hidden email]
>>CONFIDENTIALITY NOTICE
>>The information contained in this electronic message may contain
>>confidential and privileged information and is intended only for use
>by
>>the individual(s) or entity(ies) to whom it was addressed. Any
>>unauthorized review, use, disclosure, or distribution of this
>>communication is strictly prohibited. If you are not the intended
>>recipient, please contact the sender by reply email and permanently
>>delete and destroy the original message.
>>
>>
>>-----Original Message-----
>>From: Tim Erlin [mailto:[hidden email]]
>>Sent: Thursday, May 24, 2007 9:55 AM
>>To: [hidden email]
>>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>>Principles of CPE
>>
>>Buttner, Drew wrote:
>>> objective
>>> -----------
>>> The primary objective of CPE is to provide a unique name for a

given
>
>>> platform. The need for this is well documented within the
community
>
>>> and such a name will help vendors and tools share necessary
>>> information.
>>>
>>> In addition to providing a unique name, CPE is attempting to
support

objectives
>>are both ostensibly addressed by something called CPE, but they
really
>>require two distinct information structures. Let me be more specific;
>>we're really talking about CPE URIs and CPE Elements. The CPE Element
>>aims at the first objective, the unique name. The CPE URI aims to
>>support 'matching' or describe a set. A set is not a unique name, and
>>it's confusing to refer to both as CPEs.
>>
>>It's not that both objectives aren't worthwhile, but more that
they're

>>distinct.
>>
>>That first objective, providing a unique name, is mutually exclusive
>>with describing a platform, where a platform is defined as a set of
>>hardware, os and applications. If the goal is to uniquely describe an
>>object, it must be done at the most atomic level (e.g. a unique name
>>describes a unique object).
>>
>>A CVE describes a single, unique vulnerability.
>>A CCE describes a single, unique configuration item.
>>A CPE describes a single, unique platform.
>>
>>If 'platform' refers to a set, then it cannot be the object to which

>>unique name refers. It would be more accurate to state:
>>
>>A CPE Element describes a single, unique piece of hardware, operating
>>system, or application.
>>A CPE URI describes a set of CPE Elements.
>>
>>Does that make sense in the context here?
>>
>>--Tim Erlin
>>
>>--
>>------------------------------
>>-| Tim Erlin, CISSP
>>-| Principal Product Manager
>>-| nCircle Network Security
>>-| 101 2nd Street, Suite 400
>>-| San Francisco, CA 94105
>>-| Office: +1 415 625 5971
>>-| www.ncircle.com
>>-| blog.ncircle.com
>>-------------------------------
>>
>

Waltermire, Dave [USA]

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Tim Keanini Sr.

It would be good to have an unofficial yes or no vote on this approach. We obviously need to work out how these two standards will work. I vote strongly in favor of this solution. Does anyone disagree with this approach? If you are a stakeholder, please voice your opinion on this. I'd like to keep the discussion moving on this so that we can finalize a CPE specification soon.

Dave

Dave

-----Original Message-----
From: "Buttner, Drew" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: 5/25/07 1:21 PM
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design Principles of CPE

I was thinking of one effort trying to create standard names for the
known and somewhat stable building blocks. (I think this was mentioned
on this list) And a second effort to create a language to combining
the building blocks into complex descriptions. This language would be
lighter weight than OVAL and not able to support automated checking,
but could be used to do the matching part of CPE. This language would
look like the suggestions on this list and what Neal originally had in
XCCDF-p

Thanks
Drew

Ken Lassesen-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Wolfkiel, Joseph

The goal of using meaningful names is noble, but fraught with
ambiguousness. I would prefer to see the OVAL pattern for the id's
cperef="cpe:com.patchlink.cpe:os:10293"

With adjust files providing the definitions, INCLUDING the oval tests
needed to make this determination. i.e.
<cpe id="cpe:com.patchlink.cpe:os:10293"
defid="oval:com.patchlink.cpe:def:293823">
<title lang="us-en">Windows 98 US Edition, English</title>
</cpe>
<cpe id="cpe:com.patchlink.cpe:os:10293"
defid="oval:com.patchlink.cpe:def:293824">
<title lang="us-en">Windows 98 Canadian Edition, French</title>
<title lang="ca-fr">Windows 98 Quebecois</title>
</cpe>

This allows us to tie the parts together far better, in fact, it should
allow the elimination of some of the test_def's in OVAL because the
cperef's in an OVAL definition implicitly implies that their associated
OVAL tests be done as a pre-condition.

It does support a more efficients multi-pass implementation..
--> Send the cpe's down to the agent to determine what is installed
--> Send down only the OVAL definitions for what is installed.

This allows less load on the host computers and less elapse time. A win
win. It also allows more compact OVAL definitions, for a third win.

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, May 25, 2007 5:03 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

I'd really like to hear some feedback on this one. Is it really any
easier to store, transmit, and parse a single line CPE than a normal XML
representation of the same thing?

While it is smaller, the CPE format we're using now doesn't lend itself
to easy XML parsing (correct me if I'm wrong), and if size/bandwidth is
the real issue, we could probably save space by indexing the CPE names
and sending index numbers instead of entire text strings.

Thoughts?

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T)
Program Management Office

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, May 25, 2007 7:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Just a quick note regarding the idea of a language, I agree that this
would be easier and probably more powerful, but I think we need our
enumeration to be of a single line variety as the reality of the
community is that this is how it is currently implemented. We are
looking to replace the 'winxp' and 'windows xp' strings that are out
there with a standardized string. I think it would be a hard sell to
tools to get them to change their single line reference to an XML
structure.

Maybe what I am hearing is that we need both.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 1:30 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>I agree with Tim here, but the term "Platform" should likely be called
>a "Product". An OS is typically a small core of essential files, i.e.
>DLL's and a large number of optional files which provides add on
>services to this core. The core could be defined as the smallest

core

Ken Lassesen-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

As a further FYI:

cperef="cpe:com.patchlink.cpe:os:10293" comment="Windows 98 US
Edition, English"

Should server both purposes, plain english and technical

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Tuesday, May 29, 2007 6:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

The goal of using meaningful names is noble, but fraught with
ambiguousness. I would prefer to see the OVAL pattern for the id's
cperef="cpe:com.patchlink.cpe:os:10293"

With adjust files providing the definitions, INCLUDING the oval tests
needed to make this determination. i.e.
<cpe id="cpe:com.patchlink.cpe:os:10293"
defid="oval:com.patchlink.cpe:def:293823">
<title lang="us-en">Windows 98 US Edition, English</title> </cpe>
<cpe id="cpe:com.patchlink.cpe:os:10293"
defid="oval:com.patchlink.cpe:def:293824">
<title lang="us-en">Windows 98 Canadian Edition, French</title>
<title lang="ca-fr">Windows 98 Quebecois</title> </cpe>

This allows us to tie the parts together far better, in fact, it should
allow the elimination of some of the test_def's in OVAL because the
cperef's in an OVAL definition implicitly implies that their associated
OVAL tests be done as a pre-condition.

It does support a more efficients multi-pass implementation..
--> Send the cpe's down to the agent to determine what is installed Send

--> down only the OVAL definitions for what is installed.

This allows less load on the host computers and less elapse time. A win
win. It also allows more compact OVAL definitions, for a third win.

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email] mailto:[hidden email]
CONFIDENTIALITY NOTICE The information contained in this electronic
message may contain confidential and privileged information and is
intended only for use by the individual(s) or entity(ies) to whom it was
addressed. Any unauthorized review, use, disclosure, or distribution of
this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, May 25, 2007 5:03 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

I'd really like to hear some feedback on this one. Is it really any
easier to store, transmit, and parse a single line CPE than a normal XML
representation of the same thing?

While it is smaller, the CPE format we're using now doesn't lend itself
to easy XML parsing (correct me if I'm wrong), and if size/bandwidth is
the real issue, we could probably save space by indexing the CPE names
and sending index numbers instead of entire text strings.

Thoughts?

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T)
Program Management Office

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, May 25, 2007 7:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Just a quick note regarding the idea of a language, I agree that this
would be easier and probably more powerful, but I think we need our
enumeration to be of a single line variety as the reality of the
community is that this is how it is currently implemented. We are
looking to replace the 'winxp' and 'windows xp' strings that are out
there with a standardized string. I think it would be a hard sell to
tools to get them to change their single line reference to an XML
structure.

Maybe what I am hearing is that we need both.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 1:30 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>I agree with Tim here, but the term "Platform" should likely be called
>a "Product". An OS is typically a small core of essential files, i.e.
>DLL's and a large number of optional files which provides add on
>services to this core. The core could be defined as the smallest

core

Waltermire, Dave [USA]

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Ken Lassesen-2

I don't have a preference one way or the other regarding if the names
need to be human readable. Making them human readable may help in their
use when marking up content. What you are suggesting below, and it may
be unintentional, is that there be a namespace facet to each CPE. While
this would support the current state of different organizations having
their own product lists, this goes against what we are trying to
accomplish. That is globally unique COMMON identifiers that are shared
across ALL organizations. We need to have a common naming authority to
have a common vocabulary of products.

It seems to me that we need to also define a community process for
handling new product names as they are "discovered". It should
indicate:

1) How IDs will be assigned
2) Who will be the gatekeeper
3) How duplicate entries will be avoided/resolved.

Perhaps the CVE community can speak to this and provide some insight on
how best to proceed.

Dave

-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Tuesday, May 29, 2007 9:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

The goal of using meaningful names is noble, but fraught with
ambiguousness. I would prefer to see the OVAL pattern for the id's
cperef="cpe:com.patchlink.cpe:os:10293"

With adjust files providing the definitions, INCLUDING the oval tests
needed to make this determination. i.e.
<cpe id="cpe:com.patchlink.cpe:os:10293"
defid="oval:com.patchlink.cpe:def:293823">
<title lang="us-en">Windows 98 US Edition, English</title>
</cpe>
<cpe id="cpe:com.patchlink.cpe:os:10293"
defid="oval:com.patchlink.cpe:def:293824">
<title lang="us-en">Windows 98 Canadian Edition, French</title>
<title lang="ca-fr">Windows 98 Quebecois</title>
</cpe>

This allows us to tie the parts together far better, in fact, it should
allow the elimination of some of the test_def's in OVAL because the
cperef's in an OVAL definition implicitly implies that their associated
OVAL tests be done as a pre-condition.

It does support a more efficients multi-pass implementation..
--> Send the cpe's down to the agent to determine what is installed
--> Send down only the OVAL definitions for what is installed.

This allows less load on the host computers and less elapse time. A win
win. It also allows more compact OVAL definitions, for a third win.

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, May 25, 2007 5:03 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

I'd really like to hear some feedback on this one. Is it really any
easier to store, transmit, and parse a single line CPE than a normal XML
representation of the same thing?

While it is smaller, the CPE format we're using now doesn't lend itself
to easy XML parsing (correct me if I'm wrong), and if size/bandwidth is
the real issue, we could probably save space by indexing the CPE names
and sending index numbers instead of entire text strings.

Thoughts?

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T)
Program Management Office

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, May 25, 2007 7:45 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

Just a quick note regarding the idea of a language, I agree that this
would be easier and probably more powerful, but I think we need our
enumeration to be of a single line variety as the reality of the
community is that this is how it is currently implemented. We are
looking to replace the 'winxp' and 'windows xp' strings that are out
there with a standardized string. I think it would be a hard sell to
tools to get them to change their single line reference to an XML
structure.

Maybe what I am hearing is that we need both.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 1:30 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>I agree with Tim here, but the term "Platform" should likely be called
>a "Product". An OS is typically a small core of essential files, i.e.
>DLL's and a large number of optional files which provides add on
>services to this core. The core could be defined as the smallest

core

Tim Erlin-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

Dave,

I agree. The commonality across organizations is a requirement, but so
is separation from a testing method. OVAL, as a definition of a method
for testing some thing, can't also be the unique identifier for that
thing. There's a reason that OVAL does not replace CVE.

There's nothing wrong with defining an OVAL-like specification for
determining operating system, application or hardware information, but
it would be a separate effort from a common namespace.

--Tim

Waltermire, Dave wrote:

> I don't have a preference one way or the other regarding if the names
> need to be human readable. Making them human readable may help in their
> use when marking up content. What you are suggesting below, and it may
> be unintentional, is that there be a namespace facet to each CPE. While
> this would support the current state of different organizations having
> their own product lists, this goes against what we are trying to
> accomplish. That is globally unique COMMON identifiers that are shared
> across ALL organizations. We need to have a common naming authority to
> have a common vocabulary of products.
>
> It seems to me that we need to also define a community process for
> handling new product names as they are "discovered". It should
> indicate:
>
> 1) How IDs will be assigned
> 2) Who will be the gatekeeper
> 3) How duplicate entries will be avoided/resolved.
>
> Perhaps the CVE community can speak to this and provide some insight on
> how best to proceed.
>
> Dave
>
>
> -----Original Message-----
> From: Ken Lassesen [mailto:[hidden email]]
> Sent: Tuesday, May 29, 2007 9:45 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
> Principles of CPE
>
> The goal of using meaningful names is noble, but fraught with
> ambiguousness. I would prefer to see the OVAL pattern for the id's
> cperef="cpe:com.patchlink.cpe:os:10293"
>
> With adjust files providing the definitions, INCLUDING the oval tests
> needed to make this determination. i.e.
> <cpe id="cpe:com.patchlink.cpe:os:10293"
> defid="oval:com.patchlink.cpe:def:293823">
> <title lang="us-en">Windows 98 US Edition, English</title>
> </cpe>
> <cpe id="cpe:com.patchlink.cpe:os:10293"
> defid="oval:com.patchlink.cpe:def:293824">
> <title lang="us-en">Windows 98 Canadian Edition, French</title>
> <title lang="ca-fr">Windows 98 Quebecois</title>
> </cpe>
>
> This allows us to tie the parts together far better, in fact, it should
> allow the elimination of some of the test_def's in OVAL because the
> cperef's in an OVAL definition implicitly implies that their associated
> OVAL tests be done as a pre-condition.
>
> It does support a more efficients multi-pass implementation..
> --> Send the cpe's down to the agent to determine what is installed
> --> Send down only the OVAL definitions for what is installed.
>
> This allows less load on the host computers and less elapse time. A win
> win. It also allows more compact OVAL definitions, for a third win.
>
> Ken Lassesen,
> HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
> IM: [hidden email] [hidden email]
> mailto:[hidden email]
> CONFIDENTIALITY NOTICE
> The information contained in this electronic message may contain
> confidential and privileged information and is intended only for use by
> the individual(s) or entity(ies) to whom it was addressed. Any
> unauthorized review, use, disclosure, or distribution of this
> communication is strictly prohibited. If you are not the intended
> recipient, please contact the sender by reply email and permanently
> delete and destroy the original message.
>
>
> -----Original Message-----
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Friday, May 25, 2007 5:03 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
> Principles of CPE
>
> I'd really like to hear some feedback on this one. Is it really any
> easier to store, transmit, and parse a single line CPE than a normal XML
> representation of the same thing?
>
> While it is smaller, the CPE format we're using now doesn't lend itself
> to easy XML parsing (correct me if I'm wrong), and if size/bandwidth is
> the real issue, we could probably save space by indexing the CPE names
> and sending index numbers instead of entire text strings.
>
> Thoughts?
>
> Lt Col Joseph L. Wolfkiel
>
> Director, Computer Network Defense Research & Technology (CND R&T)
> Program Management Office
>
> NSA/I71
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
>
> -----Original Message-----
> From: Buttner, Drew [mailto:[hidden email]]
> Sent: Friday, May 25, 2007 7:45 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
> Principles of CPE
>
>
> Just a quick note regarding the idea of a language, I agree that this
> would be easier and probably more powerful, but I think we need our
> enumeration to be of a single line variety as the reality of the
> community is that this is how it is currently implemented. We are
> looking to replace the 'winxp' and 'windows xp' strings that are out
> there with a standardized string. I think it would be a hard sell to
> tools to get them to change their single line reference to an XML
> structure.
>
> Maybe what I am hearing is that we need both.
>
> Thanks
> Drew
>
>> -----Original Message-----
>> From: Ken Lassesen [mailto:[hidden email]]
>> Sent: Friday, May 25, 2007 1:30 AM
>> To: cpe-discussion-list CPE Community Forum
>> Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>> Principles of CPE
>>
>> I agree with Tim here, but the term "Platform" should likely be called
>> a "Product". An OS is typically a small core of essential files, i.e.
>> DLL's and a large number of optional files which provides add on
>> services to this core. The core could be defined as the smallest
> subset
>> of files required to get the OS up. Open up windows and you will see
> in
>> the administrative control panels a list of services. Most (if not
> all)
>> of the listed services can be disabled, thus they are not part of the
>> core.
>> The optional files may define one or more products, in some
>> cases, the same identical files may be involved but because of
> registry
>> entries or magic-keys somewhere, we have a different edition of the
>> product (SQL Server editions are one example). The technical
>> enumeration should be to that fine level.
>>
>> There is also a management advantage to being able to say something
>> like "Windows Vista Basic" which is a collection of two parts: that
>> which will be there and that which may be there. These are
>> aggregations.
>>
>> May I toss out the following suggestion for discussion, define things
>> in this type of LANGUAGE --- yes, we are likely needing to define a
>> language to get this issue resolved:
>>
>> <cpe id="element:os:WinXP"/> -- core OS
>> <cpe id="element:service:DCOM"/> -- a product
>> <cpe id="element:application:Microsoft Word"/> -- a product,
> core
>> (absolute min install)
>>
>> And for aggregation we have something like this <cpe
>> id="aggregation:os:Win XP Home">
>> <cpe id="element:os:WinXP" required="true"/>
>> <cpe id="element:service:DCOM" required="false">
>> <cpe id="element:service:RemoteDCOM" required="false">
>> </cpe>
>> </cpe>
>>
>> With dependencies being nested. Thus we have the higher level
>> 'abstractions' available, with the fuzz indicated (i.e. required is
>> unclear).... This does make it easy to know is a high level name
>> contains any technical items of interest....
>>
>>
>>
>>
>> Ken Lassesen,
>> HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
>> IM: [hidden email] [hidden email] mailto:[hidden email]
>> CONFIDENTIALITY NOTICE The information contained in this electronic
>> message may contain confidential and privileged information and is
>> intended only for use
> by
>> the individual(s) or entity(ies) to whom it was addressed. Any
>> unauthorized review, use, disclosure, or distribution of this
>> communication is strictly prohibited. If you are not the intended
>> recipient, please contact the sender by reply email and permanently
>> delete and destroy the original message.
>>
>>
>> -----Original Message-----
>> From: Tim Erlin [mailto:[hidden email]]
>> Sent: Thursday, May 24, 2007 9:55 AM
>> To: [hidden email]
>> Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>> Principles of CPE
>>
>> Buttner, Drew wrote:
>>> objective
>>> -----------
>>> The primary objective of CPE is to provide a unique name for a given
>
>>> platform. The need for this is well documented within the community
>
>>> and such a name will help vendors and tools share necessary
>>> information.
>>>
>>> In addition to providing a unique name, CPE is attempting to support
>
>>> the application of matching. When a checking or analysis
>> tool tests a
>>
>>> real IT target system, it must be able to decide whether any
>> given CPE
>>
>>> Name corresponds to that system, and vice-versa. This is called
>>> matching.
>> Perhaps this is where some of the confusion lies. These two objectives
>> are both ostensibly addressed by something called CPE, but they really
>> require two distinct information structures. Let me be more specific;
>> we're really talking about CPE URIs and CPE Elements. The CPE Element
>> aims at the first objective, the unique name. The CPE URI aims to
>> support 'matching' or describe a set. A set is not a unique name, and
>> it's confusing to refer to both as CPEs.
>>
>> It's not that both objectives aren't worthwhile, but more that they're
>> distinct.
>>
>> That first objective, providing a unique name, is mutually exclusive
>> with describing a platform, where a platform is defined as a set of
>> hardware, os and applications. If the goal is to uniquely describe an
>> object, it must be done at the most atomic level (e.g. a unique name
>> describes a unique object).
>>
>> A CVE describes a single, unique vulnerability.
>> A CCE describes a single, unique configuration item.
>> A CPE describes a single, unique platform.
>>
>> If 'platform' refers to a set, then it cannot be the object to which a
>> unique name refers. It would be more accurate to state:
>>
>> A CPE Element describes a single, unique piece of hardware, operating
>> system, or application.
>> A CPE URI describes a set of CPE Elements.
>>
>> Does that make sense in the context here?
>>
>> --Tim Erlin
>>
>> --
>> ------------------------------
>> -| Tim Erlin, CISSP
>> -| Principal Product Manager
>> -| nCircle Network Security
>> -| 101 2nd Street, Suite 400
>> -| San Francisco, CA 94105
>> -| Office: +1 415 625 5971
>> -| www.ncircle.com
>> -| blog.ncircle.com
>> -------------------------------
>>

Andrew Buttner

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Ken Lassesen-2

One of the problems with numerical IDs (this a problem that CVE and
OVAL has) is that someone has to manage them. We have solved this
somewhat by either giving out blocks of numbers or by assigning unique
namespaces. But it still put the moderator "in the loop", either
assigning the blocks or the namespaces. Because the number of possible
platforms is infinite, and because the need for new CPE names is
expected to be high, we made a decision that we wanted the moderator
"in the loop" as little as possible.

Part of our solution to this was to rely on a structured naming format
that allowed individuals to create new names, knowing what the official
name will be. With random numbers this is not possible. With
namespaces, others will not know what a name in someone else's'
namespace will be.

Obviously, our solution is not implemented perfectly as two names might
be created by different parties with a different order given to some of
the components. Right now we have them refer to the dictionary for
guidance, which really means to get the moderator involved.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Tuesday, May 29, 2007 9:45 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>The goal of using meaningful names is noble, but fraught with
>ambiguousness. I would prefer to see the OVAL pattern for the id's
> cperef="cpe:com.patchlink.cpe:os:10293"
>
>With adjust files providing the definitions, INCLUDING the oval tests
>needed to make this determination. i.e.
><cpe id="cpe:com.patchlink.cpe:os:10293"
>defid="oval:com.patchlink.cpe:def:293823">
> <title lang="us-en">Windows 98 US Edition, English</title>
></cpe>
><cpe id="cpe:com.patchlink.cpe:os:10293"
>defid="oval:com.patchlink.cpe:def:293824">
> <title lang="us-en">Windows 98 Canadian Edition, French</title>
> <title lang="ca-fr">Windows 98 Quebecois</title>
></cpe>
>
>This allows us to tie the parts together far better, in fact, it

should
>allow the elimination of some of the test_def's in OVAL because the
>cperef's in an OVAL definition implicitly implies that their
associated
>OVAL tests be done as a pre-condition.
>
>It does support a more efficients multi-pass implementation..
>--> Send the cpe's down to the agent to determine what is installed
>--> Send down only the OVAL definitions for what is installed.
>
>This allows less load on the host computers and less elapse time. A
win
>win. It also allows more compact OVAL definitions, for a third win.
>
>Ken Lassesen,
>HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
>IM: [hidden email] [hidden email]
>mailto:[hidden email]
>CONFIDENTIALITY NOTICE
>The information contained in this electronic message may contain
>confidential and privileged information and is intended only for use
by

>the individual(s) or entity(ies) to whom it was addressed. Any
>unauthorized review, use, disclosure, or distribution of this
>communication is strictly prohibited. If you are not the intended
>recipient, please contact the sender by reply email and permanently
>delete and destroy the original message.
>
>
>-----Original Message-----
>From: Wolfkiel, Joseph [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 5:03 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>I'd really like to hear some feedback on this one. Is it really any
>easier to store, transmit, and parse a single line CPE than a
>normal XML
>representation of the same thing?
>
>While it is smaller, the CPE format we're using now doesn't lend

itself
>to easy XML parsing (correct me if I'm wrong), and if size/bandwidth
is

>the real issue, we could probably save space by indexing the CPE names
>and sending index numbers instead of entire text strings.
>
>Thoughts?
>
>Lt Col Joseph L. Wolfkiel
>
>Director, Computer Network Defense Research & Technology (CND R&T)
>Program Management Office
>
>NSA/I71
>9800 Savage Rd Ste 6767
>Ft Meade, MD 20755-6767
>Commercial 410-854-5401 DSN 244-5401
>Fax 410-854-6700
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Friday, May 25, 2007 7:45 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>Principles of CPE
>
>
>Just a quick note regarding the idea of a language, I agree that this
>would be easier and probably more powerful, but I think we need our
>enumeration to be of a single line variety as the reality of the
>community is that this is how it is currently implemented. We are
>looking to replace the 'winxp' and 'windows xp' strings that are out
>there with a standardized string. I think it would be a hard sell to
>tools to get them to change their single line reference to an XML
>structure.
>
>Maybe what I am hearing is that we need both.
>
>Thanks
>Drew
>
>>-----Original Message-----
>>From: Ken Lassesen [mailto:[hidden email]]
>>Sent: Friday, May 25, 2007 1:30 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>>Principles of CPE
>>
>>I agree with Tim here, but the term "Platform" should likely
>be called
>>a "Product". An OS is typically a small core of essential files, i.e.
>>DLL's and a large number of optional files which provides add on
>>services to this core. The core could be defined as the smallest
>subset
>>of files required to get the OS up. Open up windows and you will see
>in
>>the administrative control panels a list of services. Most (if not
>all)
>>of the listed services can be disabled, thus they are not part of the

>>core.
>> The optional files may define one or more products, in some
>>cases, the same identical files may be involved but because of
>registry
>>entries or magic-keys somewhere, we have a different edition of the
>>product (SQL Server editions are one example). The technical
>>enumeration should be to that fine level.
>>
>>There is also a management advantage to being able to say something
>>like "Windows Vista Basic" which is a collection of two parts: that
>>which will be there and that which may be there. These are
>>aggregations.
>>
>>May I toss out the following suggestion for discussion, define things

>>in this type of LANGUAGE --- yes, we are likely needing to define a
>>language to get this issue resolved:
>>
>><cpe id="element:os:WinXP"/> -- core OS
>><cpe id="element:service:DCOM"/> -- a product
>><cpe id="element:application:Microsoft Word"/> -- a product,
>core
>>(absolute min install)
>>
>>And for aggregation we have something like this <cpe
>>id="aggregation:os:Win XP Home">
>> <cpe id="element:os:WinXP" required="true"/>
>> <cpe id="element:service:DCOM" required="false">
>> <cpe id="element:service:RemoteDCOM" required="false">
>> </cpe>
>></cpe>
>>
>>With dependencies being nested. Thus we have the higher level
>>'abstractions' available, with the fuzz indicated (i.e. required is
>>unclear).... This does make it easy to know is a high level name
>>contains any technical items of interest....
>>
>>
>>
>>
>>Ken Lassesen,
>>HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
>>IM: [hidden email] [hidden email] mailto:[hidden email]

>>CONFIDENTIALITY NOTICE The information contained in this electronic
>>message may contain confidential and privileged information and is
>>intended only for use
>by
>>the individual(s) or entity(ies) to whom it was addressed. Any
>>unauthorized review, use, disclosure, or distribution of this
>>communication is strictly prohibited. If you are not the intended
>>recipient, please contact the sender by reply email and permanently
>>delete and destroy the original message.
>>
>>
>>-----Original Message-----
>>From: Tim Erlin [mailto:[hidden email]]
>>Sent: Thursday, May 24, 2007 9:55 AM
>>To: [hidden email]
>>Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
>>Principles of CPE
>>
>>Buttner, Drew wrote:
>>> objective
>>> -----------
>>> The primary objective of CPE is to provide a unique name for a

>
>>> the application of matching. When a checking or analysis
>>tool tests a
>>
>>> real IT target system, it must be able to decide whether any
>>given CPE
>>
>>> Name corresponds to that system, and vice-versa. This is called
>>> matching.
>>
>>Perhaps this is where some of the confusion lies. These two
>objectives
>>are both ostensibly addressed by something called CPE, but
>they really
>>require two distinct information structures. Let me be more specific;

>>we're really talking about CPE URIs and CPE Elements. The CPE Element

>>aims at the first objective, the unique name. The CPE URI aims to
>>support 'matching' or describe a set. A set is not a unique name, and

>>it's confusing to refer to both as CPEs.
>>
>>It's not that both objectives aren't worthwhile, but more
>that they're
>>distinct.
>>
>>That first objective, providing a unique name, is mutually exclusive
>>with describing a platform, where a platform is defined as a set of
>>hardware, os and applications. If the goal is to uniquely describe an

>>object, it must be done at the most atomic level (e.g. a unique name
>>describes a unique object).
>>
>>A CVE describes a single, unique vulnerability.
>>A CCE describes a single, unique configuration item.
>>A CPE describes a single, unique platform.
>>
>>If 'platform' refers to a set, then it cannot be the object
>to which a
>>unique name refers. It would be more accurate to state:
>>
>>A CPE Element describes a single, unique piece of hardware, operating

>>system, or application.
>>A CPE URI describes a set of CPE Elements.
>>
>>Does that make sense in the context here?
>>
>>--Tim Erlin
>>
>>--
>>------------------------------
>>-| Tim Erlin, CISSP
>>-| Principal Product Manager
>>-| nCircle Network Security
>>-| 101 2nd Street, Suite 400
>>-| San Francisco, CA 94105
>>-| Office: +1 415 625 5971
>>-| www.ncircle.com
>>-| blog.ncircle.com
>>-------------------------------
>>
>

Ken Lassesen-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

One possible constraints on CPE's may be the maximum length, many
database products will not support a long long variable name. A
structured naming format could end up with some very long names which
could hinder implementation.

One solution is to have a web site that any vendor can access to lookup
/ create a cpe with a short id: cp:8473494 and the long formally named
(as you proposed) name. A database can easily parse a long name into
it's part and show a short list of possible candidates, if none match,
then an new ID is created. There is no need for moderator involvment,
apart from approving those with create privledges (which would be any
vendor).

If you wish, I will create such a site and folks can try it out... If
it works, I'll donate the code to Mitre (SQL Server Express[free!] +
AspNet)

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

Thomas R. Jones

Re: Functional Goals and Design Principles of CPE

Reply Threaded

On Tue, 2007-05-29 at 15:46 -0700, Ken Lassesen wrote:
> One possible constraints on CPE's may be the maximum length, many
> database products will not support a long long variable name.=20

So is the intent of the CPE community to facilitate development of the
CPE schema according to commercial software developers desires? If so I
may be in the wrong community. Seemingly some of these projects are
getting more and more commercial centric.

It seems that entities, both commercial and open source, should alter
developmental requirements and implementations to accommodate the
language structure. Not the other way around.

Thomas

3Dsignature.asc (200 bytes) Download Attachment

Waltermire, Dave [USA]

Re: Functional Goals and Design Principles of CPE

Reply Threaded

Thomas,

The goal of the community is to facilitate development of a CPE standard
that is not completely commercial or academic in nature. We are trying
to address real-world operational issues that are currently barriers to
automating security. In previous discussions regarding OVAL and XCCDF
we have always tried to address issues in a way that would ease the
implementation burden of software developers implementing these
standards and align the standards with operational capabilities that are
badly needed in the industry. I am not advocating bending the standard
to cater to vendors, nor am I pushing the concept of developing
something based on the purest ideology. We need to take a balanced
approach.

I find that the distinct views of the participants in this community
that represent commercial, open-source, academic and operational
interests are very valuable to the overall discussion. These varying
perspectives provide considerable depth to the discussions we are
having. My hope is that because of this we will end up with something
that is widely useful and not extremely difficult to integrate and use
operationally.

Dave

-----Original Message-----
From: Thomas R. Jones [mailto:[hidden email]]
Sent: Wednesday, May 30, 2007 12:54 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Functional Goals and Design
Principles of CPE

On Tue, 2007-05-29 at 15:46 -0700, Ken Lassesen wrote:
> One possible constraints on CPE's may be the maximum length, many
> database products will not support a long long variable name.

So is the intent of the CPE community to facilitate development of the
CPE schema according to commercial software developers desires? If so I
may be in the wrong community. Seemingly some of these projects are
getting more and more commercial centric.

It seems that entities, both commercial and open source, should alter
developmental requirements and implementations to accommodate the
language structure. Not the other way around.

Thomas

Ken Lassesen-2

Re: Functional Goals and Design Principles of CPE

Reply Threaded

In reply to this post by Thomas R. Jones

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

-----Original Message-----
From: Thomas R. Jones [[hidden email]]

It seems that entities, both commercial and open source, should alter developmental requirements and implementations to accommodate the language structure. Not the other way around.

Thomas

I'm in agreement with cavaets, the solution must be rigorous (I'm a mathematician by training) and implementable with a reasonable effort. The FOUNDATION of CPE, OVAL etc is Home Land Security --- which means that it must be practical to implement. More importantly, it must be practical to implement in a reasonable time frame -- right now, I want CPE to be building it's first expanding repository by OVAL Dev Days, if not, there are DOD customers (of us and others) that are going to be in a major pinch come 2008. Hence, my volunteering of writing a proof of concept of a merger of the two approaches --- the formal naming method and an numeric enumeration. With an "open to authorized folks" create your own website if none exists, else lookup what it should be...(including via web services, so there can be real simple intregation with vendor tools).

Trying out a proof of concept is much better than abstract discussions.

Ken Lassesen,
HomeOffice: 360-297-4717 Cell: 360-509-2402 Fax: 928-832-6836
IM: [hidden email] [hidden email]
[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain confidential and privileged information and is intended only for use by the individual(s) or entity(ies) to whom it was addressed. Any unauthorized review, use, disclosure, or distribution of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and permanently delete and destroy the original message.

-----Original Message-----
From: Thomas R. Jones [[hidden email]]

It seems that entities, both commercial and open source, should alter developmental requirements and implementations to accommodate the language structure. Not the other way around.

Thomas