API -> CPE map

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

API -> CPE map

Andrew Buttner
Administrator
After talking with a vendor recently, an idea was presented that I have heard in the past.  I think the time might be right to make it happen.  In short, the creation of a shared map between the return of certain API calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information that a system might return and the official CPE Name.  Without this information, a manual map would have to be performed.  Hopefully this would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE site.  The format for this file will evolve over time as we learn more about it.  Right now I am thinking about something quick and dirty.  Any thoughts as to how to initially set this up?  For some CPE Names it might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Gary Newman-2
This sounds like a very limited form of "Aliases" that was proposed
in the past.  Why is a single alias worth supporting, when multiple
aliases is not?

Supporting multiple such aliases would greatly benefit CPE.

Are you thinking of OS CPE Names, or applications too?

Perhaps you could let us in on which API calls you're talking about.

        -Gary-

> After talking with a vendor recently, an idea was presented that I
> have heard in the past.  I think the time might be right to make it
> happen.  In short, the creation of a shared map between the return of
> certain API calls and the CPE Name that the value would map to.
>
> This would help anyone who is trying to move between the information
> that a system might return and the official CPE Name.  Without this
> information, a manual map would have to be performed.  Hopefully this
> would help make it easier for vendors to add CPE to their tools.
>
> The plan for now would be to just create a file and post it on the CPE
> site.  The format for this file will evolve over time as we learn more
> about it.  Right now I am thinking about something quick and dirty.
> Any thoughts as to how to initially set this up?  For some CPE Names
> it might be a collection of CPE Name?
>
> Thoughts about this idea?  Would it be helpful?
>
> Thanks
> Drew
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Andrew Buttner
Administrator
I agree that this is close to the idea of aliasing and maybe this can be the start of it.  I also see no reason why we have to limit it to one alias.  Hopefully this can be a huge help to the community.

My guess is that both os and app name could benefit, and I wouldn't want to limit it to one or the other.  I wouldn't be surprised if one area received more focus in the beginning, but that will be determined with time.

I personally don't know which API's would be important.  I am looking for the community's help here.  Basically, I will help try and bring the community together on this and help merge data that is sent to me.  I'm sure there will be a few bumps to start with.

Thanks
Drew


>-----Original Message-----
>From: Gary Newman [mailto:[hidden email]]
>Sent: Monday, April 13, 2009 12:49 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>This sounds like a very limited form of "Aliases" that was proposed
>in the past.  Why is a single alias worth supporting, when multiple
>aliases is not?
>
>Supporting multiple such aliases would greatly benefit CPE.
>
>Are you thinking of OS CPE Names, or applications too?
>
>Perhaps you could let us in on which API calls you're talking about.
>
>        -Gary-
>
>> After talking with a vendor recently, an idea was presented that I
>> have heard in the past.  I think the time might be right to make it
>> happen.  In short, the creation of a shared map between the return of
>> certain API calls and the CPE Name that the value would map to.
>>
>> This would help anyone who is trying to move between the information
>> that a system might return and the official CPE Name.  Without this
>> information, a manual map would have to be performed.  Hopefully this
>> would help make it easier for vendors to add CPE to their tools.
>>
>> The plan for now would be to just create a file and post it on the CPE
>> site.  The format for this file will evolve over time as we learn more
>> about it.  Right now I am thinking about something quick and dirty.
>> Any thoughts as to how to initially set this up?  For some CPE Names
>> it might be a collection of CPE Name?
>>
>> Thoughts about this idea?  Would it be helpful?
>>
>> Thanks
>> Drew
>>
>> ---------
>>
>> Andrew Buttner
>> The MITRE Corporation
>> [hidden email]
>> 781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Sudhir Gandhe-3
I agree that this would benefit both OS and Applications. The problem we are currently facing to generate official dictionary CPEs with the asset inventory stuff will be solved with this alias list.

Most vendors gather application inventory from the Microsoft Installer APIs, there are other ways too. Perhaps we can have a "comments" tag for each alias to describe the way the alias was generated. This could start as a separate data files and could be merged with the CPE specification later. This will enable the vendors to implement the CPE standard in their tools. We at Telos are willing to share our alias mapping list in XML or Text format, as desired.




Regards,
Sudhir

Sudhir Gandhe

Telos Corporation




On Mon, Apr 13, 2009 at 12:54 PM, Buttner, Drew <[hidden email]> wrote:
I agree that this is close to the idea of aliasing and maybe this can be the start of it.  I also see no reason why we have to limit it to one alias.  Hopefully this can be a huge help to the community.

My guess is that both os and app name could benefit, and I wouldn't want to limit it to one or the other.  I wouldn't be surprised if one area received more focus in the beginning, but that will be determined with time.

I personally don't know which API's would be important.  I am looking for the community's help here.  Basically, I will help try and bring the community together on this and help merge data that is sent to me.  I'm sure there will be a few bumps to start with.

Thanks
Drew


>-----Original Message-----
>From: Gary Newman [mailto:[hidden email]]
>Sent: Monday, April 13, 2009 12:49 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>This sounds like a very limited form of "Aliases" that was proposed
>in the past.  Why is a single alias worth supporting, when multiple
>aliases is not?
>
>Supporting multiple such aliases would greatly benefit CPE.
>
>Are you thinking of OS CPE Names, or applications too?
>
>Perhaps you could let us in on which API calls you're talking about.
>
>        -Gary-
>
>> After talking with a vendor recently, an idea was presented that I
>> have heard in the past.  I think the time might be right to make it
>> happen.  In short, the creation of a shared map between the return of
>> certain API calls and the CPE Name that the value would map to.
>>
>> This would help anyone who is trying to move between the information
>> that a system might return and the official CPE Name.  Without this
>> information, a manual map would have to be performed.  Hopefully this
>> would help make it easier for vendors to add CPE to their tools.
>>
>> The plan for now would be to just create a file and post it on the CPE
>> site.  The format for this file will evolve over time as we learn more
>> about it.  Right now I am thinking about something quick and dirty.
>> Any thoughts as to how to initially set this up?  For some CPE Names
>> it might be a collection of CPE Name?
>>
>> Thoughts about this idea?  Would it be helpful?
>>
>> Thanks
>> Drew
>>
>> ---------
>>
>> Andrew Buttner
>> The MITRE Corporation
>> [hidden email]
>> 781-271-3515

Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Tim Keanini
In reply to this post by Andrew Buttner
Question 1: What is meant by API in this context?  What is the target
API and who is calling it?  Sounds like a massive information space to
be exploring and highly dynamic.

Question 2: While this might be a good idea initially, has anyone
thought about the long term costs in maintaining this method? Or if it
is "short term", what happens when we can say it is no longer short term
and we have to deal with the long term problem space?  It seems to be a
n(n-1)/2 or something close to it because the term vendor includes
vendors who speak authoritatively over their own CPE and other vendors
who speak beyond their CPE and about other vendors CPEs.  

I'm willing to participate in this effort, I just need to understand the
value today and then long term.

--tk

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, April 13, 2009 8:33 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] API -> CPE map

After talking with a vendor recently, an idea was presented that I have
heard in the past.  I think the time might be right to make it happen.
In short, the creation of a shared map between the return of certain API
calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information
that a system might return and the official CPE Name.  Without this
information, a manual map would have to be performed.  Hopefully this
would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE
site.  The format for this file will evolve over time as we learn more
about it.  Right now I am thinking about something quick and dirty.  Any
thoughts as to how to initially set this up?  For some CPE Names it
might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Ernest Park-2
could I suggest that CPE try to be a name, and nothing more?

If we agree on the string identifiers for software applications, then vendors, application and service developers will extend the capability of a CPE name. It is the service and product providers that can resolve a CPE string to extended metadata beyond what CPE is.

In this way, the community evolves CPE. If CPE tries to be everything, it becomes the competitor of innovation. It also likely fails at doing any one thing well.

Aliases. Let's have many of them - who cares. Let vendors extend aliases.

If CPE focuses on the core descriptor, everyone else can focus on adding extra content, both proprietary and open. In this way, CPE will serve its purpose to be a single descriptor for software packages. Additionally, nothing more is needed in a CPE provided API than the validation of a CPE name structure and possibly the existence of such a name in the current dictionary. 

Beyond that, third parties can use the name structure as "the API", and then extend what they can deliver against that string.




On Mon, Apr 13, 2009 at 10:56 PM, Tim Keanini <[hidden email]> wrote:
Question 1: What is meant by API in this context?  What is the target
API and who is calling it?  Sounds like a massive information space to
be exploring and highly dynamic.

Question 2: While this might be a good idea initially, has anyone
thought about the long term costs in maintaining this method? Or if it
is "short term", what happens when we can say it is no longer short term
and we have to deal with the long term problem space?  It seems to be a
n(n-1)/2 or something close to it because the term vendor includes
vendors who speak authoritatively over their own CPE and other vendors
who speak beyond their CPE and about other vendors CPEs.

I'm willing to participate in this effort, I just need to understand the
value today and then long term.

--tk

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, April 13, 2009 8:33 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] API -> CPE map

After talking with a vendor recently, an idea was presented that I have
heard in the past.  I think the time might be right to make it happen.
In short, the creation of a shared map between the return of certain API
calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information
that a system might return and the official CPE Name.  Without this
information, a manual map would have to be performed.  Hopefully this
would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE
site.  The format for this file will evolve over time as we learn more
about it.  Right now I am thinking about something quick and dirty.  Any
thoughts as to how to initially set this up?  For some CPE Names it
might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

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

Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Andrew Buttner
Administrator
In reply to this post by Tim Keanini
>Question 1: What is meant by API in this context?  What is the target
>API and who is calling it?  Sounds like a massive information space to
>be exploring and highly dynamic.

What I had in mind is some type of mapping file that supported users trying to create a map from their internal name to a CPE Name.  It was suggested that one way to do this would be to map the return values of certain API's as it is these return values that are often used by system inventory applications.

For example, say there is an API GetInstalledApps().  This might return "ACME Tool 3.4".  Our file would contain:

GetInstalledApps - ACME Tool 3.4 - cpe:/a:acme:tool:3.4

I agree that this is a massive information space, but the thinking is that even if we only map a small portion of it, that small portion could be useful to some.



>Question 2: While this might be a good idea initially, has anyone
>thought about the long term costs in maintaining this method? Or if it
>is "short term", what happens when we can say it is no longer short term
>and we have to deal with the long term problem space?  It seems to be a
>n(n-1)/2 or something close to it because the term vendor includes
>vendors who speak authoritatively over their own CPE and other vendors
>who speak beyond their CPE and about other vendors CPEs.

I would say that this is a short term idea.  Basically, anyone that currently wants to use CPE has to go through a manual process to map their internal product list to CPE, so this work has to be done anyway.

I think the long term solution has to be a new version of CPE or a new standard.  (unless vendors start using CPE as their output)



>I'm willing to participate in this effort, I just need to understand the
>value today and then long term.

Did this answer the questions?

Basically, for anyone that wants to help with this effort, what we are looking to do is compile all the different maps that the community might have already done and publish it to help others get started.  (hopefully those that contribute will also benefit by leveraging maps from others)  Note that only maps to externally available references will be of any use.

Thanks
Drew
Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Andrew Buttner
Administrator
In reply to this post by Sudhir Gandhe-3
>We at Telos are willing to share our alias mapping list in
>XML or Text format, as desired.

Would a good first step be to send something out in whatever format you have and then see what is included.  From there we can determine if we need to transform the format.  One outstanding question I have is how to handle name that are generated from multiple different APIs.  For example:

GetOsVersion() = ACME OS 2.3
GetOsEdition() = Desktop

CPE Name = cpe:/o:acme:os:2.3:-:desktop

Thoughts?

Thanks
Drew
Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Andrew Buttner
Administrator
In reply to this post by Ernest Park-2
>-----Original Message-----
>From: Ernest Park [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 1:21 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>could I suggest that CPE try to be a name, and nothing more?

I think this is what we are trying to do.  We are on the same page here.



>If we agree on the string identifiers for software applications, then
>vendors, application and service developers will extend the capability
>of a CPE name. It is the service and product providers that can resolve
>a CPE string to extended metadata beyond what CPE is.

Yes!


Our hope with this thread is that we can jump start the adoption of CPE by all pitching in on the biggest barrier to entry - the manual map.  We believe that everyone will benefit from helping with this as everyone will benefit once CPE gains more traction.  (for all the reasons Ernest pointed out)

Thanks
Drew
Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Ernest Park-2
btw - it seems that the report you want  could be had if you encourage companies like Symantec, McAfee, Palamida, Blackduck and others to output discovered inventory information as CPE data.

The "query" API as delineated herein should be generalized, such that any CPE compliant system can either return a CPE structured name, or resolve a name within a structured query with additional proprietary and community data, such as . . .


select * from my.cpe.database where cpename like 'cpe:/a:vendor:product';



therefore, a vendor would have to have an alias table representing the component parts of CPE names as a single string, but each part joined into the metadata relevant for the vendor.

This way, I avoid an API, but can still integrate data from Symantec, Palamida and McAfee if I know that I share common name syntaxes. Beyond that, each vendor delivers additional proprietary data, thereby allowing customers to use the CPE name as an integration point.




My company has done a lot of this work if anyone is curious.



On Wed, Apr 15, 2009 at 3:46 PM, Buttner, Drew <[hidden email]> wrote:
>-----Original Message-----
>From: Ernest Park [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 1:21 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>could I suggest that CPE try to be a name, and nothing more?

I think this is what we are trying to do.  We are on the same page here.



>If we agree on the string identifiers for software applications, then
>vendors, application and service developers will extend the capability
>of a CPE name. It is the service and product providers that can resolve
>a CPE string to extended metadata beyond what CPE is.

Yes!


Our hope with this thread is that we can jump start the adoption of CPE by all pitching in on the biggest barrier to entry - the manual map.  We believe that everyone will benefit from helping with this as everyone will benefit once CPE gains more traction.  (for all the reasons Ernest pointed out)

Thanks
Drew

Reply | Threaded
Open this post in threaded view
|

Re: API -> CPE map

Maneesh Jolly

In the current scenario, every vendor might be having his own method of identifying OS or Application. They might not be storing the return values of the API used to identify the application. Lets consider the case Microsoft windows OS only for now.

Vendor A might have a function that use the API’s (GetSystemInfo, GetVersionEx etc) to generate one identifier for that OS type but vendor B might be generating 2 identifier that are combined to identify the OS type.

The best method would have been for the vendor to associate CPE id with their internal Id, but this of course is not at all going to help the progress of CPE effort.

 

Now mapping API with CPE Id as suggested by Drew can be done, but then we need to remember that we might have to logically combine return values of several APIs to map it to CPE Id. This will be quite similar to associating an OVAL definition Id with a CPE identifier.

 


From: Ernest Park [mailto:[hidden email]]
Sent: Thursday, April 16, 2009 1:35 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map

 

btw - it seems that the report you want  could be had if you encourage companies like Symantec, McAfee, Palamida, Blackduck and others to output discovered inventory information as CPE data.

 

The "query" API as delineated herein should be generalized, such that any CPE compliant system can either return a CPE structured name, or resolve a name within a structured query with additional proprietary and community data, such as . . .

 

 

select * from my.cpe.database where cpename like 'cpe:/a:vendor:product';

 

 

 

therefore, a vendor would have to have an alias table representing the component parts of CPE names as a single string, but each part joined into the metadata relevant for the vendor.

 

This way, I avoid an API, but can still integrate data from Symantec, Palamida and McAfee if I know that I share common name syntaxes. Beyond that, each vendor delivers additional proprietary data, thereby allowing customers to use the CPE name as an integration point.

 

 

 

 

My company has done a lot of this work if anyone is curious.

 

 

On Wed, Apr 15, 2009 at 3:46 PM, Buttner, Drew <[hidden email]> wrote:

>-----Original Message-----
>From: Ernest Park [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 1:21 PM
>To: cpe-discussion-list CPE Community Forum

>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>could I suggest that CPE try to be a name, and nothing more?

I think this is what we are trying to do.  We are on the same page here.



>If we agree on the string identifiers for software applications, then
>vendors, application and service developers will extend the capability
>of a CPE name. It is the service and product providers that can resolve
>a CPE string to extended metadata beyond what CPE is.

Yes!


Our hope with this thread is that we can jump start the adoption of CPE by all pitching in on the biggest barrier to entry - the manual map.  We believe that everyone will benefit from helping with this as everyone will benefit once CPE gains more traction.  (for all the reasons Ernest pointed out)

Thanks
Drew