cpe prefix property mythbusters *

1© 2010 The MITRE Corporation. All rights reserved

CPE Prefix Property MythBusters*CPE Core Team Technical Working Group (TWG)

05/11/2010

* This presentation contains explanatory text in the notes field

© 2010 The MITRE Corporation. All rights reserved2

Introduction

This presentation describes the analysis, results, conclusions and recommendations of the CPE Core Team with respect to the treatment of the CPE prefix property in the CPE 2.3 family of specifications. It includes an executive summary on slides 3 – 11 followed by a detailed description of the supporting analytical processes and rationale for each recommendation.


EXECUTIVE SUMMARYCPE Prefix Property MythBusters


Goal and Purpose

Goal: Determine if the prefix property can be removed from CPE 2.3 without breaking backward compatibility.

Purposes:

1. To eliminate misconceptions about the prefix property’s meaning and function

2. To expose dependencies on the prefix property in the 2.2 specification

3. To provide a prefix property recommendation for CPE 2.3


Scope

In Scope Out of Scope

Determine the ramifications of removing the prefix property.

Determining the ramifications of any other change to the CPE specification.

Provide a recommendation and rationale for either retaining or removing the prefix property from the CPE 2.3 specification.

Recommendations for change to any other part of the CPE specification.


Approach

1. Identify the assumptions associated with the CPE prefix property

2. Test each assumption to determine whether it is truth or myth

3. Determine the ramifications of removing the prefix property

4. Recommend whether or not to eliminate the prefix property


Prefix Property Assumptions

Two assumptions were identified in the text of the CPE 2.2 specification:

1. the set hierarchy assumption;

2. the matching dependency assumption.

In order to determine if we can eliminate the prefix property in CPE 2.3, we must answer the following questions:

3. Is a CPE name a formal set hierarchy?

4. Does the prefix property enable matching?


Methods

1. The set hierarchy assumption was tested by comparing the relations of the things that are designated in each component of a CPE name with the expected relation according to the principles of set theory.

2. The matching dependency assumption was tested by stepping through the code of the CPE matching algorithm, checking for dependencies with each step.


Results

1. Only the “product” component of a CPE Name qualifies as a formal subset relation. The other components are properties of product or of the CPE Name itself.

2. No part of the matching algorithm depends on the prefix property. Rather, matching depends on two things: the position of a CPE component in a CPE name, and the content of each component.


Truth or Myth Conclusions

1. The set hierarchy assumption is a MYTH! The truth is that although CPE 2.2 specification states that a CPE name is a set hierarchy, testing revealed that only the product component is a logical subset of the set of all platform parts.

2. The matching dependency assumption is a MYTH! The truth is that matching will be unaffected by removal of the prefix property as long as the required order of CPE components is preserved.


Recommendations

1. Remove the prefix property from the CPE 2.3 family of specifications. CPE 2.2 functionality will be unaffected and backward compatibility will be preserved.

2. Redefine the structure of a CPE Name as a single set of name:value pairs that designates an IT product and its attributes.

3. Add a CPE Name component position constraint to the CPE 2.3 Matching and Dictionary specifications in order to maintain backward compatibility with the CPE 2.2.

4. Maintain CPE 2.2 component value rules, such as the usage of blanks and special character “-”


Rationale

1. Preserves backward compatibility with CPE 2.2

2. Preserves normalized structure of the current CPE Name while eliminating the invalid set hierarchy assumption

3. No change to the CPE 2.2 Matching Algorithm is required


DETAILED DESCRIPTIONCPE Prefix Property Mythbusters


Identify CPE Prefix Property Assumptions

In the verbiage in the CPE 2.2 specification that defines the prefix property, we identify two main assumptions associated with the prefix property: the set hierarchy assumption and the matching assumption. We will test each assumption to determine whether it is truth or a myth.

“ A general requirement for the naming structure is that the set of platforms identified by a long name should be a subset of the set of platforms identified by a shorter initial portion of that same name, thus allowing matching to take place. This is called the "prefix property". For example, redhat:enterprise_linux:4 would be a subset of redhat:enterprise_linux.”

- CPE 2.2 Specification, Section 4, Page 6


The highlighted verbiage from the CPE 2.2 specification is the source of the set hierarchy assumption. The assumption is that it describes a CPE Name as a logical set relation.


The Set Hierarchy Assumption


The Matching Dependency Assumption

The highlighted verbiage from the CPE 2.2 specification is the source of the matching dependency assumption. The assumption is that matching depends on the prefix property’s set relation.



MythBuster Test 1: Is CPE a Formal Set Hierarchy?

Apply set theory principles to the set hierarchy that is defined by the prefix property

a) Define the Set Theory relation to be tested

b) Explicitly describe the set relation of a CPE Name as defined in CPE 2.2

c) Apply the Set Theory relation to each level in the hierarchy to determine whether a CPE name is a set hierarchy

d) Describe results


Test 1a: Define Subset Relation According to Set Theory

A set of things that share common properties. Set A is a subset of B only if all members of A are also members of B.

[Jech, Thomas (2002). Set Theory. Springer-Verlag. ISBN 3-540-44085-2]

B AAll Prime Numbers

1, 3, 7

The set of all natural numbers that are divisible by 1 and themselves.


language = All languages in which a product with a given part, vendor, product, version, update and edition is produced

edition = All editions of a given part, vendor, product, version and update

version = All versions of products with a given vendor and part

product = All products with a given vendor and part

vendor = All vendors for a given platform part

part = All apps, OS, or hardware (a,o,h) on a given platform

cpe:/ = All known things on a given platform

update = All updates for a given part, vendor, product and version

Test 1b: Describe the Set Hierarchy as Described in CPE 2.2


Test 1c: Apply the Principles of Set Theory to the CPE Set Hierarchy.

Given the cpe set definition as the set of all things that can be found on a platform*; we compare the CPE set relations to the principles of set theory by posing the following true or false questions at each level of the cpe hierarchy:

1) Is every component in the hierarchy a platform part as defined by CPE 2.2?

2) Is each member of a set a subset of the members of its parent set?

* Platform = An IT system that is made up of hardware, applications, an operating system, and other possible parts


Results

1. Application, operating system (OS) and hardware are kinds of products not the other way around

2. Vendors are not things that can be found on a platform

3. Products can be parts of a platform, but they are not subsets of vendor, application, or OS

4. Version, update, and edition are properties of product, not subsets of product.

5. Language is not part of a platform. It is a human language identifier that applies to all other components of a CPE Name.

Therefore questions 1 and 2 are both false.


Test 1: Conclusions

Is a CPE Name a set hierarchy: truth or myth?

MYTH!: When the principles of set theory are applied to the CPE set hierarchy, it reveals that a CPE Name is not a formal set hierarchy.


Test 1: Conclusions Continued

• The prefix property functions as an arbitrary “name restriction” rather than a formal set hierarchy, but misleading verbiage in the specification has created confusion among implementers who are understandably interpreting it as a set hierarchy of actual platform types. In this latter context it is illogical.

• Actual CPE component relations are mostly product-attribute relations, not hierarchical subsets of a platform.



A set of things that share common properties. Set A is a subset of B only if all members of A are also members of B.

[Jech, Thomas (2002). Set Theory. Springer-Verlag. ISBN 3-540-44085-2]

B AThings that can be found on a platform

products

The set of all things that can be found on a platform


Described vs. Actual CPE 2.2 Name Logical Structure

Described Structure Actual Structure

language edition

version

product

vendor

part

cpe:

update

cpe:- language

product

- part (type)- vendor- version- update- edition

Attributes of product

Subset of platform parts

Attribute of CPE Name


MythBuster Test 2: Does the Prefix Property Enable Matching?

a) Define and describe the CPE 2.2 matching process

b) Describe the CPE Matching Algorithm as it is defined in the CPE 2.2 specification

c) Assess each functional step of the CPE Matching Algorithm to for dependency on the prefix property

d) Describe results

e) Conclude what, if any dependencies the CPE matching algorithm has on the prefix property.


Test 2a: Define the CPE 2.2 Matching Process

“Matching is the process of determining if a given CPE Name or CPE Language statement specifies a platform that is defined by a set of known CPE Names.”

- CPE 2.2 Specification, Section 3, Page 4 and Section 7, Page 20


Test 2a: Describe the CPE 2.2 Matching Process

AnalysisTool

CPEDictionary

OVALTesting

Analysisdocument

Matching

Known InstanceSet

Object marked with

CPE Name or

Language Expression

TargetSystem

Object or null

As illustrated in the CPE 2.2 Conceptual Model, the CPE 2.2 Matching Algorithm is designed to match a CPE Name that is known to identify a given platform instance (target system) to a candidate CPE Name or CPE Language expression (e.g. from an analysis document).

- CPE 2.2 Specification, Section 7.1, Page 21

Step1

Step 4

Step 2

Step 3


Test 2a: Describe the CPE 2.2 Matching Process Continued

AnalysisTool

CPEDictionary

OVALTesting

Analysisdocument

Matching

Known InstanceSet

Object marked with

CPE Name or

Language Expression

TargetSystem

Object or null

Target system = instance of target platform

The CPE Names in Known Instance Set (K1-KN) come from the CPE Dictionary

A candidate (“given”) CPE Name (X) or an expression (E) of multiple CPE Names connected by Boolean operators (aka “language statement”)

Matching algorithm returns true if an item (N) in the K list matches X or E, it returns false if no match is found.

Step1

Step 4

Step 2

Step 3

OVAL testing produces this list of “known CPE Names” (K1- KN) identifying the target system

The CPE 2.2 Matching Algorithm iterates through each item (N) in the (K1-Km) list until a match to X or E is found or until the list ends, whichever comes first.


Test 2b: Describe the CPE Matching Algorithm

Two matching Algorithms are described in the CPE 2.2 Specification: CPE Name matching and CPE Language matching. These two algorithms use a common name matching algorithm, which is the algorithm that we will evaluate for dependency on the prefix property.


The CPE 2.2 Specification describes the CPE Name Matching Algorithm in pseudocode.

Inputs:

• K = A list of m CPE Names, K = {K1, K2, …, Km} .

• N= A single CPE Name in the list of K• X= A Candidate CPE Name for comparison to the Ns in list K.

Output: True if X matches any N in K, false otherwise.

Notes:• The function length(N) returns the number of components in a

CPE Name N.• The function comp(N,i) returns the i'th component of the CPE

Name N as a string. - CPE 2.2 Specification, Section 7.2, Pages 21-22

Test 2b: Describe the CPE Matching Algorithm Continued


Test 2b: Describe the CPE Matching Algorithm Continued

CPE 2.2 Matching Algorithm Pseudocode Description of Functional Steps

1 function CPE_Name_Match(K, X )2 for each N in K do 3 if length(N)>= length(X) then4 r := false.5 for i := 1 to length(X) do 6 if comp(X,i) = comp(N,i) or7 comp(X,i) = ""8 then9 r := true.10 else11 r := false.12 break.13 end 14 end15 if r = true then16 return true.17 end18 end19 end20 return false.21 end

A. 2-4: Compares component length of N to X. If N is greater than or equal to X then compare values of each component.

B. 5-12: Compares the value of each component in X to it respective component in N. If N value matches X or is blank, then move to the next component.

C. 15-17: If X matches N then return true. If any component doesn’t match, then return false and check next N.

D. 18-21: If all N’s have been checked and no X:N match exists then return false and end process.


2c: Assess Functional Steps for Dependency on the Prefix Property

We will assess each of the functional steps for dependency on the prefix property- Examples are provided for Steps A and B.- Steps C and D are self explanatory.

Finally, for explanatory purposes, we provide an alternative pseudocode algorithm that provides the same functionality as the CPE 2.2 algorithm, but may be simpler for some readers to understand.


Test 2c: Assess Functional Step A for Dependency on the Prefix Property

Step A - Code lines 2-4: moving from left to right, counts number of components in N and X respectively to the last non-blank component. If N has fewer components than X it is rejected as a possible match and the process moves to the next N.

2 for each N in K do

3 if length(N)>= length(X) then

4 r := false.

No dependency on a set hierarchy.


Test 2c: Functional Step A Example

Item No

List K of products (N) identified on target system

Component length

Compare values?

K1 cpe:/o:microsoft:windows_2000::sp3 6 Yes (N>X)

K2 cpe:/o:redhat:enterprise_linux:3::as 7 Yes (N>X)

K3 cpe:/o:redhat:enterprise_linux 4 No (N<X)

K4 cpe:/a:adobe:reader:8 5 Yes (N=X)

Given candidate CPE Name X = cpe:/o:redhat:enterprise_linux:3Component length of X = 5, K3 is eliminated as a match candidate because it has fewer components than X.


Test 2c: Assess Functional Step B for Dependency on the Prefix Property

Step B. - Code lines 5-12: Compares the value of each component in X to its respective component in N. If each N value either matches its corresponding X value or is blank, then a match is found (r = true).

5 for i := 1 to length(X) do

6 if comp(X,i) = comp(N,i) or

7 comp(X,i) = ""

8 then

9 r := true.

10 else

11 r := false.

12 break.

• Dependent on the position and content of CPE Name components• No dependency on a set hierarchy


Test 2c: Functional Step B Example

Steps 1 2 3 4 5 6

K1 Compare o microsoft windows_2000 [empty] sp3

Match? check next component

False (check K2)

K2 Compare o redhat enterprise_linux 3 [empty] as

Match? check next component

check next component

check next component

True (end)

Given candidate CPE Name X = cpe:/o:redhat:enterprise_linux:3, the algorithm compares each component in K1 in left to right order. It finds that microsoft does not match redhat. Then it compares K2, and finds a match (r=true), therefore it is not necessary to check K4.


Test 2c: Assess Functional Step C for Dependency on the Prefix Property

Step C – Code lines 15-16: If X matches N then return true. If any component doesn’t match, then check next N.

15 if r = true then

16 return true

17 end

• Dependent on the position and content of CPE Name components

• No dependency on a set hierarchy


Test 2c: Assess Functional Step D for Dependency on the Prefix Property

Step D. – Code lines 18 - 21: If all N’s have been checked and no X:N match exists then return false and end process.

18 end

19 end

20 return false.

21 end

• Dependent on the position and content of CPE Name components

• No dependency on a set hierarchy


Alternative Algorithm

Finally, for explanatory purposes only, we provide an alternative pseudocode algorithm that provides the same functionality as the CPE 2.2 algorithm, but may be simpler for some readers to understand.

This simpler algorithm is being implemented in SQL by some CPE users today. Like the CPE 2.2 Algorithm, it also depends on component position and content, but not on a set hierarchy.


Alternative Algorithm Example With the Same Logic

Alternative Algorithm Description of Functional Steps

1 function CPE_Name_Match(K, X) 2 for each N in K do 3 if (compare(comp(X, 1), comp(N, 1)) = true and 4 compare(comp(X, 2), comp(N, 2)) = true and 5 compare(comp(X, 3), comp(N, 3)) = true and 6 compare(comp(X, 4), comp(N, 4)) = true and 7 compare(comp(X, 5), comp(N, 5)) = true and 8 compare(comp(X, 6), comp(N, 6)) = true and 9 compare(comp(X, 7), comp(N, 7)) = true) then10 return true.11 end12 end13 return false.14 end1516 function compare(C1, C2)17 if C1 = C2 or C1 = ""18 return true.19 end20 return false.21 End

A. 2-9: Compares the value of each component in X to its respective component in N. If N value string matches X or is blank, then check next component. If any component doesn’t match, then check next N.B. 10: If all components of X and N match then return true.C. 13: If we make it to this line, no member of K (no N) was found to be a match, therefore return false.D. 16-21: Defines the compare function used in lines 3-10. Components match if their value string matches exactly or if the N component argument (C1) is the empty string ("")


Results

• The CPE 2.2 Matching Algorithm is dependent on only on absolute position of each component in a CPE Name and the values of those components.• Dependency on position of a component in a CPE Name does not equal dependency on a subset hierarchy.


Test 2: Conclusion

Does the Prefix Property Enable Matching: truth or myth?

MYTH!: No dependency on the prefix property was found in any functional step of the CPE 2.2 Matching Algorithm.



As long as CPE components maintain their position and the rules for component values remain the same for 2.2 content then the CPE 2.2 Matching Algorithm will function as expected.

cpe prefix property mythbusters *

Documents

cpe specification

cpe prefix propertytest

cpe component

prefix property recommendation

cpe matching algorithm

mitre corporation

prefix propertys

prefix property6