Utilizing the Enumerations in the OVAL Repository

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

Utilizing the Enumerations in the OVAL Repository

Jon Baker
Administrator
At the Security Automation Developer Days this week we began a discussion about the OVAL Repository, but ran short on time. I had planned to go over three current issues with the OVAL Repository. Here are the issues I had in mind:

- Utilizing the Enumerations in the OVAL Repository
- hosting test content in the repository
- consistent usage of affected platforms and products

In this message I will review the first item. I will write separate messages to start conversations on the other two topics.

Utilizing the Enumerations in the OVAL Repository:
The OVAL Repository has required all vulnerability class definitions to have a cve reference and to use the cve description as the description of the definition. This convention allows us to leverage cve for correlation across all sort of security advisories and other information related to the vulnerability the definition is written for.

Should we follow the same pattern of usage for CCE and CPE?

Should we decide on a convention that states something like all inventory class definitions must include a CPE reference? If we adopt this convention we would shift all definitions that are currently in the inventory class that are not candidates for cpe names into the miscellaneous class. By way of example the definition that checks for windows xp sp2 or later is currently in the inventory class. There is no cpe name that aligns with sp2 or later so this definition would be moved to the inventory class.

Similarly should we decide on a convention that states that all compliance class definitions must include a cce reference? Here to we would move any definition that does not align with the intent of CCE into the miscellaneous class.

If we adopt these two conventions we will be able to establish a very high level of consistence in the usage of references in the oval repository. This will make verifying quality content in the repository more automatable, and show clear support for these enumerations as the way to uniquely identify the thing that a given definition is checking for.

So should we move forward with these conventions?

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing the Enumerations in the OVAL Repository

Dandurand Luc
All,

I would like to provide the following point of view on this issue as a result of recent experimentation we have performed using both CPE and CVE, amongst other technologies. I may be wrong, but I see pitfalls in what you are proposing.

While both standards are considered "enumerations", CPE is not the same kind of enumeration as CVE. The domain of CVE is a simple one. CVE enumerates the same kind of things: vulnerabilities. And while vulnerabilities differ in their characteristics, they are mutually exclusive, atomic elements. So a CVE number identifies a single, unique vulnerability. The domain of CPE is far more complex, as it encompasses a very diverse set of elements, which are neither mutually exclusive nor atomic because of the way the standard was designed. The standard defines a structure for CPE Names that allows users to omit some of the components to indicate "any value". This allows CPE users to wildcard parts of CPE names so that a single entry can refer to a number of items. This means that CPE operates at various levels of abstraction: a CPE Name can pinpoint an operating system down to the language and patch level, and another can identify a family of operating systems, depending on how the user chooses to use it. These are two very different elements, and this will never happen in CVE. It also doesn't always protect against the impact of future CPE names. When a group is defined by a single CPE Name, its membership will change as new CPE Names that match the group CPE Name are created, so the semantic meaning of the CPE Name will change over time. Again, this never happens with CVE... Finally, even if you use fully qualified CPE Names, it may not be sufficiently specific for your purposes because of the complexity of uniquely identifying something as complex and fluid as an operating system.

Now I sincerely believe that the ability to work at various levels of abstraction is a great feature of CPE. But in what you are proposing, as worded, it poses a problem. The fact is, CPE is a completely different beast than CVE, and so it has to be used differently. I am not saying that it can't be used for the purpose you describe below, but how you use it for that purpose will be very different than how you use CVE for the equivalent purpose in the domain of vulnerabilities.

Finally, just to be clear, I believe that those who wrote the standard understand this, as they have written about it in the specification, as can be seen from the following extract:
"Each CPE Name defines a set of platform types. Another way of thinking about a CPE Name is that it identifies a bucket of related platform types. How each bucket relates to an external entity is beyond the scope of CPE, and is something that the data producer should define. All CPE is trying to do is define these buckets and present a common name for each. For example, consider two security configuration guides for Windows XP each written by a different producer. One producer may choose to tag the guide with the union of all CPEs for all known versions of XP for which the guide applies, with the expectation of updating the CPE tags as appropriate if/when new versions of XP become available. But the other producer may choose to tag the guide with "Windows XP", despite the fact that the guide does not apply to some current or future versions of Windows XP. Both approaches are consistent with the CPE specification, but what can be assumed by users about the relationship between the guides and certain platform types is very different. The user must obtain this information from the guide author."

I will highlight the key words in UPPER CASE: "How each bucket relates to an external entity is BEYOND THE SCOPE OF CPE, and is something that the DATA PRODUCER SHOULD DEFINE." And: "but WHAT CAN BE ASSUMED BY USERS about the relationship between the guides and certain platform types IS VERY DIFFERENT. The USER MUST OBTAIN THIS INFORMATION from the guide author."

What the authors are trying to say became much clearer to us during our experimentation. We were trying to use CPE like we were using CVE. We had great success with CVE, but we realized CPE was a completely different thing. To make CPE work for us, we would have had to specify how the standard was to be used in our system and impose it to all our data producers and consumers. At that point, we would have been using CPE in our own specific way, and we would have lost the very interoperability we were looking for in the use of a common enumeration...

Once again, I believe CPE has its place and is a very good standard, and I am by no means trying to put it down as a solution to your problem. I am just saying that to successfully achieve what you propose below will be much more difficult than it is with vulnerabilities. It will require detailed instructions on how to use CPE Names in the context of OVAL for both providers and consumers of OVAL definitions, and it will be difficult at least initially. Too difficult? I really don't know...

Just my humble opinion based on my limited understanding of CPE and our limited experimentation, for your consideration...

(PS: I have no experience with CCE, so I cannot comment...)

Luc Dandurand

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Thu 11 Jun 2009 15:32
To: [hidden email]
Subject: [OVAL-DISCUSSION-LIST] Utilizing the Enumerations in the OVAL Repository

At the Security Automation Developer Days this week we began a discussion about the OVAL Repository, but ran short on time. I had planned to go over three current issues with the OVAL Repository. Here are the issues I had in mind:

- Utilizing the Enumerations in the OVAL Repository
- hosting test content in the repository
- consistent usage of affected platforms and products

In this message I will review the first item. I will write separate messages to start conversations on the other two topics.

Utilizing the Enumerations in the OVAL Repository:
The OVAL Repository has required all vulnerability class definitions to have a cve reference and to use the cve description as the description of the definition. This convention allows us to leverage cve for correlation across all sort of security advisories and other information related to the vulnerability the definition is written for.

Should we follow the same pattern of usage for CCE and CPE?

Should we decide on a convention that states something like all inventory class definitions must include a CPE reference? If we adopt this convention we would shift all definitions that are currently in the inventory class that are not candidates for cpe names into the miscellaneous class. By way of example the definition that checks for windows xp sp2 or later is currently in the inventory class. There is no cpe name that aligns with sp2 or later so this definition would be moved to the inventory class.

Similarly should we decide on a convention that states that all compliance class definitions must include a cce reference? Here to we would move any definition that does not align with the intent of CCE into the miscellaneous class.

If we adopt these two conventions we will be able to establish a very high level of consistence in the usage of references in the oval repository. This will make verifying quality content in the repository more automatable, and show clear support for these enumerations as the way to uniquely identify the thing that a given definition is checking for.

So should we move forward with these conventions?

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing the Enumerations in the OVAL Repository

Tim Keanini
In reply to this post by Jon Baker
Jon, it would be helpful to lay out the classes-to-enumeration mapping
today, what is being suggested, and then we can see if this is backing
us into a corner or adding more road for the future.

From the text below, I can see these relationship:
Vulnerability-Class -> CVE
Inventory-Class
Compliance-Class
Miscellaneous-Class
(of the last three, inventory mapping to CPE, compliance to CCE, and
Miscellaneous for any classification we have not yet defined)

If we are consider this as a whole, we need to consider all the existing
enumerations and future Classes (and the management of the
Miscellaneous-Class which can get ugly if we don't watch out)

--tk


-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Thursday, June 11, 2009 6:32 AM
To: [hidden email]
Subject: [OVAL-DISCUSSION-LIST] Utilizing the Enumerations in the OVAL
Repository

At the Security Automation Developer Days this week we began a
discussion about the OVAL Repository, but ran short on time. I had
planned to go over three current issues with the OVAL Repository. Here
are the issues I had in mind:

- Utilizing the Enumerations in the OVAL Repository
- hosting test content in the repository
- consistent usage of affected platforms and products

In this message I will review the first item. I will write separate
messages to start conversations on the other two topics.

Utilizing the Enumerations in the OVAL Repository:
The OVAL Repository has required all vulnerability class definitions to
have a cve reference and to use the cve description as the description
of the definition. This convention allows us to leverage cve for
correlation across all sort of security advisories and other information
related to the vulnerability the definition is written for.

Should we follow the same pattern of usage for CCE and CPE?

Should we decide on a convention that states something like all
inventory class definitions must include a CPE reference? If we adopt
this convention we would shift all definitions that are currently in the
inventory class that are not candidates for cpe names into the
miscellaneous class. By way of example the definition that checks for
windows xp sp2 or later is currently in the inventory class. There is no
cpe name that aligns with sp2 or later so this definition would be moved
to the inventory class.

Similarly should we decide on a convention that states that all
compliance class definitions must include a cce reference? Here to we
would move any definition that does not align with the intent of CCE
into the miscellaneous class.

If we adopt these two conventions we will be able to establish a very
high level of consistence in the usage of references in the oval
repository. This will make verifying quality content in the repository
more automatable, and show clear support for these enumerations as the
way to uniquely identify the thing that a given definition is checking
for.

So should we move forward with these conventions?

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing the Enumerations in the OVAL Repository

Jon Baker
Administrator
TK,

The current map from definition class to reference type is as follows:

Definition Class | Reference Type
---------------------------------
Vulnerability    |  CVE (one exception)[1]
Inventory        |  CPE (most of the time)[2]
Compliance       |  no defined convention
Patch            |  no defined convention
Miscellaneous    |  no defined convention

[1] At the time the definition was written a cve did not exist. A CVE was later released and the  definition will be updated with the cve.

[2] Inventory definitions don't have cpe referances for two reasons. Either the author did not know to add one, or the definition was written to match some version or later. We will add names for those that are simply missing names because the author did not know to add one.

---------------------------------------------------------

Here is the map I have suggested we adopt in the OVAL Repository.

Definition Class | Reference Type
---------------------------------
Vulnerability    |  CVE
Inventory        |  CPE [1]
Compliance       |  CCE [2]
Patch            |  VENDOR [3]
Miscellaneous    |  MISC [4]  

[1] This would suggest that definitions like Windows XP SP2 or later would be classified as miscellaneous definitions.

[2] Given that it takes time to get a new CCE I would expect that the convention would be to accept content that 'should' get a cce id. Then once the cce id is assigned we can update any content that was missing a cce id. We currently have definitions in the repository with a class of 'compliance' that will not get cce ids any time soon. For example, we have a definition that 'Verifies no USB Drives are installed' this simply does not align with how CCE ids are created. If we adopt this proposed convention this definition would become a 'miscellaneous' class definition.

[3] There is no standard identifier for patch definitions to reference. We have suggested that patch based definitions include a reference to the corresponding patch binary. This led us to suggest the string 'VENDOR' as the

[4] We have been using the 'MISC' string as the reference source for non standardized references.

In suggesting this approach my intent is to document a convention for the oval repository so that content contributors will have clear guidelines for submitting content to the oval repository and also to improve the consistency and usability of the content in the repository.

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]


>-----Original Message-----
>From: Tim Keanini [mailto:[hidden email]]
>Sent: Sunday, June 14, 2009 5:35 PM
>To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
>Subject: Re: [OVAL-DISCUSSION-LIST] Utilizing the Enumerations in the
>OVAL Repository
>
>Jon, it would be helpful to lay out the classes-to-enumeration mapping
>today, what is being suggested, and then we can see if this is backing
>us into a corner or adding more road for the future.
>
>From the text below, I can see these relationship:
>Vulnerability-Class -> CVE
>Inventory-Class
>Compliance-Class
>Miscellaneous-Class
>(of the last three, inventory mapping to CPE, compliance to CCE, and
>Miscellaneous for any classification we have not yet defined)
>
>If we are consider this as a whole, we need to consider all the existing
>enumerations and future Classes (and the management of the
>Miscellaneous-Class which can get ugly if we don't watch out)
>
>--tk
>
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Thursday, June 11, 2009 6:32 AM
>To: [hidden email]
>Subject: [OVAL-DISCUSSION-LIST] Utilizing the Enumerations in the OVAL
>Repository
>
>At the Security Automation Developer Days this week we began a
>discussion about the OVAL Repository, but ran short on time. I had
>planned to go over three current issues with the OVAL Repository. Here
>are the issues I had in mind:
>
>- Utilizing the Enumerations in the OVAL Repository
>- hosting test content in the repository
>- consistent usage of affected platforms and products
>
>In this message I will review the first item. I will write separate
>messages to start conversations on the other two topics.
>
>Utilizing the Enumerations in the OVAL Repository:
>The OVAL Repository has required all vulnerability class definitions to
>have a cve reference and to use the cve description as the description
>of the definition. This convention allows us to leverage cve for
>correlation across all sort of security advisories and other information
>related to the vulnerability the definition is written for.
>
>Should we follow the same pattern of usage for CCE and CPE?
>
>Should we decide on a convention that states something like all
>inventory class definitions must include a CPE reference? If we adopt
>this convention we would shift all definitions that are currently in the
>inventory class that are not candidates for cpe names into the
>miscellaneous class. By way of example the definition that checks for
>windows xp sp2 or later is currently in the inventory class. There is no
>cpe name that aligns with sp2 or later so this definition would be moved
>to the inventory class.
>
>Similarly should we decide on a convention that states that all
>compliance class definitions must include a cce reference? Here to we
>would move any definition that does not align with the intent of CCE
>into the miscellaneous class.
>
>If we adopt these two conventions we will be able to establish a very
>high level of consistence in the usage of references in the oval
>repository. This will make verifying quality content in the repository
>more automatable, and show clear support for these enumerations as the
>way to uniquely identify the thing that a given definition is checking
>for.
>
>So should we move forward with these conventions?
>
>Thanks,
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DISCUSSION-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DISCUSSION-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].