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 1

2. © 2010 The MITRE Corporation. All rights reserved 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. 2

3. © 2010 The MITRE Corporation. All rights reserved EXECUTIVE SUMMARY CPE Prefix Property MythBusters 3

4. © 2010 The MITRE Corporation. All rights reserved 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 4

5. © 2010 The MITRE Corporation. All rights reserved Scope In ScopeOut 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. 5

6. © 2010 The MITRE Corporation. All rights reserved 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 6

7. © 2010 The MITRE Corporation. All rights reserved 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: 1.Is a CPE name a formal set hierarchy? 2.Does the prefix property enable matching? 7

8. © 2010 The MITRE Corporation. All rights reserved 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. 8

9. © 2010 The MITRE Corporation. All rights reserved 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. 9

10. © 2010 The MITRE Corporation. All rights reserved 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. 10

11. © 2010 The MITRE Corporation. All rights reserved 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 “-” 11

12. © 2010 The MITRE Corporation. All rights reserved 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 12

13. © 2010 The MITRE Corporation. All rights reserved DETAILED DESCRIPTION CPE Prefix Property Mythbusters 13

14. © 2010 The MITRE Corporation. All rights reserved Identify CPE Prefix Property Assumptions 14 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

15. © 2010 The MITRE Corporation. All rights reserved 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. “ 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.” The Set Hierarchy Assumption 15

16. © 2010 The MITRE Corporation. All rights reserved The Matching Dependency Assumption 16 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. “ 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.”

17. © 2010 The MITRE Corporation. All rights reserved 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 17

18. © 2010 The MITRE Corporation. All rights reserved 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. 18 [Jech, Thomas (2002). Set Theory. Springer-Verlag. ISBN 3-540-44085-2] B A All Prime Numbers 1, 3, 7 The set of all natural numbers that are divisible by 1 and themselves.

19. © 2010 The MITRE Corporation. All rights reserved 19 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

20. © 2010 The MITRE Corporation. All rights reserved Test 1c: Apply the Principles of Set Theory to the CPE Set Hierarchy. 20 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

21. © 2010 The MITRE Corporation. All rights reserved 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. 21

22. © 2010 The MITRE Corporation. All rights reserved 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. 22

23. © 2010 The MITRE Corporation. All rights reserved 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. 23

24. © 2010 The MITRE Corporation. All rights reserved Test 1: Conclusions Continued 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. 24 [Jech, Thomas (2002). Set Theory. Springer-Verlag. ISBN 3-540-44085-2] B A Things that can be found on a platform products The set of all things that can be found on a platform

25. © 2010 The MITRE Corporation. All rights reserved 25 Described vs. Actual CPE 2.2 Name Logical Structure Described StructureActual 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

26. © 2010 The MITRE Corporation. All rights reserved 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. 26

27. © 2010 The MITRE Corporation. All rights reserved 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 27

28. © 2010 The MITRE Corporation. All rights reserved Test 2a: Describe the CPE 2.2 Matching Process 28 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

29. © 2010 The MITRE Corporation. All rights reserved Test 2a: Describe the CPE 2.2 Matching Process Continued 29 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.

30. © 2010 The MITRE Corporation. All rights reserved 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. 30

31. © 2010 The MITRE Corporation. All rights reserved The CPE 2.2 Specification describes the CPE Name Matching Algorithm in pseudocode. Inputs: K = A list of m CPE Names, K = {K 1, K 2, …, K m }. 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 31 Test 2b: Describe the CPE Matching Algorithm Continued

32. © 2010 The MITRE Corporation. All rights reserved Test 2b: Describe the CPE Matching Algorithm Continued 32 CPE 2.2 Matching Algorithm PseudocodeDescription of Functional Steps 1 function CPE_Name_Match(K, X ) 2for each N in K do 3if length(N)>= length(X) then 4 r := false. 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. 13 end 14end 15 if r = true then 16 return true. 17end 18 end 19end 20return 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.

33. © 2010 The MITRE Corporation. All rights reserved 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. 33

34. © 2010 The MITRE Corporation. All rights reserved 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 3if length(N)>= length(X) then 4 r := false. No dependency on a set hierarchy. 34

35. © 2010 The MITRE Corporation. All rights reserved Test 2c: Functional Step A Example Item No List K of products (N) identified on target system Component length Compare values? K1cpe:/o:microsoft:windows_2000::sp36Yes (N>X) K2cpe:/o:redhat:enterprise_linux:3::as7Yes (N>X) K3cpe:/o:redhat:enterprise_linux4No (N<X) K4cpe:/a:adobe:reader:85Yes (N=X) 35 Given candidate CPE Name X = cpe:/o:redhat:enterprise_linux:3 Component length of X = 5, K3 is eliminated as a match candidate because it has fewer components than X.

36. © 2010 The MITRE Corporation. All rights reserved 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 36

37. © 2010 The MITRE Corporation. All rights reserved Test 2c: Functional Step B Example 37 Steps123456 K1Compareomicrosoftwindows_2000[empty]sp3 Match?check next component False (check K2) K2Compareoredhatenterprise_linux3[empty]as Match?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.

38. © 2010 The MITRE Corporation. All rights reserved 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 38

39. © 2010 The MITRE Corporation. All rights reserved 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 39

40. © 2010 The MITRE Corporation. All rights reserved 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. 40

41. © 2010 The MITRE Corporation. All rights reserved Alternative Algorithm Example With the Same Logic Alternative AlgorithmDescription 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) then 10 return true. 11 end 12 end 13 return false. 14 end 15 16 function compare(C1, C2) 17 if C1 = C2 or C1 = "" 18 return true. 19 end 20 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 ("") 41

42. © 2010 The MITRE Corporation. All rights reserved 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. 42

43. © 2010 The MITRE Corporation. All rights reserved 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. 43

44. © 2010 The MITRE Corporation. All rights reserved Test 2: Conclusions Continued 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. 44