More Microsoft Naming issues

[Wolfkiel, Joseph]

I was working through the Microsoft CPEs in the NVD to standardize names and
to attempt to use the 2.0 spec and see what happens.  The attached is the
result of my efforts.  Please pardon any typos.

I think I could parse most of the existing CPEs into the fields for CPE 2.0,
but my latest tribulation is where to put the architecture designation,
particularly the i386 or x64 name.  It appears all over the map in the
current CPE names, but I couldn't find a good home for it that didn't take
up real-estate that is already claimed by other names.

What should the standard naming convention be for this value?  Maybe append
it to the "edition" field?

Not a huge deal, but it does interfere with the ability to do correlation
and matching if we don't all use it the same way.  Microsoft products
written for Mac OS seem to have a similar problem, but I just dropped them
into the edition field.

Also, any feedback on whether "sr"s or "gold" releases are updates or not,
and what does "FR" mean -- French?, Feature Release?, not sure.  The more of
these abbreviations I see, the more I want to use spelled-out words.

- Joe

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

[Gary Newman-2]

Microsoft technically has built the early x64 editions completely different
from those for Win32.  Following the technical grounds, and the prefix
property, the x64 version of XP should be

        cpe:/o:Microsoft:windows_xp_x64

However, it does seem that the prefix property is being relaxed a bit.  The
marketing versions explicitly name the editions things like "Windows XP
Professional x64 Edition".  So... if you follow the strategy of following the
well known "marketing" names of the products that should become

        cpe:/o:Microsoft:windows_xp::professional_x64

I'm in favor of following the marketing names.

   -Gary-

> I was working through the Microsoft CPEs in the NVD to standardize names and
> to attempt to use the 2.0 spec and see what happens.  The attached is the
> result of my efforts.  Please pardon any typos.
>
> I think I could parse most of the existing CPEs into the fields for CPE 2.0,
> but my latest tribulation is where to put the architecture designation,
> particularly the i386 or x64 name.  It appears all over the map in the
> current CPE names, but I couldn't find a good home for it that didn't take
> up real-estate that is already claimed by other names.
>
> What should the standard naming convention be for this value?  Maybe append
> it to the "edition" field?
>
> Not a huge deal, but it does interfere with the ability to do correlation
> and matching if we don't all use it the same way.  Microsoft products
> written for Mac OS seem to have a similar problem, but I just dropped them
> into the edition field.
>
> Also, any feedback on whether "sr"s or "gold" releases are updates or not,
> and what does "FR" mean -- French?, Feature Release?, not sure.  The more of
> these abbreviations I see, the more I want to use spelled-out words.
>
> - Joe
>
> 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 [phone]

[Wolfkiel, Joseph]

I agree with Gary.

Using either of these conventions, you lose the ability to match based on
looking for either "windows_xp" or "professional".  From the vulnerabilities
I've seen lately, many of them apply across the board to all windows
products (arguing against including the architecture component at all), but
must be checked for or patched differently based on the architecture
(requiring the use of the architecture component).  So you would potentially
end up using a differet CPE to link to the vulnerability than you would use
to direct the patch for it.

If we could wantonly bastardize the CPE standard at our convenience, the
simple solution would be to add an attribute (similar to language) at the
end to address architecture.

Noting that doing that isn't really an option, I would advocate pushing it
down as far into the CPE language as possible (the edition field -- it
obviously doesn't belong in the language field [unless we're talking machine
language]).  That still gives me a high probability that my matching based
on vendor, product, and version will work, but edition may or may not based
on whether an architecture is specified in the CPE name.

For the short term, I guess I agree with Gary, with the caveat that the
sample cpe, "cpe:/o:Microsoft:windows_xp::professional_x64" should have an
additional colon so the "professional_x64" designation is in the edition
field instead of the update
field--cpe:/o:Microsoft:windows_xp:::professional_x64
type=o
vendor="microsoft"
product="windows_xp"
version=""
update=""
edition="professional_x64"



*** sidebar discussion ***
Looking toward 3.0, I'm wondering if we don't need a richer set of metadata
for CPE.  Seems like that would be easier to manage attributes than adding
or deleting sub-parts.

Consider the following example (not a real product, just a potential one):

cpe:/a:Microsoft:access:2007:sp2:professional_macos_x64:farsi

We could solve this using attributes and allow the architecture to come out
of the CPE name altogether:

<platform>cpe:/a:microsoft:access:2007:sp2:professional</platform>
     <language>farsi</language>
     <target_environment_platform>macos</target_environment_platform>
     <architecture>x64</architecture>
     <product_suite>office_2007</product_suite>
     <code_base>office_2000</code_base>

Of course we would need to define default behavior where attributes aren't
specified, but that's still easier than trying to cram all the info into a
huge string.

and... once you've gone this route, it may not really make sense to keep
CPEs in the URI format either.

Arguably, we would be just as well served by going to XML designators across
the board, reference the following:

<platform>
     <type>application</type>
     <vendor>microsoft</vendor>
     <product>access</product>
     <version>2007</version>
     <edition>professional</edition>
     <language>farsi</language>
     <target_environment_platform>macos</target_environment_platform>
     <architecture>x64</architecture>
     <product_suite>office_2007</product_suite>
     <code_base>office_2000</code_base>
</platform>

This is more easily human readable and you don't have to parse once for XML,
then again for colons.

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


-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Thursday, October 25, 2007 8:08 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] More Microsoft Naming issues


Microsoft technically has built the early x64 editions completely different
from those for Win32.  Following the technical grounds, and the prefix
property, the x64 version of XP should be

        cpe:/o:Microsoft:windows_xp_x64

However, it does seem that the prefix property is being relaxed a bit.  The
marketing versions explicitly name the editions things like "Windows XP
Professional x64 Edition".  So... if you follow the strategy of following
the
well known "marketing" names of the products that should become

        cpe:/o:Microsoft:windows_xp::professional_x64

I'm in favor of following the marketing names.

   -Gary-

> I was working through the Microsoft CPEs in the NVD to standardize names
and
> to attempt to use the 2.0 spec and see what happens.  The attached is the
> result of my efforts.  Please pardon any typos.
>
> I think I could parse most of the existing CPEs into the fields for CPE
2.0,
> but my latest tribulation is where to put the architecture designation,
> particularly the i386 or x64 name.  It appears all over the map in the
> current CPE names, but I couldn't find a good home for it that didn't take
> up real-estate that is already claimed by other names.
>
> What should the standard naming convention be for this value?  Maybe
append
> it to the "edition" field?
>
> Not a huge deal, but it does interfere with the ability to do correlation
> and matching if we don't all use it the same way.  Microsoft products
> written for Mac OS seem to have a similar problem, but I just dropped them
> into the edition field.
>
> Also, any feedback on whether "sr"s or "gold" releases are updates or not,
> and what does "FR" mean -- French?, Feature Release?, not sure.  The more
of

> these abbreviations I see, the more I want to use spelled-out words.
>
> - Joe
>
> 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 [phone]

[Gary Newman-2]

Joe, thanks for opening the discussion of where CPE should go.

You're suggesting the same kinds of things I'm thinking.  It may be best to
focus on the data, rather than the encoding though.

Here're my added $0.04 on the topic:

* The identifier should retain it's URI notation, but add a common unique
numeric ID synonym.  Anyone with a significant database will assign such a
number anyway, so it's best to get it out in the open.

* The "prefix property" should be transitioned from being a requirement to a
desired goal.  This is already what's being done, so let's get it over with and
allow freer thinking about how CPEs should operate.

* The components should be treated as independent properties, soas to free them
from the current tree-structured requirements imposed by the prefix property
requirement.  The recent x64 and spoken language discussions show that it's
important (or perhaps just convenient?) to have properties independent of the
tree structure set out by the prefix property.

* The component names should closely align with authoritative (likely
marketing) names for the "platform" the CPE describes.  This is both more
understandable and possible with the relaxation of the prefix property.

Anyone else like to join us at the sidebar?

        -Gary-

> *** sidebar discussion ***
> Looking toward 3.0, I'm wondering if we don't need a richer set of
> metadata for CPE.  Seems like that would be easier to manage attributes
> than adding or deleting sub-parts.
>
> Consider the following example (not a real product, just a potential one):
>
> cpe:/a:Microsoft:access:2007:sp2:professional_macos_x64:farsi
>
> We could solve this using attributes and allow the architecture to come
> out of the CPE name altogether:
>
> <platform>cpe:/a:microsoft:access:2007:sp2:professional</platform>
>      <language>farsi</language>
>      <target_environment_platform>macos</target_environment_platform>
>      <architecture>x64</architecture>
>      <product_suite>office_2007</product_suite>
>      <code_base>office_2000</code_base>
>
> Of course we would need to define default behavior where attributes aren't
> specified, but that's still easier than trying to cram all the info into a
> huge string.
>
> and... once you've gone this route, it may not really make sense to keep
> CPEs in the URI format either.
>
> Arguably, we would be just as well served by going to XML designators
> across the board, reference the following:
>
> <platform>
>      <type>application</type>
>      <vendor>microsoft</vendor>
>      <product>access</product>
>      <version>2007</version>
>      <edition>professional</edition>
>      <language>farsi</language>
>      <target_environment_platform>macos</target_environment_platform>
>      <architecture>x64</architecture>
>      <product_suite>office_2007</product_suite>
>      <code_base>office_2000</code_base>
> </platform>
>
> This is more easily human readable and you don't have to parse once for
> XML, then again for colons.
>
> 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 [phone]

[Ken Lassesen-3]

 May I also remind folks that there were both i64 and x64 for XP

" A version of Windows XP for the Itanium processor is no longer
available. Windows Server 2003 Enterprise Edition continues to support
the Itanium processor."

http://www.microsoft.com/windowsxp/using/64bit/russel_x64faq.mspx 

Although the itanium is well into a sunset, it will likely live for many
years in artifact machines.

So, I would suggest          cpe:/o:Microsoft:windows_xp_i64


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: Gary Newman [mailto:[hidden email]]

Microsoft technically has built the early x64 editions completely
different from those for Win32.  Following the technical grounds, and
the prefix property, the x64 version of XP should be

        cpe:/o:Microsoft:windows_xp_x64

[Ken Lassesen-3]

Going through the list I see the issue/challenge of arbitary origin in
time.

Some products were known by version number, i.e. SQL Server 6.5 and then
the marketing naming switched over to SQL Server 2000.If you look at the
physical folders you see the original pattern is maintained in the file
system.

C:\Program Files\Microsoft SQL Server\80
C:\Program Files\Microsoft SQL Server\90

This is the typical pattern for Microsoft products at the MOMENT, it
really hits the issue of marketing names versus technical names.

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: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, October 25, 2007 2:17 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] More Microsoft Naming issues

I was working through the Microsoft CPEs in the NVD to standardize names
and to attempt to use the 2.0 spec and see what happens.  The attached
is the result of my efforts.  Please pardon any typos.

I think I could parse most of the existing CPEs into the fields for CPE
2.0, but my latest tribulation is where to put the architecture
designation, particularly the i386 or x64 name.  It appears all over the
map in the current CPE names, but I couldn't find a good home for it
that didn't take up real-estate that is already claimed by other names.

What should the standard naming convention be for this value?  Maybe
append it to the "edition" field?

Not a huge deal, but it does interfere with the ability to do
correlation and matching if we don't all use it the same way.  Microsoft
products written for Mac OS seem to have a similar problem, but I just
dropped them into the edition field.

Also, any feedback on whether "sr"s or "gold" releases are updates or
not, and what does "FR" mean -- French?, Feature Release?, not sure.
The more of these abbreviations I see, the more I want to use
spelled-out words.

- Joe

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

[Wolfkiel, Joseph]

So here's the latest with the x64 appended to the edition field.

I spent some time thinking about this over the weekend.  Seems like we may
need to be able to describe the target HW environment for the platform --
(e.g. i386, x64), as well as the target SW environment for the platform
(e.g. windows_xp, macos, solaris) in addition to the parts we have.  

Picture, if you will, this product:  Microsoft Access, professional edition,
SP3, 64 bit, for Mac OS-X, French

We could pick some arbitrary way to assign each of these names to an
existing sub-part, but which ones end up being important to match a setting
or vulnerability?  If we start just gluing names together, I'm afraid (and
believe I've seen examples) that we'll lose the ability to match the
critical name pieces to other platforms that have the same vulnerability.

In most of the examples I've seen, the only parts of the example that are
really important (as far as determining vulnerabilities and settings) are
knowing that it's Microsoft Access, SP3.  However, if you want to apply
patches, you'll have to know to look for it on Mac OS X machines, and that
you need the 64-bit version of the patch instead of the 32-bit.

I've also been running into some problems using the CPEs to aggregate
vulnerabilities.  Particularly with the implied "and previous" concept.
E.g. if I find a vulnerability on Windows XP Service Pack 2, I would assume
it also may occur on SP1 and Windows XP without any service packs.  I have
talked to others who said if it's specified for Service Pack 2, it only
occurs on SP2 machines, and you can't assume the "and previous"
functionality.

I'm not clear on exactly how NVD deals with this issue.

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


-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Sunday, October 28, 2007 8:02 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] More Microsoft Naming issues


Going through the list I see the issue/challenge of arbitary origin in
time.

Some products were known by version number, i.e. SQL Server 6.5 and then
the marketing naming switched over to SQL Server 2000.If you look at the
physical folders you see the original pattern is maintained in the file
system.

C:\Program Files\Microsoft SQL Server\80
C:\Program Files\Microsoft SQL Server\90

This is the typical pattern for Microsoft products at the MOMENT, it
really hits the issue of marketing names versus technical names.

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: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, October 25, 2007 2:17 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] More Microsoft Naming issues

I was working through the Microsoft CPEs in the NVD to standardize names
and to attempt to use the 2.0 spec and see what happens.  The attached
is the result of my efforts.  Please pardon any typos.

I think I could parse most of the existing CPEs into the fields for CPE
2.0, but my latest tribulation is where to put the architecture
designation, particularly the i386 or x64 name.  It appears all over the
map in the current CPE names, but I couldn't find a good home for it
that didn't take up real-estate that is already claimed by other names.

What should the standard naming convention be for this value?  Maybe
append it to the "edition" field?

Not a huge deal, but it does interfere with the ability to do
correlation and matching if we don't all use it the same way.  Microsoft
products written for Mac OS seem to have a similar problem, but I just
dropped them into the edition field.

Also, any feedback on whether "sr"s or "gold" releases are updates or
not, and what does "FR" mean -- French?, Feature Release?, not sure.
The more of these abbreviations I see, the more I want to use
spelled-out words.

- Joe

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

[Gary Newman-2]

Hi Joe,

It seems that the problem you're tackling is difficult because of the desire to
"reverse engineer" products to create a taxonomy.  The goal is admirable: to
more clearly and simply specify by using a tree of that taxonomy, yet both
difficult and not necessary.  I recommend that the creation of a software
taxonomy be a (background) research effort until shown that it can be broadly
applied.  In the mean time this community should simply use product names given
by the software publisher.

At least for Microsoft, the detection of vulnerabilities is different for the
x64 OSes.  For example:

        http://www.microsoft.com/technet/security/Bulletin/MS07-056.mspx

As to the "and previous" issue, this recent MS security update

        http://www.microsoft.com/technet/security/Bulletin/MS07-055.mspx

is an example that applies to XP SP2 but not XP SP1.

        -Gary-

> So here's the latest with the x64 appended to the edition field.
>
> I spent some time thinking about this over the weekend.  Seems like we may
> need to be able to describe the target HW environment for the platform --
> (e.g. i386, x64), as well as the target SW environment for the platform
> (e.g. windows_xp, macos, solaris) in addition to the parts we have.  
>
> Picture, if you will, this product:  Microsoft Access, professional edition,
> SP3, 64 bit, for Mac OS-X, French
>
> We could pick some arbitrary way to assign each of these names to an
> existing sub-part, but which ones end up being important to match a setting
> or vulnerability?  If we start just gluing names together, I'm afraid (and
> believe I've seen examples) that we'll lose the ability to match the
> critical name pieces to other platforms that have the same vulnerability.
>
> In most of the examples I've seen, the only parts of the example that are
> really important (as far as determining vulnerabilities and settings) are
> knowing that it's Microsoft Access, SP3.  However, if you want to apply
> patches, you'll have to know to look for it on Mac OS X machines, and that
> you need the 64-bit version of the patch instead of the 32-bit.
>
> I've also been running into some problems using the CPEs to aggregate
> vulnerabilities.  Particularly with the implied "and previous" concept.
> E.g. if I find a vulnerability on Windows XP Service Pack 2, I would assume
> it also may occur on SP1 and Windows XP without any service packs.  I have
> talked to others who said if it's specified for Service Pack 2, it only
> occurs on SP2 machines, and you can't assume the "and previous"
> functionality.
>
> I'm not clear on exactly how NVD deals with this issue.
>
> 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 [phone]

[Wolfkiel, Joseph]

I agree that reverse-engineering the software is too hard for the present.  

I wanted to have the discussion on whether vulnerabilities and remediations
are specified frequently enough based on hardware architecture or target OS
environment to justify giving them their own metadata tags.  I note that, in
the example, both Windows XP and Windows XP x64 had the vulnerability. I'm
assuming they are treated differently because they must be scanned and
patched differently.

Using the current naming conventions, I could find the related vulnerability
by searching Windows XP, but might not be able to match the HW architecture
since there are other names jammed into the Edition sub-part.  Based on that
thinking, if I want to unambiguously match based on HW architecture, it
would probably need to have its own metadata.

For Windows, it seems the important things to know are generally product
name, update, plus target HW and (possibly) SW architecture.

Admittedly, I can do most of what I want to do with the Version 2.0 names.

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


-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Monday, October 29, 2007 10:38 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] More Microsoft Naming issues


Hi Joe,

It seems that the problem you're tackling is difficult because of the desire
to
"reverse engineer" products to create a taxonomy.  The goal is admirable: to

more clearly and simply specify by using a tree of that taxonomy, yet both
difficult and not necessary.  I recommend that the creation of a software
taxonomy be a (background) research effort until shown that it can be
broadly
applied.  In the mean time this community should simply use product names
given
by the software publisher.

At least for Microsoft, the detection of vulnerabilities is different for
the
x64 OSes.  For example:

        http://www.microsoft.com/technet/security/Bulletin/MS07-056.mspx

As to the "and previous" issue, this recent MS security update

        http://www.microsoft.com/technet/security/Bulletin/MS07-055.mspx

is an example that applies to XP SP2 but not XP SP1.

        -Gary-

> So here's the latest with the x64 appended to the edition field.
>
> I spent some time thinking about this over the weekend.  Seems like we may
> need to be able to describe the target HW environment for the platform --
> (e.g. i386, x64), as well as the target SW environment for the platform
> (e.g. windows_xp, macos, solaris) in addition to the parts we have.  
>
> Picture, if you will, this product:  Microsoft Access, professional
edition,
> SP3, 64 bit, for Mac OS-X, French
>
> We could pick some arbitrary way to assign each of these names to an
> existing sub-part, but which ones end up being important to match a
setting

> or vulnerability?  If we start just gluing names together, I'm afraid (and
> believe I've seen examples) that we'll lose the ability to match the
> critical name pieces to other platforms that have the same vulnerability.
>
> In most of the examples I've seen, the only parts of the example that are
> really important (as far as determining vulnerabilities and settings) are
> knowing that it's Microsoft Access, SP3.  However, if you want to apply
> patches, you'll have to know to look for it on Mac OS X machines, and that
> you need the 64-bit version of the patch instead of the 32-bit.
>
> I've also been running into some problems using the CPEs to aggregate
> vulnerabilities.  Particularly with the implied "and previous" concept.
> E.g. if I find a vulnerability on Windows XP Service Pack 2, I would

assume

> it also may occur on SP1 and Windows XP without any service packs.  I have
> talked to others who said if it's specified for Service Pack 2, it only
> occurs on SP2 machines, and you can't assume the "and previous"
> functionality.
>
> I'm not clear on exactly how NVD deals with this issue.
>
> 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 [phone]

[Wolfkiel, Joseph]

So I went back and read the supporting verbiage in both the security
bulletins.  I think the following caveat makes a pretty good case for having
to assume the "and previous."

"The affected software listed in this bulletin have been tested to determine
which versions or editions are affected. Other versions or editions are past
their support life cycle. To determine the support life cycle for your
software versions or editions, visit Microsoft Support Lifecycle."

Basically, it doesn't say XP SP1 wasn't vulnerable, it just wasn't tested.

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


-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Monday, October 29, 2007 10:38 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] More Microsoft Naming issues


Hi Joe,

It seems that the problem you're tackling is difficult because of the desire
to
"reverse engineer" products to create a taxonomy.  The goal is admirable: to

more clearly and simply specify by using a tree of that taxonomy, yet both
difficult and not necessary.  I recommend that the creation of a software
taxonomy be a (background) research effort until shown that it can be
broadly
applied.  In the mean time this community should simply use product names
given
by the software publisher.

At least for Microsoft, the detection of vulnerabilities is different for
the
x64 OSes.  For example:

        http://www.microsoft.com/technet/security/Bulletin/MS07-056.mspx

As to the "and previous" issue, this recent MS security update

        http://www.microsoft.com/technet/security/Bulletin/MS07-055.mspx

is an example that applies to XP SP2 but not XP SP1.

        -Gary-

> So here's the latest with the x64 appended to the edition field.
>
> I spent some time thinking about this over the weekend.  Seems like we may
> need to be able to describe the target HW environment for the platform --
> (e.g. i386, x64), as well as the target SW environment for the platform
> (e.g. windows_xp, macos, solaris) in addition to the parts we have.  
>
> Picture, if you will, this product:  Microsoft Access, professional
edition,
> SP3, 64 bit, for Mac OS-X, French
>
> We could pick some arbitrary way to assign each of these names to an
> existing sub-part, but which ones end up being important to match a
setting

> or vulnerability?  If we start just gluing names together, I'm afraid (and
> believe I've seen examples) that we'll lose the ability to match the
> critical name pieces to other platforms that have the same vulnerability.
>
> In most of the examples I've seen, the only parts of the example that are
> really important (as far as determining vulnerabilities and settings) are
> knowing that it's Microsoft Access, SP3.  However, if you want to apply
> patches, you'll have to know to look for it on Mac OS X machines, and that
> you need the 64-bit version of the patch instead of the 32-bit.
>
> I've also been running into some problems using the CPEs to aggregate
> vulnerabilities.  Particularly with the implied "and previous" concept.
> E.g. if I find a vulnerability on Windows XP Service Pack 2, I would

assume

> it also may occur on SP1 and Windows XP without any service packs.  I have
> talked to others who said if it's specified for Service Pack 2, it only
> occurs on SP2 machines, and you can't assume the "and previous"
> functionality.
>
> I'm not clear on exactly how NVD deals with this issue.
>
> 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 [phone]

[Ken Lassesen-3]

Language is also important for some patches (depends on how the patch is
packaged), and in a few cases, whether the patch included 40bit or
128bit encryption code.


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: Wolfkiel, Joseph [mailto:[hidden email]]

In most of the examples I've seen, the only parts of the example that
are really important (as far as determining vulnerabilities and
settings) are knowing that it's Microsoft Access, SP3.  However, if you
want to apply patches, you'll have to know to look for it on Mac OS X
machines, and that you need the 64-bit version of the patch instead of
the 32-bit.

I've also been running into some problems using the CPEs to aggregate
vulnerabilities.  Particularly with the implied "and previous" concept.
E.g. if I find a vulnerability on Windows XP Service Pack 2, I would
assume it also may occur on SP1 and Windows XP without any service
packs.  I have talked to others who said if it's specified for Service
Pack 2, it only occurs on SP2 machines, and you can't assume the "and
previous"
functionality.

I'm not clear on exactly how NVD deals with this issue.

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


-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Sunday, October 28, 2007 8:02 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] More Microsoft Naming issues


Going through the list I see the issue/challenge of arbitary origin in
time.

Some products were known by version number, i.e. SQL Server 6.5 and then
the marketing naming switched over to SQL Server 2000.If you look at the
physical folders you see the original pattern is maintained in the file
system.

C:\Program Files\Microsoft SQL Server\80 C:\Program Files\Microsoft SQL
Server\90

This is the typical pattern for Microsoft products at the MOMENT, it
really hits the issue of marketing names versus technical names.

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: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Thursday, October 25, 2007 2:17 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] More Microsoft Naming issues

I was working through the Microsoft CPEs in the NVD to standardize names
and to attempt to use the 2.0 spec and see what happens.  The attached
is the result of my efforts.  Please pardon any typos.

I think I could parse most of the existing CPEs into the fields for CPE
2.0, but my latest tribulation is where to put the architecture
designation, particularly the i386 or x64 name.  It appears all over the
map in the current CPE names, but I couldn't find a good home for it
that didn't take up real-estate that is already claimed by other names.

What should the standard naming convention be for this value?  Maybe
append it to the "edition" field?

Not a huge deal, but it does interfere with the ability to do
correlation and matching if we don't all use it the same way.  Microsoft
products written for Mac OS seem to have a similar problem, but I just
dropped them into the edition field.

Also, any feedback on whether "sr"s or "gold" releases are updates or
not, and what does "FR" mean -- French?, Feature Release?, not sure.
The more of these abbreviations I see, the more I want to use
spelled-out words.

- Joe

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

[Ken Lassesen-3]

This leads to that common theme of needing a Common Platform Language
(CPL) to clarify what is a CPE. Part of the language is the product
heritage (a linked list of pointers to prior products). We don't want it
to be double linked list because that becomes a maintenance headache
[although vendors could implement such in their own products, using the
prior-linked-list and updating constantly].

In some ways it may make CVE's simpler. Just designate the current
product and then attribute "priorproducts" instead of enumerating out
the choices. It's a tree, but not a hierarchy.


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: Wolfkiel, Joseph [mailto:[hidden email]]

Basically, it doesn't say XP SP1 wasn't vulnerable, it just wasn't
tested.

Lt Col Joseph L. Wolfkiel

[Gary Newman-2]

Hi Joe,

You're right!  I didn't take into account the support life cycle.  It would be
hard to find an example then.  It's easy to envision a vulnerability in a
component that didn't even exist in SP1 though.  Any of the security features
added in SP2 could need an update that wouldn't apply to SP1.

Sorry for my misdirection there.

        -Gary-

> So I went back and read the supporting verbiage in both the security
> bulletins.  I think the following caveat makes a pretty good case for having
> to assume the "and previous."
>
> "The affected software listed in this bulletin have been tested to determine
> which versions or editions are affected. Other versions or editions are past
> their support life cycle. To determine the support life cycle for your
> software versions or editions, visit Microsoft Support Lifecycle."
>
> Basically, it doesn't say XP SP1 wasn't vulnerable, it just wasn't tested.
>
> 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 [phone]
>
>
> -----Original Message-----
> From: Gary Newman [mailto:[hidden email]]
> Sent: Monday, October 29, 2007 10:38 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] More Microsoft Naming issues
>
>
> Hi Joe,
>
> It seems that the problem you're tackling is difficult because of the desire
> to
> "reverse engineer" products to create a taxonomy.  The goal is admirable: to
>
> more clearly and simply specify by using a tree of that taxonomy, yet both
> difficult and not necessary.  I recommend that the creation of a software
> taxonomy be a (background) research effort until shown that it can be
> broadly
> applied.  In the mean time this community should simply use product names
> given
> by the software publisher.
>
> At least for Microsoft, the detection of vulnerabilities is different for
> the
> x64 OSes.  For example:
>
>         http://www.microsoft.com/technet/security/Bulletin/MS07-056.mspx
>
> As to the "and previous" issue, this recent MS security update
>
>         http://www.microsoft.com/technet/security/Bulletin/MS07-055.mspx
>
> is an example that applies to XP SP2 but not XP SP1.
>
>         -Gary-
>
> > So here's the latest with the x64 appended to the edition field.
> >
> > I spent some time thinking about this over the weekend.  Seems like we may
> > need to be able to describe the target HW environment for the platform --
> > (e.g. i386, x64), as well as the target SW environment for the platform
> > (e.g. windows_xp, macos, solaris) in addition to the parts we have.  
> >
> > Picture, if you will, this product:  Microsoft Access, professional
> edition,
> > SP3, 64 bit, for Mac OS-X, French
> >
> > We could pick some arbitrary way to assign each of these names to an
> > existing sub-part, but which ones end up being important to match a
> setting
> > or vulnerability?  If we start just gluing names together, I'm afraid (and
> > believe I've seen examples) that we'll lose the ability to match the
> > critical name pieces to other platforms that have the same vulnerability.
> >
> > In most of the examples I've seen, the only parts of the example that are
> > really important (as far as determining vulnerabilities and settings) are
> > knowing that it's Microsoft Access, SP3.  However, if you want to apply
> > patches, you'll have to know to look for it on Mac OS X machines, and that
> > you need the 64-bit version of the patch instead of the 32-bit.
> >
> > I've also been running into some problems using the CPEs to aggregate
> > vulnerabilities.  Particularly with the implied "and previous" concept.
> > E.g. if I find a vulnerability on Windows XP Service Pack 2, I would
> assume
> > it also may occur on SP1 and Windows XP without any service packs.  I have
> > talked to others who said if it's specified for Service Pack 2, it only
> > occurs on SP2 machines, and you can't assume the "and previous"
> > functionality.
> >
> > I'm not clear on exactly how NVD deals with this issue.
> >
> > 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 [phone]
>
>
>