Quantcast

Product architecture

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Product architecture

Aharon
Forgive me if this has been hashed through numerous times before. Does CPE (including 2.3) support architecture? For example, is there a way for me to communicate Chrome 32 bit versus Chrome 64bit in WFN or URI formatting? Or maybe there is an alternative method that I am unaware of?

Aharon

DTCC Confidential (Yellow)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173
<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Product architecture

Brant Cheikes
Aharon,

It's a good question and in fact hasn't been hashed thru much before--so
I'll take this opportunity to comment on this at some length.

In CPE 2.2 usage, architecture-related information has traditionally been
coded into the "edition" component of the CPE name, the 6th component of the
CPE URI (ignoring the leading "cpe:/").  Here are three examples:

cpe:/a:aprelium:abyss_web_server_x1:2.3.2:-:win32 ("win32" is the edition)
cpe:/a:ca:brightstor_arcserve_backup:::tru64 ("tru64" is the edition)
cpe:/a:microsoft:exchange_server:2010:-:x64 ("x64" is the edition)

The problem has been that, historically, we've also dumped a lot of other
non-architecture but edition-related information into the "edition"
component, and done so inconsistently, e.g.,

cpe:/a:hp:insight_diagnostics:7.8.0.2257:unknown:online_windows_server_2003_
x64
cpe:/o:microsoft:windows_2003_server::r2:x64-enterprise
cpe:/o:microsoft:windows_server_2008:-:sp1:enterprise_x64
cpe:/o:microsoft:windows_xp:-:gold:64-bit-2003
cpe:/o:redhat:enterprise_linux:2.1::ia64-es

All this is a natural outgrowth of a dictionary maintenance process that
depends heavily on human judgment and attention to (or failure of attention
to) precedent.

Recognizing that the CPE 2.2 "edition" component had become a bit of a
dumping ground, while designing CPE 2.3 we decided to try to explicitly
break out three fundamentally different kinds of information into separate
fields.  We decided that there was some "core" notion of edition as
reflected in terms like "Professional", "Home and Basic", "Enterprise", etc.
Separately, there was "architecture/hardware" information as reflected in
terms like "x64", "win32", "sparc", etc.  And finally there was some amount
of "target platform/software" information, as reflected in terms like
"Windows Server 2003", "HPUX", "Solaris", etc.  That is, we came to view the
CPE 2.2 "edition" component as a place where, over time, we had come to
encode three distinctly different kinds of information, and in the process
had failed to standardize where or how within the component value these
items should be encoded.

In CPE 2.3, we have defined three separate attributes: sw_edition, target_hw
and target_sw.  For backward compatibility with CPE 2.2 we retained an
"edition" attribute purely to enable pre-existing (i.e., pre-2.3) CPE names
to be mechanically translated to CPE 2.3 without requiring human review.
(By default, whatever value appears in the "edition" component of a CPE 2.2
URI will be copied to the edition attribute of a CPE 2.3 name.  But for new
names created under the rules of CPE 2.3, we've allowed the three different
types of edition-related information to be broken out separately.  Below are
examples of how the names shown above could appear as CPE 2.3 formatted
strings:

cpe:2.3:a:hp:insight_diagnostics:7.8.0.2257:unknown:-:-:online:windows_serve
r_2003:x64:-
cpe:2.3:o:microsoft:windows_2003_server::r2:-:-:enterprise:-:x64:-
cpe:23:o:microsoft:windows_server_2008:-:sp1:-:-:enterprise:-x64:-
cpe:2.3:o:microsoft:windows_xp:-:gold:-:-:2003:-:x64:-
cpe:2.3:o:redhat:enterprise_linux:2.1::-:-:es:-:ia64:-

The last four fields in the above names are: <sw_edition> : <target_sw> :
<target_hw> : <other>.  I've taken some liberties in the examples, such as
conventionally filling the "legacy edition" (6th, ignoring "cpe:2.3:") field
with a hyphen, but I think you get the idea.

So the long answer to your question is:

* CPE 2.2 supports architecture in the sense that you can just dump that
information into the edition field in the CPE 2.2 URI (the 6th field
ignoring "cpe:/").  But there really aren't any guidelines on how to do that
properly.
* CPE 2.3 supports architecture explicitly in that we give you the target_hw
attribute expressly for that purpose.

Ultimately, for such architecture support to be meaningful and useful, we
need to normalize this information across all CPE names--to prevent, e.g.,
"x64" used for target_hw in one name and "64bit" in another, etc.  The CPE
2.3 Naming specification says (cf. Section 5.3.3.9), "Values for [target_hw]
SHOULD be selected from an attribute-specific valid-values list, which MAY
be defined by other specifications that utilize this specification."  NIST,
as maintainer of the Official CPE Dictionary, has the task of defining the
process to be used to establish and maintain this valid-values list, as part
of their roll-out of the CPE 2.3 Dictionary.

I hope this message, despite its length, satisfactorily answered your
question.

Cheers,
/Brant

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


-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Wednesday, December 21, 2011 4:11 PM
To: cpe-discussion-list CPE Community Forum
Subject: [CPE-DISCUSSION-LIST] Product architecture

Forgive me if this has been hashed through numerous times before. Does CPE
(including 2.3) support architecture? For example, is there a way for me to
communicate Chrome 32 bit versus Chrome 64bit in WFN or URI formatting? Or
maybe there is an alternative method that I am unaware of?

Aharon

DTCC Confidential (Yellow)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173
<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

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

Re: Product architecture

Aharon
Brant, thanks for the reply. I understand both use cases now, and the 2.3 target_hw seems appropriate. Hopefully, whoever is creating the acceptable CPE 2.3 taxonomy for the target_hw field at NIST is also taking into account other aspects of processor architecture like sparc_x64, arm_x32, etc. It does seem like we are asking a lot from this field though. If you look at your example:

cpe:2.3:o:microsoft:windows_2003_server::r2:-:-:enterprise:-:x64:-

All of the fields represent a single piece of meta data about this product. If we change the target_hw to ia_x64, I believe this to be two pieces of meta data. The processor type and processor architecture. I don't feel strongly about this, but it was something I noticed.

Aharon


DTCC Confidential (Yellow)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173


-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, December 21, 2011 5:04 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Product architecture

Aharon,

It's a good question and in fact hasn't been hashed thru much before--so
I'll take this opportunity to comment on this at some length.

In CPE 2.2 usage, architecture-related information has traditionally been
coded into the "edition" component of the CPE name, the 6th component of the
CPE URI (ignoring the leading "cpe:/").  Here are three examples:

cpe:/a:aprelium:abyss_web_server_x1:2.3.2:-:win32 ("win32" is the edition)
cpe:/a:ca:brightstor_arcserve_backup:::tru64 ("tru64" is the edition)
cpe:/a:microsoft:exchange_server:2010:-:x64 ("x64" is the edition)

The problem has been that, historically, we've also dumped a lot of other
non-architecture but edition-related information into the "edition"
component, and done so inconsistently, e.g.,

cpe:/a:hp:insight_diagnostics:7.8.0.2257:unknown:online_windows_server_2003_
x64
cpe:/o:microsoft:windows_2003_server::r2:x64-enterprise
cpe:/o:microsoft:windows_server_2008:-:sp1:enterprise_x64
cpe:/o:microsoft:windows_xp:-:gold:64-bit-2003
cpe:/o:redhat:enterprise_linux:2.1::ia64-es

All this is a natural outgrowth of a dictionary maintenance process that
depends heavily on human judgment and attention to (or failure of attention
to) precedent.

Recognizing that the CPE 2.2 "edition" component had become a bit of a
dumping ground, while designing CPE 2.3 we decided to try to explicitly
break out three fundamentally different kinds of information into separate
fields.  We decided that there was some "core" notion of edition as
reflected in terms like "Professional", "Home and Basic", "Enterprise", etc.
Separately, there was "architecture/hardware" information as reflected in
terms like "x64", "win32", "sparc", etc.  And finally there was some amount
of "target platform/software" information, as reflected in terms like
"Windows Server 2003", "HPUX", "Solaris", etc.  That is, we came to view the
CPE 2.2 "edition" component as a place where, over time, we had come to
encode three distinctly different kinds of information, and in the process
had failed to standardize where or how within the component value these
items should be encoded.

In CPE 2.3, we have defined three separate attributes: sw_edition, target_hw
and target_sw.  For backward compatibility with CPE 2.2 we retained an
"edition" attribute purely to enable pre-existing (i.e., pre-2.3) CPE names
to be mechanically translated to CPE 2.3 without requiring human review.
(By default, whatever value appears in the "edition" component of a CPE 2.2
URI will be copied to the edition attribute of a CPE 2.3 name.  But for new
names created under the rules of CPE 2.3, we've allowed the three different
types of edition-related information to be broken out separately.  Below are
examples of how the names shown above could appear as CPE 2.3 formatted
strings:

cpe:2.3:a:hp:insight_diagnostics:7.8.0.2257:unknown:-:-:online:windows_serve
r_2003:x64:-
cpe:2.3:o:microsoft:windows_2003_server::r2:-:-:enterprise:-:x64:-
cpe:23:o:microsoft:windows_server_2008:-:sp1:-:-:enterprise:-x64:-
cpe:2.3:o:microsoft:windows_xp:-:gold:-:-:2003:-:x64:-
cpe:2.3:o:redhat:enterprise_linux:2.1::-:-:es:-:ia64:-

The last four fields in the above names are: <sw_edition> : <target_sw> :
<target_hw> : <other>.  I've taken some liberties in the examples, such as
conventionally filling the "legacy edition" (6th, ignoring "cpe:2.3:") field
with a hyphen, but I think you get the idea.

So the long answer to your question is:

* CPE 2.2 supports architecture in the sense that you can just dump that
information into the edition field in the CPE 2.2 URI (the 6th field
ignoring "cpe:/").  But there really aren't any guidelines on how to do that
properly.
* CPE 2.3 supports architecture explicitly in that we give you the target_hw
attribute expressly for that purpose.

Ultimately, for such architecture support to be meaningful and useful, we
need to normalize this information across all CPE names--to prevent, e.g.,
"x64" used for target_hw in one name and "64bit" in another, etc.  The CPE
2.3 Naming specification says (cf. Section 5.3.3.9), "Values for [target_hw]
SHOULD be selected from an attribute-specific valid-values list, which MAY
be defined by other specifications that utilize this specification."  NIST,
as maintainer of the Official CPE Dictionary, has the task of defining the
process to be used to establish and maintain this valid-values list, as part
of their roll-out of the CPE 2.3 Dictionary.

I hope this message, despite its length, satisfactorily answered your
question.

Cheers,
/Brant

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


-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Wednesday, December 21, 2011 4:11 PM
To: cpe-discussion-list CPE Community Forum
Subject: [CPE-DISCUSSION-LIST] Product architecture

Forgive me if this has been hashed through numerous times before. Does CPE
(including 2.3) support architecture? For example, is there a way for me to
communicate Chrome 32 bit versus Chrome 64bit in WFN or URI formatting? Or
maybe there is an alternative method that I am unaware of?

Aharon

DTCC Confidential (Yellow)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173
<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
Loading...