Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

All,

I've been working more on the concept of converting registry-equivalent entries for discovered product names into CPE format.

My last attempt was to take a dump off of one of our lab Red Hat machines and attempt to convert the installed packages into CPE-compliant names using an automatable process.

Here's what I came up with:

The original file, redhat inventory.txt has names pulled from RPM in pipe-delimited format.  If I understand the structure right, you get the application name, distributor, version, release, target microprocessor architecture, and the package number.  I took the values and made my best guess at where everything should go during a conversion into CPE.  The file "linuxcpenames.txt" shows the CPE equivalent output.

I didn't run the full lookup table to convert everything, so there are still upper case letters and some unconverted symbols, but I think it's obvious how that would be taken care of.

What I'd like to focus on are the less obvious issues.  Specifically:
- Should the "Red_Hat,_Inc." be in the vendor field, or in the target software field?  If I put it in the vendor field, it's obviously incorrect in several cases (e.g. the vendor for Python isn't Red Hat)
- Does "release" go in the version field?
- I substituted "-" for "noarch".  Is that right?
- I put the package data into the edition "other" field.  Should it go there?  If it does, should there be a tag associated with it (e.g. pkg_eq__)?

These issues don't seem unsolvable, but they do illustrate the need for some sort of community common practice for how to deal with the different name components maintained by each operating system.

I appreciate any feedback.  Is anyone else working on this?  What heuristics are you using?

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
    Classification:  UNCLASSIFIED
Caveats: NONE


linuxcpenames.txt (60K) Download Attachment
redhat_inventory.txt (53K) Download Attachment
smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

Thomas Jones
Hello Joseph,

I have been down the road you are currently traversing. I performed a
very similiar generation script using bash for the Novell suite of
products.

I am currently developing a perl implementation for deriving entire
oval inventory and cpe sources.

Let me know if you want to collaborate. Cheers.

Thomas

Sent from my iPhone

On Oct 29, 2010, at 2:41 PM, "WOLFKIEL, JOSEPH L CIV DISA PEO-MA"
<[hidden email]
 > wrote:

> Classification:  UNCLASSIFIED
> Caveats: NONE
>
> All,
>
> I've been working more on the concept of converting registry-
> equivalent entries for discovered product names into CPE format.
>
> My last attempt was to take a dump off of one of our lab Red Hat
> machines and attempt to convert the installed packages into CPE-
> compliant names using an automatable process.
>
> Here's what I came up with:
>
> The original file, redhat inventory.txt has names pulled from RPM in
> pipe-delimited format.  If I understand the structure right, you get
> the application name, distributor, version, release, target
> microprocessor architecture, and the package number.  I took the
> values and made my best guess at where everything should go during a
> conversion into CPE.  The file "linuxcpenames.txt" shows the CPE
> equivalent output.
>
> I didn't run the full lookup table to convert everything, so there
> are still upper case letters and some unconverted symbols, but I
> think it's obvious how that would be taken care of.
>
> What I'd like to focus on are the less obvious issues.  Specifically:
> - Should the "Red_Hat,_Inc." be in the vendor field, or in the
> target software field?  If I put it in the vendor field, it's
> obviously incorrect in several cases (e.g. the vendor for Python
> isn't Red Hat)
> - Does "release" go in the version field?
> - I substituted "-" for "noarch".  Is that right?
> - I put the package data into the edition "other" field.  Should it
> go there?  If it does, should there be a tag associated with it
> (e.g. pkg_eq__)?
>
> These issues don't seem unsolvable, but they do illustrate the need
> for some sort of community common practice for how to deal with the
> different name components maintained by each operating system.
>
> I appreciate any feedback.  Is anyone else working on this?  What
> heuristics are you using?
>
> Joseph L. Wolfkiel
> Engineering Group Lead
> DISA PEO MA/IA52
> (703) 882-0772
> [hidden email]
>    Classification:  UNCLASSIFIED
> Caveats: NONE
>
> <linuxcpenames.txt>
> <redhat_inventory.txt>
Reply | Threaded
Open this post in threaded view
|

Re: Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

Adam Montville
Has anyone ever considered opening up development to a CPE repository
service that could be made available to primary platform vendors (i.e.
Operating system vendors) that would listen on a certain port (say 273) and
report it's installation configuration?

In this way, a scanner would be able to discover a host, connect to and
interrogate that host on 273 to determine it's complete configuration based
on CPE names.

Regards,

Adam


On 10/29/10 1:07 PM, "Thomas Jones" <[hidden email]>
wrote:

> Hello Joseph,
>
> I have been down the road you are currently traversing. I performed a
> very similiar generation script using bash for the Novell suite of
> products.
>
> I am currently developing a perl implementation for deriving entire
> oval inventory and cpe sources.
>
> Let me know if you want to collaborate. Cheers.
>
> Thomas
>
> Sent from my iPhone
>
> On Oct 29, 2010, at 2:41 PM, "WOLFKIEL, JOSEPH L CIV DISA PEO-MA"
> <[hidden email]
>> wrote:
>
>> Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> All,
>>
>> I've been working more on the concept of converting registry-
>> equivalent entries for discovered product names into CPE format.
>>
>> My last attempt was to take a dump off of one of our lab Red Hat
>> machines and attempt to convert the installed packages into CPE-
>> compliant names using an automatable process.
>>
>> Here's what I came up with:
>>
>> The original file, redhat inventory.txt has names pulled from RPM in
>> pipe-delimited format.  If I understand the structure right, you get
>> the application name, distributor, version, release, target
>> microprocessor architecture, and the package number.  I took the
>> values and made my best guess at where everything should go during a
>> conversion into CPE.  The file "linuxcpenames.txt" shows the CPE
>> equivalent output.
>>
>> I didn't run the full lookup table to convert everything, so there
>> are still upper case letters and some unconverted symbols, but I
>> think it's obvious how that would be taken care of.
>>
>> What I'd like to focus on are the less obvious issues.  Specifically:
>> - Should the "Red_Hat,_Inc." be in the vendor field, or in the
>> target software field?  If I put it in the vendor field, it's
>> obviously incorrect in several cases (e.g. the vendor for Python
>> isn't Red Hat)
>> - Does "release" go in the version field?
>> - I substituted "-" for "noarch".  Is that right?
>> - I put the package data into the edition "other" field.  Should it
>> go there?  If it does, should there be a tag associated with it
>> (e.g. pkg_eq__)?
>>
>> These issues don't seem unsolvable, but they do illustrate the need
>> for some sort of community common practice for how to deal with the
>> different name components maintained by each operating system.
>>
>> I appreciate any feedback.  Is anyone else working on this?  What
>> heuristics are you using?
>>
>> Joseph L. Wolfkiel
>> Engineering Group Lead
>> DISA PEO MA/IA52
>> (703) 882-0772
>> [hidden email]
>>    Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> <linuxcpenames.txt>
>> <redhat_inventory.txt>
>

Adam Montville, CISSP | Security and Compliance Solutions Program Manager
Direct: 503.276.7661
Mobile: 360.471.7815
 
TRIPWIRE | The Leader in IT Security & Compliance Software
http://www.tripwire.com
Reply | Threaded
Open this post in threaded view
|

Re: Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking about this over the weekend.

First thought -- Shouldn't this be done as an SNMP MIB?
Second thought -- What would the security considerations be?  Seems like a full CPE/update dump is pretty much one stop (via the NVD) away from a full vulnerability enumeration and would be pretty sensitive.
Third thought -- Based on my (limited) experience with the IANA guys, registering a new port is really difficult.

Reservations aside, I like the thought.  It would be a big win if CPE were incorporated into a standardized interface to output installed software and patches.  The devil, of course, is in the details.  


Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: Adam W. Montville [mailto:[hidden email]]
Sent: Friday, October 29, 2010 7:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

Has anyone ever considered opening up development to a CPE repository
service that could be made available to primary platform vendors (i.e.
Operating system vendors) that would listen on a certain port (say 273) and
report it's installation configuration?

In this way, a scanner would be able to discover a host, connect to and
interrogate that host on 273 to determine it's complete configuration based
on CPE names.

Regards,

Adam


On 10/29/10 1:07 PM, "Thomas Jones" <[hidden email]>
wrote:

> Hello Joseph,
>
> I have been down the road you are currently traversing. I performed a
> very similiar generation script using bash for the Novell suite of
> products.
>
> I am currently developing a perl implementation for deriving entire
> oval inventory and cpe sources.
>
> Let me know if you want to collaborate. Cheers.
>
> Thomas
>
> Sent from my iPhone
>
> On Oct 29, 2010, at 2:41 PM, "WOLFKIEL, JOSEPH L CIV DISA PEO-MA"
> <[hidden email]
>> wrote:
>
>> Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> All,
>>
>> I've been working more on the concept of converting registry-
>> equivalent entries for discovered product names into CPE format.
>>
>> My last attempt was to take a dump off of one of our lab Red Hat
>> machines and attempt to convert the installed packages into CPE-
>> compliant names using an automatable process.
>>
>> Here's what I came up with:
>>
>> The original file, redhat inventory.txt has names pulled from RPM in
>> pipe-delimited format.  If I understand the structure right, you get
>> the application name, distributor, version, release, target
>> microprocessor architecture, and the package number.  I took the
>> values and made my best guess at where everything should go during a
>> conversion into CPE.  The file "linuxcpenames.txt" shows the CPE
>> equivalent output.
>>
>> I didn't run the full lookup table to convert everything, so there
>> are still upper case letters and some unconverted symbols, but I
>> think it's obvious how that would be taken care of.
>>
>> What I'd like to focus on are the less obvious issues.  Specifically:
>> - Should the "Red_Hat,_Inc." be in the vendor field, or in the
>> target software field?  If I put it in the vendor field, it's
>> obviously incorrect in several cases (e.g. the vendor for Python
>> isn't Red Hat)
>> - Does "release" go in the version field?
>> - I substituted "-" for "noarch".  Is that right?
>> - I put the package data into the edition "other" field.  Should it
>> go there?  If it does, should there be a tag associated with it
>> (e.g. pkg_eq__)?
>>
>> These issues don't seem unsolvable, but they do illustrate the need
>> for some sort of community common practice for how to deal with the
>> different name components maintained by each operating system.
>>
>> I appreciate any feedback.  Is anyone else working on this?  What
>> heuristics are you using?
>>
>> Joseph L. Wolfkiel
>> Engineering Group Lead
>> DISA PEO MA/IA52
>> (703) 882-0772
>> [hidden email]
>>    Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> <linuxcpenames.txt>
>> <redhat_inventory.txt>
>
Adam Montville, CISSP | Security and Compliance Solutions Program Manager
Direct: 503.276.7661
Mobile: 360.471.7815
 
TRIPWIRE | The Leader in IT Security & Compliance Software
http://www.tripwire.com
Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

Adam Montville
SNMP MIB wouldn't be bad (frankly, any way to leave the chicken/egg
problem behind).

As far as a one-stop-shop of sensitive information, well, yes it could
be.  But, which scenario is worse: The bad guys know our vulnerabilities
better than we do, or we know our vulnerabilities just as well as the
bad guys?

I'd rather know about everything in my domain and be able to address
potential issues than worry about whether an attacker will have the same
information.  In fact, in the same spirit as assuming an attacker has
knowledge of a cryptographic algorithm when designing it, we should
assume that an attacker knows our configurations.

So, I suppose the question still stands to the larger group as well,
though modified: Has anyone considered backing an open-source,
cross-platform interface for housing CPE information on a host?  Put
another way, should we seek the devil in those details or not?

Adam

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA
[mailto:[hidden email]]
Sent: Monday, November 01, 2010 4:38 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking about this over the weekend.

First thought -- Shouldn't this be done as an SNMP MIB?
Second thought -- What would the security considerations be?  Seems like
a full CPE/update dump is pretty much one stop (via the NVD) away from a
full vulnerability enumeration and would be pretty sensitive.
Third thought -- Based on my (limited) experience with the IANA guys,
registering a new port is really difficult.

Reservations aside, I like the thought.  It would be a big win if CPE
were incorporated into a standardized interface to output installed
software and patches.  The devil, of course, is in the details.  


Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: Adam W. Montville [mailto:[hidden email]]
Sent: Friday, October 29, 2010 7:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Has anyone ever considered opening up development to a CPE repository
service that could be made available to primary platform vendors (i.e.
Operating system vendors) that would listen on a certain port (say 273)
and
report it's installation configuration?

In this way, a scanner would be able to discover a host, connect to and
interrogate that host on 273 to determine it's complete configuration
based
on CPE names.

Regards,

Adam


On 10/29/10 1:07 PM, "Thomas Jones" <[hidden email]>
wrote:

> Hello Joseph,
>
> I have been down the road you are currently traversing. I performed a
> very similiar generation script using bash for the Novell suite of
> products.
>
> I am currently developing a perl implementation for deriving entire
> oval inventory and cpe sources.
>
> Let me know if you want to collaborate. Cheers.
>
> Thomas
>
> Sent from my iPhone
>
> On Oct 29, 2010, at 2:41 PM, "WOLFKIEL, JOSEPH L CIV DISA PEO-MA"
> <[hidden email]
>> wrote:
>
>> Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> All,
>>
>> I've been working more on the concept of converting registry-
>> equivalent entries for discovered product names into CPE format.
>>
>> My last attempt was to take a dump off of one of our lab Red Hat
>> machines and attempt to convert the installed packages into CPE-
>> compliant names using an automatable process.
>>
>> Here's what I came up with:
>>
>> The original file, redhat inventory.txt has names pulled from RPM in
>> pipe-delimited format.  If I understand the structure right, you get
>> the application name, distributor, version, release, target
>> microprocessor architecture, and the package number.  I took the
>> values and made my best guess at where everything should go during a
>> conversion into CPE.  The file "linuxcpenames.txt" shows the CPE
>> equivalent output.
>>
>> I didn't run the full lookup table to convert everything, so there
>> are still upper case letters and some unconverted symbols, but I
>> think it's obvious how that would be taken care of.
>>
>> What I'd like to focus on are the less obvious issues.  Specifically:
>> - Should the "Red_Hat,_Inc." be in the vendor field, or in the
>> target software field?  If I put it in the vendor field, it's
>> obviously incorrect in several cases (e.g. the vendor for Python
>> isn't Red Hat)
>> - Does "release" go in the version field?
>> - I substituted "-" for "noarch".  Is that right?
>> - I put the package data into the edition "other" field.  Should it
>> go there?  If it does, should there be a tag associated with it
>> (e.g. pkg_eq__)?
>>
>> These issues don't seem unsolvable, but they do illustrate the need
>> for some sort of community common practice for how to deal with the
>> different name components maintained by each operating system.
>>
>> I appreciate any feedback.  Is anyone else working on this?  What
>> heuristics are you using?
>>
>> Joseph L. Wolfkiel
>> Engineering Group Lead
>> DISA PEO MA/IA52
>> (703) 882-0772
>> [hidden email]
>>    Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> <linuxcpenames.txt>
>> <redhat_inventory.txt>
>

Adam Montville, CISSP | Security and Compliance Solutions Program
Manager
Direct: 503.276.7661
Mobile: 360.471.7815
 
TRIPWIRE | The Leader in IT Security & Compliance Software
http://www.tripwire.com
Classification:  UNCLASSIFIED
Caveats: NONE
Reply | Threaded
Open this post in threaded view
|

Re: Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

Tim Keanini
The problem with a service or even the concept of SNMP is the notion of a
'node under management'.
While this concept makes perfect sense for those end-points that are
under-management, we are dealing with a namespace that must consider the set
of end-points not under-management.  For this reason, I am not a huge fan of
an application service specific to this type of inquiry and much more biased
toward an approach that would try and make sense of what is the end-points
natural operational state.  I think what Joe is asking is given certain
end-point defaults states, how can one derive useful CPE names that are
stable and useful across vendor boundaries.  

Joe, I'm not sure we will ever get this perfect because there will always be
exceptions in the names that are "wrong" so maybe a strategy that would give
the asserted name enough context.  All of my examples here would be in RDF
but any way to represent metadata would suffice.  If something is wrong
consistently than provided enough context to the data the data consumers can
compensate.

--tk

-----Original Message-----
From: Adam Montville [mailto:[hidden email]]
Sent: Monday, November 01, 2010 4:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux RPM
entries into CPE Names (UNCLASSIFIED)

SNMP MIB wouldn't be bad (frankly, any way to leave the chicken/egg
problem behind).

As far as a one-stop-shop of sensitive information, well, yes it could
be.  But, which scenario is worse: The bad guys know our vulnerabilities
better than we do, or we know our vulnerabilities just as well as the
bad guys?

I'd rather know about everything in my domain and be able to address
potential issues than worry about whether an attacker will have the same
information.  In fact, in the same spirit as assuming an attacker has
knowledge of a cryptographic algorithm when designing it, we should
assume that an attacker knows our configurations.

So, I suppose the question still stands to the larger group as well,
though modified: Has anyone considered backing an open-source,
cross-platform interface for housing CPE information on a host?  Put
another way, should we seek the devil in those details or not?

Adam

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA
[mailto:[hidden email]]
Sent: Monday, November 01, 2010 4:38 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking about this over the weekend.

First thought -- Shouldn't this be done as an SNMP MIB?
Second thought -- What would the security considerations be?  Seems like
a full CPE/update dump is pretty much one stop (via the NVD) away from a
full vulnerability enumeration and would be pretty sensitive.
Third thought -- Based on my (limited) experience with the IANA guys,
registering a new port is really difficult.

Reservations aside, I like the thought.  It would be a big win if CPE
were incorporated into a standardized interface to output installed
software and patches.  The devil, of course, is in the details.  


Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: Adam W. Montville [mailto:[hidden email]]
Sent: Friday, October 29, 2010 7:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Has anyone ever considered opening up development to a CPE repository
service that could be made available to primary platform vendors (i.e.
Operating system vendors) that would listen on a certain port (say 273)
and
report it's installation configuration?

In this way, a scanner would be able to discover a host, connect to and
interrogate that host on 273 to determine it's complete configuration
based
on CPE names.

Regards,

Adam


On 10/29/10 1:07 PM, "Thomas Jones" <[hidden email]>
wrote:

> Hello Joseph,
>
> I have been down the road you are currently traversing. I performed a
> very similiar generation script using bash for the Novell suite of
> products.
>
> I am currently developing a perl implementation for deriving entire
> oval inventory and cpe sources.
>
> Let me know if you want to collaborate. Cheers.
>
> Thomas
>
> Sent from my iPhone
>
> On Oct 29, 2010, at 2:41 PM, "WOLFKIEL, JOSEPH L CIV DISA PEO-MA"
> <[hidden email]
>> wrote:
>
>> Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> All,
>>
>> I've been working more on the concept of converting registry-
>> equivalent entries for discovered product names into CPE format.
>>
>> My last attempt was to take a dump off of one of our lab Red Hat
>> machines and attempt to convert the installed packages into CPE-
>> compliant names using an automatable process.
>>
>> Here's what I came up with:
>>
>> The original file, redhat inventory.txt has names pulled from RPM in
>> pipe-delimited format.  If I understand the structure right, you get
>> the application name, distributor, version, release, target
>> microprocessor architecture, and the package number.  I took the
>> values and made my best guess at where everything should go during a
>> conversion into CPE.  The file "linuxcpenames.txt" shows the CPE
>> equivalent output.
>>
>> I didn't run the full lookup table to convert everything, so there
>> are still upper case letters and some unconverted symbols, but I
>> think it's obvious how that would be taken care of.
>>
>> What I'd like to focus on are the less obvious issues.  Specifically:
>> - Should the "Red_Hat,_Inc." be in the vendor field, or in the
>> target software field?  If I put it in the vendor field, it's
>> obviously incorrect in several cases (e.g. the vendor for Python
>> isn't Red Hat)
>> - Does "release" go in the version field?
>> - I substituted "-" for "noarch".  Is that right?
>> - I put the package data into the edition "other" field.  Should it
>> go there?  If it does, should there be a tag associated with it
>> (e.g. pkg_eq__)?
>>
>> These issues don't seem unsolvable, but they do illustrate the need
>> for some sort of community common practice for how to deal with the
>> different name components maintained by each operating system.
>>
>> I appreciate any feedback.  Is anyone else working on this?  What
>> heuristics are you using?
>>
>> Joseph L. Wolfkiel
>> Engineering Group Lead
>> DISA PEO MA/IA52
>> (703) 882-0772
>> [hidden email]
>>    Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> <linuxcpenames.txt>
>> <redhat_inventory.txt>
>
Adam Montville, CISSP | Security and Compliance Solutions Program
Manager
Direct: 503.276.7661
Mobile: 360.471.7815
 
TRIPWIRE | The Leader in IT Security & Compliance Software
http://www.tripwire.com
Classification:  UNCLASSIFIED
Caveats: NONE

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

Adam Montville
That makes sense, TK.  Perhaps I'm late to the overall CPE discussion...
It seems that if we can make our lives easier when we do have nodes
under management that we might try to do so.  If there's a way to fail
gracefully while at the same time learning from those failures, then the
system will only become better at what it does - figure out what the
end-point is so it can do something with it (configure it, secure it,
assess it, patch it).

Am I incorrect in saying that XML alone wouldn't get us where we need to
go with CPE if this is an approach we want to take?  

Adam


-----Original Message-----
From: Tim Keanini [mailto:[hidden email]]
Sent: Monday, November 01, 2010 3:03 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

The problem with a service or even the concept of SNMP is the notion of
a
'node under management'.
While this concept makes perfect sense for those end-points that are
under-management, we are dealing with a namespace that must consider the
set
of end-points not under-management.  For this reason, I am not a huge
fan of
an application service specific to this type of inquiry and much more
biased
toward an approach that would try and make sense of what is the
end-points
natural operational state.  I think what Joe is asking is given certain
end-point defaults states, how can one derive useful CPE names that are
stable and useful across vendor boundaries.  

Joe, I'm not sure we will ever get this perfect because there will
always be
exceptions in the names that are "wrong" so maybe a strategy that would
give
the asserted name enough context.  All of my examples here would be in
RDF
but any way to represent metadata would suffice.  If something is wrong
consistently than provided enough context to the data the data consumers
can
compensate.

--tk

-----Original Message-----
From: Adam Montville [mailto:[hidden email]]
Sent: Monday, November 01, 2010 4:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM
entries into CPE Names (UNCLASSIFIED)

SNMP MIB wouldn't be bad (frankly, any way to leave the chicken/egg
problem behind).

As far as a one-stop-shop of sensitive information, well, yes it could
be.  But, which scenario is worse: The bad guys know our vulnerabilities
better than we do, or we know our vulnerabilities just as well as the
bad guys?

I'd rather know about everything in my domain and be able to address
potential issues than worry about whether an attacker will have the same
information.  In fact, in the same spirit as assuming an attacker has
knowledge of a cryptographic algorithm when designing it, we should
assume that an attacker knows our configurations.

So, I suppose the question still stands to the larger group as well,
though modified: Has anyone considered backing an open-source,
cross-platform interface for housing CPE information on a host?  Put
another way, should we seek the devil in those details or not?

Adam

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA
[mailto:[hidden email]]
Sent: Monday, November 01, 2010 4:38 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking about this over the weekend.

First thought -- Shouldn't this be done as an SNMP MIB?
Second thought -- What would the security considerations be?  Seems like
a full CPE/update dump is pretty much one stop (via the NVD) away from a
full vulnerability enumeration and would be pretty sensitive.
Third thought -- Based on my (limited) experience with the IANA guys,
registering a new port is really difficult.

Reservations aside, I like the thought.  It would be a big win if CPE
were incorporated into a standardized interface to output installed
software and patches.  The devil, of course, is in the details.  


Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: Adam W. Montville [mailto:[hidden email]]
Sent: Friday, October 29, 2010 7:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Has anyone ever considered opening up development to a CPE repository
service that could be made available to primary platform vendors (i.e.
Operating system vendors) that would listen on a certain port (say 273)
and
report it's installation configuration?

In this way, a scanner would be able to discover a host, connect to and
interrogate that host on 273 to determine it's complete configuration
based
on CPE names.

Regards,

Adam


On 10/29/10 1:07 PM, "Thomas Jones" <[hidden email]>
wrote:

> Hello Joseph,
>
> I have been down the road you are currently traversing. I performed a
> very similiar generation script using bash for the Novell suite of
> products.
>
> I am currently developing a perl implementation for deriving entire
> oval inventory and cpe sources.
>
> Let me know if you want to collaborate. Cheers.
>
> Thomas
>
> Sent from my iPhone
>
> On Oct 29, 2010, at 2:41 PM, "WOLFKIEL, JOSEPH L CIV DISA PEO-MA"
> <[hidden email]
>> wrote:
>
>> Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> All,
>>
>> I've been working more on the concept of converting registry-
>> equivalent entries for discovered product names into CPE format.
>>
>> My last attempt was to take a dump off of one of our lab Red Hat
>> machines and attempt to convert the installed packages into CPE-
>> compliant names using an automatable process.
>>
>> Here's what I came up with:
>>
>> The original file, redhat inventory.txt has names pulled from RPM in
>> pipe-delimited format.  If I understand the structure right, you get
>> the application name, distributor, version, release, target
>> microprocessor architecture, and the package number.  I took the
>> values and made my best guess at where everything should go during a
>> conversion into CPE.  The file "linuxcpenames.txt" shows the CPE
>> equivalent output.
>>
>> I didn't run the full lookup table to convert everything, so there
>> are still upper case letters and some unconverted symbols, but I
>> think it's obvious how that would be taken care of.
>>
>> What I'd like to focus on are the less obvious issues.  Specifically:
>> - Should the "Red_Hat,_Inc." be in the vendor field, or in the
>> target software field?  If I put it in the vendor field, it's
>> obviously incorrect in several cases (e.g. the vendor for Python
>> isn't Red Hat)
>> - Does "release" go in the version field?
>> - I substituted "-" for "noarch".  Is that right?
>> - I put the package data into the edition "other" field.  Should it
>> go there?  If it does, should there be a tag associated with it
>> (e.g. pkg_eq__)?
>>
>> These issues don't seem unsolvable, but they do illustrate the need
>> for some sort of community common practice for how to deal with the
>> different name components maintained by each operating system.
>>
>> I appreciate any feedback.  Is anyone else working on this?  What
>> heuristics are you using?
>>
>> Joseph L. Wolfkiel
>> Engineering Group Lead
>> DISA PEO MA/IA52
>> (703) 882-0772
>> [hidden email]
>>    Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> <linuxcpenames.txt>
>> <redhat_inventory.txt>
>

Adam Montville, CISSP | Security and Compliance Solutions Program
Manager
Direct: 503.276.7661
Mobile: 360.471.7815
 
TRIPWIRE | The Leader in IT Security & Compliance Software
http://www.tripwire.com
Classification:  UNCLASSIFIED
Caveats: NONE
Reply | Threaded
Open this post in threaded view
|

Re: Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

Actually, I want it all.  The examples I initially sent out to the list came from nodes that are "under management", so I could run the right scripts/queries on them.  For non-managed systems, we have sensors that try to figure out what a device looks like based on external indicators.  Both cases drive a need to match discovered software names against a list of standardized names.

I suggested CPE interfaces for systems under management use SNMP because the community that governs SNMP has already dealt with getting standard ports and building in strong authentication (SNMPv3), which can be leveraged out-of-the-box.  After studying up on the process required to discover "installed" applications on Windows 7, I can certainly see the value of having a single, uniform external or internal API that will provide a comprehensive list of installed software and updates.

Since we'll continue to have mixes of managed and unmanaged systems indefinitely, some CPE process will have to deal gracefully with the data we obtain from both.


Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: Adam Montville [mailto:[hidden email]]
Sent: Monday, November 01, 2010 8:20 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux RPM entries into CPE Names (UNCLASSIFIED)

That makes sense, TK.  Perhaps I'm late to the overall CPE discussion...
It seems that if we can make our lives easier when we do have nodes
under management that we might try to do so.  If there's a way to fail
gracefully while at the same time learning from those failures, then the
system will only become better at what it does - figure out what the
end-point is so it can do something with it (configure it, secure it,
assess it, patch it).

Am I incorrect in saying that XML alone wouldn't get us where we need to
go with CPE if this is an approach we want to take?  

Adam


-----Original Message-----
From: Tim Keanini [mailto:[hidden email]]
Sent: Monday, November 01, 2010 3:03 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

The problem with a service or even the concept of SNMP is the notion of
a
'node under management'.
While this concept makes perfect sense for those end-points that are
under-management, we are dealing with a namespace that must consider the
set
of end-points not under-management.  For this reason, I am not a huge
fan of
an application service specific to this type of inquiry and much more
biased
toward an approach that would try and make sense of what is the
end-points
natural operational state.  I think what Joe is asking is given certain
end-point defaults states, how can one derive useful CPE names that are
stable and useful across vendor boundaries.  

Joe, I'm not sure we will ever get this perfect because there will
always be
exceptions in the names that are "wrong" so maybe a strategy that would
give
the asserted name enough context.  All of my examples here would be in
RDF
but any way to represent metadata would suffice.  If something is wrong
consistently than provided enough context to the data the data consumers
can
compensate.

--tk

-----Original Message-----
From: Adam Montville [mailto:[hidden email]]
Sent: Monday, November 01, 2010 4:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM
entries into CPE Names (UNCLASSIFIED)

SNMP MIB wouldn't be bad (frankly, any way to leave the chicken/egg
problem behind).

As far as a one-stop-shop of sensitive information, well, yes it could
be.  But, which scenario is worse: The bad guys know our vulnerabilities
better than we do, or we know our vulnerabilities just as well as the
bad guys?

I'd rather know about everything in my domain and be able to address
potential issues than worry about whether an attacker will have the same
information.  In fact, in the same spirit as assuming an attacker has
knowledge of a cryptographic algorithm when designing it, we should
assume that an attacker knows our configurations.

So, I suppose the question still stands to the larger group as well,
though modified: Has anyone considered backing an open-source,
cross-platform interface for housing CPE information on a host?  Put
another way, should we seek the devil in those details or not?

Adam

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA
[mailto:[hidden email]]
Sent: Monday, November 01, 2010 4:38 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking about this over the weekend.

First thought -- Shouldn't this be done as an SNMP MIB?
Second thought -- What would the security considerations be?  Seems like
a full CPE/update dump is pretty much one stop (via the NVD) away from a
full vulnerability enumeration and would be pretty sensitive.
Third thought -- Based on my (limited) experience with the IANA guys,
registering a new port is really difficult.

Reservations aside, I like the thought.  It would be a big win if CPE
were incorporated into a standardized interface to output installed
software and patches.  The devil, of course, is in the details.  


Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: Adam W. Montville [mailto:[hidden email]]
Sent: Friday, October 29, 2010 7:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automated conversion of Red Hat Linux
RPM entries into CPE Names (UNCLASSIFIED)

Has anyone ever considered opening up development to a CPE repository
service that could be made available to primary platform vendors (i.e.
Operating system vendors) that would listen on a certain port (say 273)
and
report it's installation configuration?

In this way, a scanner would be able to discover a host, connect to and
interrogate that host on 273 to determine it's complete configuration
based
on CPE names.

Regards,

Adam


On 10/29/10 1:07 PM, "Thomas Jones" <[hidden email]>
wrote:

> Hello Joseph,
>
> I have been down the road you are currently traversing. I performed a
> very similiar generation script using bash for the Novell suite of
> products.
>
> I am currently developing a perl implementation for deriving entire
> oval inventory and cpe sources.
>
> Let me know if you want to collaborate. Cheers.
>
> Thomas
>
> Sent from my iPhone
>
> On Oct 29, 2010, at 2:41 PM, "WOLFKIEL, JOSEPH L CIV DISA PEO-MA"
> <[hidden email]
>> wrote:
>
>> Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> All,
>>
>> I've been working more on the concept of converting registry-
>> equivalent entries for discovered product names into CPE format.
>>
>> My last attempt was to take a dump off of one of our lab Red Hat
>> machines and attempt to convert the installed packages into CPE-
>> compliant names using an automatable process.
>>
>> Here's what I came up with:
>>
>> The original file, redhat inventory.txt has names pulled from RPM in
>> pipe-delimited format.  If I understand the structure right, you get
>> the application name, distributor, version, release, target
>> microprocessor architecture, and the package number.  I took the
>> values and made my best guess at where everything should go during a
>> conversion into CPE.  The file "linuxcpenames.txt" shows the CPE
>> equivalent output.
>>
>> I didn't run the full lookup table to convert everything, so there
>> are still upper case letters and some unconverted symbols, but I
>> think it's obvious how that would be taken care of.
>>
>> What I'd like to focus on are the less obvious issues.  Specifically:
>> - Should the "Red_Hat,_Inc." be in the vendor field, or in the
>> target software field?  If I put it in the vendor field, it's
>> obviously incorrect in several cases (e.g. the vendor for Python
>> isn't Red Hat)
>> - Does "release" go in the version field?
>> - I substituted "-" for "noarch".  Is that right?
>> - I put the package data into the edition "other" field.  Should it
>> go there?  If it does, should there be a tag associated with it
>> (e.g. pkg_eq__)?
>>
>> These issues don't seem unsolvable, but they do illustrate the need
>> for some sort of community common practice for how to deal with the
>> different name components maintained by each operating system.
>>
>> I appreciate any feedback.  Is anyone else working on this?  What
>> heuristics are you using?
>>
>> Joseph L. Wolfkiel
>> Engineering Group Lead
>> DISA PEO MA/IA52
>> (703) 882-0772
>> [hidden email]
>>    Classification:  UNCLASSIFIED
>> Caveats: NONE
>>
>> <linuxcpenames.txt>
>> <redhat_inventory.txt>
>
Adam Montville, CISSP | Security and Compliance Solutions Program
Manager
Direct: 503.276.7661
Mobile: 360.471.7815
 
TRIPWIRE | The Leader in IT Security & Compliance Software
http://www.tripwire.com
Classification:  UNCLASSIFIED
Caveats: NONE
Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (7K) Download Attachment