CPE 2.0 draft specification

[Andrew Buttner]

Attached is a cleaned up version of the 2.0 draft.  This draft was
based on the conversations had during the conference call on June 7th.
If you have time over the next week, please read through the draft and
forward any comments to the list.  We will be having another conference
call the last week of July to discuss this spec and more specifically
the CPE Language section.

As has been mentioned before, CPE is a key piece in our automation
puzzle and we need to make sure we get it right.  We really need to
leverage the entire community here so please take a look at the draft
and think about how it might relate to your work, and how it could
further be improved.

Our goal is to have 2.0 wrapped up (and the official dictionary
released) by the SCAP conference in mid September.

Thanks
Drew


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Dick_Whitehurst]

I would like to suggest that the vendor component be removed from the
CPE name format.  

My rationale is based on a number of considerations:
1.  The name should be immutable and the vendor component is susceptible
to change.
2.  The product should component should uniquely identify the product
without a vendor component.
3. Vendor has been a contentious issue, especially when dealing with
open source software.

While knowing the vendor of a particular product can be useful in many
situations, it is not particularly useful or necessary in the context of
this enumeration.  A separate map or library could be built by those
with interest in, or need of, this type of mapping.

I hope the community will give serious consideration to this suggestion.

Thanks,
Dick Whitehurst
McAfee, Inc


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, July 20, 2007 8:40 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

Attached is a cleaned up version of the 2.0 draft.  This draft was based
on the conversations had during the conference call on June 7th.
If you have time over the next week, please read through the draft and
forward any comments to the list.  We will be having another conference
call the last week of July to discuss this spec and more specifically
the CPE Language section.

As has been mentioned before, CPE is a key piece in our automation
puzzle and we need to make sure we get it right.  We really need to
leverage the entire community here so please take a look at the draft
and think about how it might relate to your work, and how it could
further be improved.

Our goal is to have 2.0 wrapped up (and the official dictionary
released) by the SCAP conference in mid September.

Thanks
Drew


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Ben Greenbaum]

Hi all,

I just joined this list, so I apologize for the late entry into this
process. By way of introduction, I manage the DeepSight research teams
here at Symantec, which includes (among other things) overseeing
maintenance and development of our database of platforms, products etc.

On the topic of vendor name inclusion in the spec, I believe that is an
important feature for the simple reason that many software packages from
different vendors share the same name, and the vendor's name becomes the
primary method of differentiation.

Quick example: We have 35 software packages named 'guestbook', by 35
different vendors. Also 13 different products called simply 'FTP
Server', 12 named 'forum', etc. Aside from including the vendor, does
the CPE address a means of uniquely identifying these cases? (If it
does, my apologies, I'm new...)

Thank you,
Ben Greenbaum
Symantec

-----Original Message-----
From: Dick Whitehurst [mailto:[hidden email]]
Sent: Friday, July 20, 2007 9:08 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

I would like to suggest that the vendor component be removed from the
CPE name format.  

My rationale is based on a number of considerations:
1.  The name should be immutable and the vendor component is susceptible
to change.
2.  The product should component should uniquely identify the product
without a vendor component.
3. Vendor has been a contentious issue, especially when dealing with
open source software.

While knowing the vendor of a particular product can be useful in many
situations, it is not particularly useful or necessary in the context of
this enumeration.  A separate map or library could be built by those
with interest in, or need of, this type of mapping.

I hope the community will give serious consideration to this suggestion.

Thanks,
Dick Whitehurst
McAfee, Inc


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, July 20, 2007 8:40 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

Attached is a cleaned up version of the 2.0 draft.  This draft was based
on the conversations had during the conference call on June 7th.
If you have time over the next week, please read through the draft and
forward any comments to the list.  We will be having another conference
call the last week of July to discuss this spec and more specifically
the CPE Language section.

As has been mentioned before, CPE is a key piece in our automation
puzzle and we need to make sure we get it right.  We really need to
leverage the entire community here so please take a look at the draft
and think about how it might relate to your work, and how it could
further be improved.

Our goal is to have 2.0 wrapped up (and the official dictionary
released) by the SCAP conference in mid September.

Thanks
Drew


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Ken Lassesen-2]

I've been chewing over a bit for the last few days, trying to come up
with a orthogonal approach to some of the current dilemna and issues
(aka lateral thinking) -- and I would agree:
* The company name should be eliminated from the identifier
* The company name(s) and product name(s) should be in the metadata.

This means that as a company is passed thru various companies (or
licensed to and rebranded by other companies) there is the ability to
identify it host of identities; and we have independence from the
ownership issues in the identifier.

The issue remains, how to differentiate  four score and eight products
with the same short name? Assuming a central repository somewhere (with
community authoring -- Wiki model) then it should be just serialization:

* server:internet:ftp:10232
Or
* wordprocessor:3823
* spreadsheet:3823
* spreadsheet:3823
* compression:3823
* viewer:3942
* misc:3874

This assumes that CPE is issued as Xml -- with the above being
identifiers.

Versions could be designated as either by version number
* server:internet:ftp:10232:4.3.4.2
Or by issue date (highest file time stamp date on the distributable).
* server:internet:ftp:10232:2001-01-12

I realize that this is a change of direction from the current trend, but
it seems to be balanced against the many issues....

Ken Lassesen,
Office 206-734-4718 Home: 360-297-4717   Cell: 360-509-2402  Skype:
Ken.Lassesen
IM: [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: Ben Greenbaum [mailto:[hidden email]]
Sent: Friday, July 20, 2007 1:38 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

Hi all,

I just joined this list, so I apologize for the late entry into this
process. By way of introduction, I manage the DeepSight research teams
here at Symantec, which includes (among other things) overseeing
maintenance and development of our database of platforms, products etc.

On the topic of vendor name inclusion in the spec, I believe that is an
important feature for the simple reason that many software packages from
different vendors share the same name, and the vendor's name becomes the
primary method of differentiation.

Quick example: We have 35 software packages named 'guestbook', by 35
different vendors. Also 13 different products called simply 'FTP
Server', 12 named 'forum', etc. Aside from including the vendor, does
the CPE address a means of uniquely identifying these cases? (If it
does, my apologies, I'm new...)

Thank you,
Ben Greenbaum
Symantec

-----Original Message-----
From: Dick Whitehurst [mailto:[hidden email]]
Sent: Friday, July 20, 2007 9:08 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

I would like to suggest that the vendor component be removed from the
CPE name format.  

My rationale is based on a number of considerations:
1.  The name should be immutable and the vendor component is susceptible
to change.
2.  The product should component should uniquely identify the product
without a vendor component.
3. Vendor has been a contentious issue, especially when dealing with
open source software.

While knowing the vendor of a particular product can be useful in many
situations, it is not particularly useful or necessary in the context of
this enumeration.  A separate map or library could be built by those
with interest in, or need of, this type of mapping.

I hope the community will give serious consideration to this suggestion.

Thanks,
Dick Whitehurst
McAfee, Inc


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Friday, July 20, 2007 8:40 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

Attached is a cleaned up version of the 2.0 draft.  This draft was based
on the conversations had during the conference call on June 7th.
If you have time over the next week, please read through the draft and
forward any comments to the list.  We will be having another conference
call the last week of July to discuss this spec and more specifically
the CPE Language section.

As has been mentioned before, CPE is a key piece in our automation
puzzle and we need to make sure we get it right.  We really need to
leverage the entire community here so please take a look at the draft
and think about how it might relate to your work, and how it could
further be improved.

Our goal is to have 2.0 wrapped up (and the official dictionary
released) by the SCAP conference in mid September.

Thanks
Drew


---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Thomas R. Jones]

On Fri, 2007-07-20 at 10:07 -0500, Dick Whitehurst wrote:
> I would like to suggest that the vendor component be removed from the
> CPE name format. =20
I would like to submit my suggestion against this avenue of approach to
the 2.0 specification. The reasoning is annotated below:
>=20
> My rationale is based on a number of considerations:
> 1.  The name should be immutable and the vendor component is susceptible
> to change.
This is true -- it is susceptible to change. But on the same note, so is
the product name.
> 2.  The product should component should uniquely identify the product
> without a vendor component.
This is next to impossible without a mapping implementation. There have
been a great multitude of discussions with regards to this topic. Please
see the mailinglist archives for applicable reference. As well as the
following annotation.
> 3. Vendor has been a contentious issue, especially when dealing with
> open source software.
This is not the situation. For instance, I have been constructing a CPE
dictionary for the past 12 months of ALL the packages for some ten(10)
different distributions released by Novell --- currently some 10,000+
CPE definitions ready for release into the community.=20

A great majority of these packages --- approximately 85% --- are
developed by open source communities. However, the authoritative object
(e.g. vendor) for all of them is Novell. They customize, compile and
distribute the product. They are the authoritative entity. Due to the
fact that the same products may also be compiled and distributed by
Redhat(among many others) --- in essence the same application has two(2)
or more authoritative entities. They are not the same though and must be
explicitly referenced as different.

By removing the authoritative entity, we greatly increase the
administrative overhead of the CPE; without any substantial gain in ROI.
The amount of work and human-hours needed to administer a mapping scheme
due to the removal of "vendor" will far outweigh the work and hours
needed by administrators to revise the CPE definitions for a few changes
to the authoritative entity.

Just my 2 cents.

Cheers.
Thomas R. Jones

[Dick_Whitehurst]

I guess maybe I don't understand what the objective of the CPE project
is.  I thought it was a technique for associating software existence
with various OVAL definitions or XCCDF rules, i.e., a means of
determining applicability of checks and rules in audits.  In this case,
the importance of immutability seems high, and being able to include the
vendor in the *NAME*, as opposed to the *METADATA*, seems to be of less
value.  In my view, the second most important feature is the ability to
associate the CPE name with check which can be used to determine whether
the CPE identified NAME is applicable to the system in question.

If my understanding of the intended use of CPE is incorrect, please help
clarify.

Thanks,
Dick

-----Original Message-----
From: Thomas R. Jones [mailto:[hidden email]]
Sent: Saturday, July 21, 2007 7:59 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

On Fri, 2007-07-20 at 10:07 -0500, Dick Whitehurst wrote:
> I would like to suggest that the vendor component be removed from the
> CPE name format.
I would like to submit my suggestion against this avenue of approach to
the 2.0 specification. The reasoning is annotated below:
>
> My rationale is based on a number of considerations:
> 1.  The name should be immutable and the vendor component is
> susceptible to change.
This is true -- it is susceptible to change. But on the same note, so is
the product name.
> 2.  The product should component should uniquely identify the product
> without a vendor component.
This is next to impossible without a mapping implementation. There have
been a great multitude of discussions with regards to this topic. Please
see the mailinglist archives for applicable reference. As well as the
following annotation.
> 3. Vendor has been a contentious issue, especially when dealing with
> open source software.
This is not the situation. For instance, I have been constructing a CPE
dictionary for the past 12 months of ALL the packages for some ten(10)
different distributions released by Novell --- currently some 10,000+
CPE definitions ready for release into the community.

A great majority of these packages --- approximately 85% --- are
developed by open source communities. However, the authoritative object
(e.g. vendor) for all of them is Novell. They customize, compile and
distribute the product. They are the authoritative entity. Due to the
fact that the same products may also be compiled and distributed by
Redhat(among many others) --- in essence the same application has two(2)
or more authoritative entities. They are not the same though and must be
explicitly referenced as different.

By removing the authoritative entity, we greatly increase the
administrative overhead of the CPE; without any substantial gain in ROI.
The amount of work and human-hours needed to administer a mapping scheme
due to the removal of "vendor" will far outweigh the work and hours
needed by administrators to revise the CPE definitions for a few changes
to the authoritative entity.

Just my 2 cents.

Cheers.
Thomas R. Jones

[Andrew Buttner]

>I guess maybe I don't understand what the objective of the CPE project
>is.  I thought it was a technique for associating software existence
>with various OVAL definitions or XCCDF rules, i.e., a means of
>determining applicability of checks and rules in audits.

The main objective of CPE is to provide a unique identifier for
different platform types, thus allowing two different tools to exchange
data with an understanding about what the other is talking about.  Part
of providing a unique identifier is giving a map to what it is that
identifier points to.  This is accomplished via a provided OVAL
Definition.  In other words, the CPE identifies a platform such that a
given OVAL Definition will return true.

The structure of the CPE Name was created in an effort to allow CPE
Names to be created by the community (without having to rely on MITRE
to assign an id number) and also to allow matching to occur between
names at different levels of abstraction.


>In this case,
>the importance of immutability seems high, and being able to
>include the
>vendor in the *NAME*, as opposed to the *METADATA*, seems to be of
less
>value.

Again the reason vendor is in there is provide some structured format
for creating names that will result in a unique name.  Ideally we would
like the name format to be something that is deterministic (i.e. two
individuals will come up with the same name).  I've heard some opinions
that Vendor is needed to uniquely id a platform.  Any different ideas
on how to accomplish this without using the vendor name?  For example,
how to name "FTP Server" that offered by 3 different vendors?


>In my view, the second most important feature is the ability to
>associate the CPE name with check which can be used to
>determine whether
>the CPE identified NAME is applicable to the system in question.

Yes


Thanks
Drew

[Kent_Landfield]

Drew writes:
> Again the reason vendor is in there is provide some structured format
> for creating names that will result in a unique name.  Ideally we
would
> like the name format to be something that is deterministic (i.e. two
> individuals will come up with the same name).  

I think this 'ideal' is getting in the way of finding a solution.

>                                              I've heard some opinions
> that Vendor is needed to uniquely id a platform.  Any different ideas
> on how to accomplish this without using the vendor name?  For example,
> how to name "FTP Server" that offered by 3 different vendors?

So vendors have products that have the same trademarked name? Commercial
vendors are *very* careful to protect and brand their product names.
The only way this name is used in three different products is if it is a
non-commercial tool.  Otherwise I'd like to see commercial examples. So
are we back to the open-source issue?

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

[Banghart, John]

iPhone (Linksys and Apple) is one example.  I'm sure there are others, although I'm willing to concede that examples in the commercial space are probably small.
 
 
 
---
John Banghart, CISSP
Associate
Booz | Allen | Hamilton
Tel [phone]
[hidden email]

________________________________

From: Kent Landfield [mailto:[hidden email]]
Sent: Mon 7/23/2007 3:05 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification



Drew writes:
> Again the reason vendor is in there is provide some structured format
> for creating names that will result in a unique name.  Ideally we
would
> like the name format to be something that is deterministic (i.e. two
> individuals will come up with the same name).

I think this 'ideal' is getting in the way of finding a solution.

>                                              I've heard some opinions
> that Vendor is needed to uniquely id a platform.  Any different ideas
> on how to accomplish this without using the vendor name?  For example,
> how to name "FTP Server" that offered by 3 different vendors?

So vendors have products that have the same trademarked name? Commercial
vendors are *very* careful to protect and brand their product names.
The only way this name is used in three different products is if it is a
non-commercial tool.  Otherwise I'd like to see commercial examples. So
are we back to the open-source issue?

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

[Ken Lassesen-2]

Is there a strong reason that a Wiki-ish approach (community definition
via a central repository) instead of an authority (Mitre) is not on the
table.

By this, I mean there is a central repository (hosted at Mitre). There
are also 'recording agents' that can add new numbers (serialized) to
this repository on demand. The entry screen provides sufficient
information to reduce the risk of duplicates to a low level AND also
provide sufficient information to create an OVAL test (with
assuredness="1" , see my post on the OVAL-Dev list for more
information).

Example:
        To define the CPE, you must upload at least one file from the
product [which could then be automatically parsed and compared to other
known entries]. After a person has submitted this preliminary
information, a list of alternative candidates appear and the agent
either picks on of those INSTEAD or clicks  "NEW CPE" and it is created.
This would address the following issues:
* No reliance on MITRE, except for providing hardware and possibly
software (if they are to provide an IIS box, I can likely write and
donate the software)
* Eliminate vendor name dependency
* Restricts the creations to recording agents (which MITRE will control,
with likely 2+ per active company)
* Immediate turn around
* Pre-generation of OVAL tests (with assuredness of 0-1).

Comments?

"The structure of the CPE Name was created in an effort to allow CPE
Names to be created by the community (without having to rely on MITRE to
assign an id number) and also to allow matching to occur between names
at different levels of abstraction."




Thanks
Drew

[Dick_Whitehurst]

Thomas,

        I'd guess you have an automated system for generating all those
10,000 + definitions?  Can you help me understand the greatly increased
administrative overhead that will result from using unique product
names?  

Also, can you point me to the CPE mail archives?  I haven't found them
yet, though I did look for them when I signed up for this list.  I
suspect it's hiding in plain sight, but I just haven't found it.

Thanks,
Dick



-----Original Message-----
From: Thomas R. Jones [mailto:[hidden email]]
Sent: Saturday, July 21, 2007 7:59 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification

On Fri, 2007-07-20 at 10:07 -0500, Dick Whitehurst wrote:
> I would like to suggest that the vendor component be removed from the
> CPE name format.
I would like to submit my suggestion against this avenue of approach to
the 2.0 specification. The reasoning is annotated below:
>
> My rationale is based on a number of considerations:
> 1.  The name should be immutable and the vendor component is
> susceptible to change.
This is true -- it is susceptible to change. But on the same note, so is
the product name.
> 2.  The product should component should uniquely identify the product
> without a vendor component.
This is next to impossible without a mapping implementation. There have
been a great multitude of discussions with regards to this topic. Please
see the mailinglist archives for applicable reference. As well as the
following annotation.
> 3. Vendor has been a contentious issue, especially when dealing with
> open source software.
This is not the situation. For instance, I have been constructing a CPE
dictionary for the past 12 months of ALL the packages for some ten(10)
different distributions released by Novell --- currently some 10,000+
CPE definitions ready for release into the community.

A great majority of these packages --- approximately 85% --- are
developed by open source communities. However, the authoritative object
(e.g. vendor) for all of them is Novell. They customize, compile and
distribute the product. They are the authoritative entity. Due to the
fact that the same products may also be compiled and distributed by
Redhat(among many others) --- in essence the same application has two(2)
or more authoritative entities. They are not the same though and must be
explicitly referenced as different.

By removing the authoritative entity, we greatly increase the
administrative overhead of the CPE; without any substantial gain in ROI.
The amount of work and human-hours needed to administer a mapping scheme
due to the removal of "vendor" will far outweigh the work and hours
needed by administrators to revise the CPE definitions for a few changes
to the authoritative entity.

Just my 2 cents.

Cheers.
Thomas R. Jones

[Thomas R. Jones]

On Mon, 2007-07-23 at 17:11 -0500, Dick Whitehurst wrote:
> Thomas,
>
> I'd guess you have an automated system for generating all those
> 10,000 + definitions?  
Most certainly. I have been working with the OVAL community to develop
definitions for the Novell platforms and products.  I decided that
during this time, that I may be able to also help the CPE community and
chose to also construct tools and scripts to help develop a
comprehensive and concise CPE dictionary based on the data and
information that I have on hand.
> Can you help me understand the greatly increased
> administrative overhead that will result from using unique product
> names?  
Sure. I guess I should have been more descriptive in previous
communications. The following data is rudimentary but should suffice for
our means at this time:

The data design of the CPE structure must be taken into consideration.
In order to properly take all design issues into consideration we must
utilize common software development life cycle(SDLC) developmental
strategies. Agreed? The following concepts are common to all SDLC
strategies and are internationally accepted as true.

The use of a database system as opposed to a file processing system
offers much greater flexibility and efficiency. By implementing a
mapping scheme we no longer utilize a singular database system but must
rely on data from a file processing system. I think that all community
members are in agreement with this notion. I am not a commercial
developer as many of the members of the community are; rather I am an
open source developer. But I utilize developmental strategies
much the same as commercial entities. Based on this notion if one were
to develop a context diagram and a level 0 diagram for the CPE system,
it should show that by removing the authoritative object we introduce a
second process into the CPE system --- a unique number processing
system. In this example, we have a few issues already:

1.) We now have two processes that must be executed to utilize our CPE
system.
2.) Depending on the data design utilized, there will be no less than
two(2) items of information that must be duplicated in both the CPE
system and the unique number system. We now introduce data redundancy.
Data redundancy meaning a portion of data that is common to two or more
process system. By design this requires more space; and the maintenance
and updating of the data in several locations is expensive.
3.) By implementing data redundancy, we also inherently introduce data
integrity issues. This may happen if updates are not applied to each
data store during a singular execution of the CPE system. Changing the
data in only one system will cause inconsistent data and result in
incorrect information in the second system. In the case of the CPE
system, this results in exponential inconsistency.
4.) By using a unique number system, we must then develop a rigid data
structure for the environment. This may be local or network oriented
depending on use. We must specify another explicit location that must be
utilized to retrieve the mapping of number to product and/or platform
object.
5.) By implementing a unique number system we also must develop
supplementary types of files:
 * Master file - a data store with relatively permanent data about an
platform and/or product. The original CPE system data store.
* Table file - a data store that is used by the CPE system. The unique
number system data store.
* Transaction file - utilized by administrators to update the master
file.
* Security file - created for backup and recovery for both systems.
* History file - utilized for historical or archival purposes. We must
ensure that every transaction may be backed out of the CPE system.

Again this is rudimentary. This is high-level review of the proposed
system and just barely scratches the surface of the developmental
requirements. I would have no problems with performing comprehensive
system analysis and design of the CPE system; unfortunately though given
time constraints, we don't seem to have the necessary time. If we in
fact do, I would present my time and effort to properly document and
develop the CPE system utilizing the proper amount of SDLC strategies.

Cheers.
Thomas R. Jones

On Mon, 2007-07-23 at 17:11 -0500, Dick Whitehurst wrote:=20
> Thomas,
>=20
> I'd guess you have an automated system for generating all those
> 10,000 + definitions? =20
Most certainly. I have been working with the OVAL community to develop
definitions for the Novell platforms and products.  I decided that
during this time, that I may be able to also help the CPE community and
chose to also construct tools and scripts to help develop a
comprehensive and concise CPE dictionary based on the data and
information that I have on hand.=20
> Can you help me understand the greatly increased
> administrative overhead that will result from using unique product
> names? =20
Sure. I guess I should have been more descriptive in previous
communications. The following data is rudimentary but should suffice for
our means at this time:

The data design of the CPE structure must be taken into consideration.
In order to properly take all design issues into consideration we must
utilize common software development life cycle(SDLC) developmental
strategies. Agreed? The following concepts are common to all SDLC
strategies and are internationally accepted as true.

The use of a database system as opposed to a file processing system
offers much greater flexibility and efficiency. By implementing a
mapping scheme we no longer utilize a singular database system but must
rely on data from a file processing system. I think that all community
members are in agreement with this notion. I am not a commercial
developer as many of the members of the community are; rather I am an
open source developer. But I utilize developmental strategies=20
much the same as commercial entities. Based on this notion if one were
to develop a context diagram and a level 0 diagram for the CPE system,
it should show that by removing the authoritative object we introduce a
second process into the CPE system --- a unique number processing
system. In this example, we have a few issues already:

1.) We now have two processes that must be executed to utilize our CPE
system.
2.) Depending on the data design utilized, there will be no less than
two(2) items of information that must be duplicated in both the CPE
system and the unique number system. We now introduce data redundancy.
Data redundancy meaning a portion of data that is common to two or more
process system. By design this requires more space; and the maintenance
and updating of the data in several locations is expensive.
3.) By implementing data redundancy, we also inherently introduce data
integrity issues. This may happen if updates are not applied to each
data store during a singular execution of the CPE system. Changing the
data in only one system will cause inconsistent data and result in
incorrect information in the second system. In the case of the CPE
system, this results in exponential inconsistency.
4.) By using a unique number system, we must then develop a rigid data
structure for the environment. This may be local or network oriented
depending on use. We must specify another explicit location that must be
utilized to retrieve the mapping of number to product and/or platform
object.
5.) By implementing a unique number system we also must develop
supplementary types of files:
 * Master file - a data store with relatively permanent data about an
platform and/or product. The original CPE system data store.
* Table file - a data store that is used by the CPE system. The unique
number system data store.
* Transaction file - utilized by administrators to update the master
file.
* Security file - created for backup and recovery for both systems.
* History file - utilized for historical or archival purposes. We must
ensure that every transaction may be backed out of the CPE system.

Again this is rudimentary. This is high-level review of the proposed
system and just barely scratches the surface of the developmental
requirements. I would have no problems with performing comprehensive
system analysis and design of the CPE system; unfortunately though given
time constraints, we don't seem to have the necessary time. If we in
fact do, I would present my time and effort to properly document and
develop the CPE system utilizing the proper amount of SDLC strategies.

Cheers.
Thomas R. Jones

[Andrew Buttner]

In essence this is what we are after.  We would like a dictionary that
certain community members (primary source vendors) can submit name to
and these submissions would be added automatically.  I think the
implementation of this is separate from the discussion about the name
format.  This is probably something we will tackle once we have
solidified the spec.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Monday, July 23, 2007 3:52 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft specification
>
>Is there a strong reason that a Wiki-ish approach (community
definition
>via a central repository) instead of an authority (Mitre) is not on
the

>table.
>
>By this, I mean there is a central repository (hosted at Mitre). There
>are also 'recording agents' that can add new numbers (serialized) to
>this repository on demand. The entry screen provides sufficient
>information to reduce the risk of duplicates to a low level AND also
>provide sufficient information to create an OVAL test (with
>assuredness="1" , see my post on the OVAL-Dev list for more
>information).
>
>Example:
> To define the CPE, you must upload at least one file from the
>product [which could then be automatically parsed and compared to

other

>known entries]. After a person has submitted this preliminary
>information, a list of alternative candidates appear and the agent
>either picks on of those INSTEAD or clicks  "NEW CPE" and it
>is created.
>This would address the following issues:
>* No reliance on MITRE, except for providing hardware and possibly
>software (if they are to provide an IIS box, I can likely write and
>donate the software)
>* Eliminate vendor name dependency
>* Restricts the creations to recording agents (which MITRE
>will control,
>with likely 2+ per active company)
>* Immediate turn around
>* Pre-generation of OVAL tests (with assuredness of 0-1).
>
>Comments?
>
>"The structure of the CPE Name was created in an effort to allow CPE
>Names to be created by the community (without having to rely
>on MITRE to
>assign an id number) and also to allow matching to occur between names
>at different levels of abstraction."
>
>
>
>
>Thanks
>Drew
>

[Andrew Buttner]

>Also, can you point me to the CPE mail archives?  I haven't found them
>yet, though I did look for them when I signed up for this list.  I
>suspect it's hiding in plain sight, but I just haven't found it.

CPE mail archives are not available as of yet through the web site.  I
think if you are a listsrv power user you can fetch them from the
server, but the exact commands are escaping me right now.  Hopefully in
the future we can get the archives up on the website.

Thanks
Drew

[Tim Keanini Sr.]

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

[information from the listserv process]

You can get a list   of   the   available   archive  files   by   sending   an   "INDEX CPE-DISCUSSION-LIST"  command to  [hidden email]. You  can then order these  files with a  "GET CPE-DISCUSSION-LIST LOGxxxx"  command, or

using  LISTSERV's database  search  facilities. Send  an "INFO  DATABASE" command for more information on the latter.

On Jul 25, 2007, at 12:53 PM, Buttner, Drew wrote:

Also, can you point me to the CPE mail archives?  I haven't found them

yet, though I did look for them when I signed up for this list.  I

suspect it's hiding in plain sight, but I just haven't found it.

CPE mail archives are not available as of yet through the web site.  I

think if you are a listsrv power user you can fetch them from the

server, but the exact commands are escaping me right now.  Hopefully in

the future we can get the archives up on the website.

Thanks

Drew

--

Timothy 'TK' Keanini. CTO

101 Second Street, Suite 400

San Francisco, CA  94105

Office: [phone]

Mobile: [phone]

Fax: [phone]

http://www.ncircle.com/

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