From my efforts to map our existing names in the Army asset database to the
names in the NVD, it's becoming clear that even the three part types we have
now are difficult to manage. For example, the NVD treats printers as
hardware, but the Army uses the identical name to refer to the OS/firmware
on the hardware platform. The vulnerabilities are the same, but using the
existing part types you wouldn't discover them because they generate
different CPEs.
I see the proposal to more than double the part types as a change that would
make mapping almost infeasible.
I'm also concerned that we don't actually fix the problems by continually
adding new part types.
I would like to make a counter-proposal that we keep the part types to a
bare minimum. We should be able to talk about things that execute,
hardware, operating systems, and data. Solving the run-time and
virtualization problem (in my opinion) would be better solved by specifying
sub-parts that can specify target software environment and target hardware
environment. This allows us to deal with drivers, macros, plug-ins, runtime
environments, and virtualization platforms all as applications/executables.
As an illustration, I have, on my desktop, a java application (Eclipse),
that uses a plugin (Hypermodel), a data library (XML schema data types) and
runs on a runtime environment (JRE), on Windows 2000. Rather than having to
define a part type for plugin, application, runtime environment, in addition
to data structure and OS, I would prefer to treat them as executables with a
target CPE software environment. I can now describe the relationships by
using the CPE language to "and" together the following:
cpe://d::xml_schema_data_types target_sw_environment=cpe://a::hypermodel
cpe://a::hypermodel target_sw_environment=cpe://a:open_source:eclipse
cpe://a:open_source:eclipse target_sw_environment=cpe://a:sun:jre
cpe://a:sun:jre target_sw_environment=cpe://o:microsoft:windows_2000
cpe://o:microsoft:windows_2000
target_hw_environment=cpe://h:HP_Compaq:dc7100
This sort of naming would also apply to macros, virtualization engines, and
most other executables.
I don't have any real use cases why you would ever want to specify to this
level of detail, but I think this is a more flexible way of describing my
environment than having a continually expanding list of part types. With a
little thought, we can probably also fix the x64/x32/i386 target hardware
descriptions that litter the existing CPE names. I would advocate for
adding the "target SW" and "target HW" environment specs as CPE subparts or
appended metadata.
The fact that we haven't discussed this alternative or any others and are
forced to consider only one is why I fully support the statement that "the
new parts (especially the runtime and virtualization parts) have not been
fully thought out and this may not be the best way to enumerate these types
of platform pieces."
I would like to second Dave's request that we focus on necessary corrections
and clarifications in the CPE specification and dictionary schema. Fixing
the major issues the introduction of new part types addresses should wait
for a major revision.
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: Thursday, November 29, 2007 8:35 AM
To:
[hidden email]
Subject: [CPE-DISCUSSION-LIST] additional part components
There has been some push back regarding adding new part components at
this time. Version 2.0 called out:
h = hardware part
o = operating system part
a = application part
It was proposed that Version 2.1 add:
r = runtime environment part
l = library part
d = driver part
v = virtualization part
I think the two concerns have been raised. The first is that the
addition of these parts are too big of a change for a minor release.
The basis for this concern comes from the possibility that current CPE
Names that might have used the Application Part would have to be
changed to use some of the new parts.
The other concern is that the new parts (especially the runtime and
virtualization parts) have not been fully thought out and this may not
be the best way to enumerate these types of platform pieces.
I'd be interested in hearing additional comments about these concerns
as well as hearing support for the change if it is out there. I'd like
to get Version 2.1 finished so we can fix the bug in the schema that
was presented.
Thanks
Drew
---------
Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
