1 / 44

CPE Prefix Property MythBusters *

CPE Prefix Property MythBusters *. CPE Core Team Technical Working Group (TWG) 05/11/2010 * This presentation contains explanatory text in the notes field. Introduction.

denim
Télécharger la présentation

CPE Prefix Property MythBusters *

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPE Prefix Property MythBusters* CPE Core Team Technical Working Group (TWG) 05/11/2010 * This presentation contains explanatory text in the notes field

  2. 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.

  3. CPE Prefix Property MythBusters Executive Summary

  4. Goal and Purpose Goal: Determine if the prefix property can be removed from CPE 2.3 without breaking backward compatibility. Purposes: • To eliminate misconceptions about the prefix property’s meaning and function • To expose dependencies on the prefix property in the 2.2 specification • To provide a prefix property recommendation for CPE 2.3

  5. Scope

  6. Approach • Identify the assumptions associated with the CPE prefix property • Test each assumption to determine whether it is truth or myth • Determinethe ramifications of removing the prefix property • Recommend whether or not to eliminate the prefix property

  7. Prefix Property Assumptions Two assumptions were identified in the text of the CPE 2.2 specification: • the set hierarchy assumption; • 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: • Is a CPE name a formal set hierarchy? • Does the prefix property enable matching?

  8. Methods • 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. • The matching dependency assumption was tested by stepping through the code of the CPE matching algorithm, checking for dependencies with each step.

  9. Results • 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. • 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.

  10. Truth or Myth Conclusions • 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. • 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.

  11. Recommendations • 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. • Redefine the structure of a CPE Name as a single set of name:value pairs that designates an IT product and its attributes. • 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. • Maintain CPE 2.2 component value rules, such as the usage of blanks and special character “-”

  12. Rationale • Preserves backward compatibility with CPE 2.2 • Preserves normalized structure of the current CPE Name while eliminating the invalid set hierarchy assumption • No change to the CPE 2.2 Matching Algorithm is required

  13. CPE Prefix Property Mythbusters Detailed Description

  14. 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

  15. The Set Hierarchy Assumption 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.”

  16. 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. “ 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. MythBuster Test 1: Is CPE a Formal Set Hierarchy? Apply set theory principles to the set hierarchy that is defined by the prefix property • Define the Set Theory relation to be tested • Explicitly describe the set relation of a CPE Name as defined in CPE 2.2 • Apply the Set Theory relation to each level in the hierarchy to determine whether a CPE name is a set hierarchy • Describe results

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

  19. Test 1b: Describe the Set Hierarchy as Described in CPE 2.2 cpe:/ = All known things on a given platform part = All apps, OS, or hardware (a,o,h) on a given platform vendor = All vendors for a given platform part product = All products with a given vendor and part version = All versions of products with a given vendor and part update = All updates for a given part, vendor, product and version edition = All editions of a given part, vendor, product, version and update language = All languages in which a product with a given part, vendor, product, version, update and edition is produced

  20. 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: • Is every component in the hierarchy a platform part as defined by CPE 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. Results • Application, operating system (OS) and hardware are kinds of products not the other way around • Vendors are not things that can be found on a platform • Products can be parts of a platform, but they are not subsets of vendor, application, or OS • Version, update, and edition are properties of product, not subsets of product. • 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.

  22. 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.

  23. 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.

  24. 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. Things that can be found on a platform B A products The set of all things that can be found on a platform [Jech, Thomas (2002). Set Theory. Springer-Verlag. ISBN 3-540-44085-2]

  25. Described vs. Actual CPE 2.2 Name Logical Structure cpe: cpe: - language Attribute of CPE Name part • product • part (type) • vendor • version • update • edition vendor Subset of platform parts product version update Attributes of product edition language

  26. MythBuster Test 2: Does the Prefix Property Enable Matching? • Define and describe the CPE 2.2 matching process • Describe the CPE Matching Algorithm as it is defined in the CPE 2.2 specification • Assess each functional step of the CPE Matching Algorithm to for dependency on the prefix property • Describe results • Conclude what, if any dependencies the CPE matching algorithm has on the prefix property.

  27. 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

  28. Test 2a: Describe the CPE 2.2 Matching Process 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). Step1 Step 2 Step 3 Step 4 - CPE 2.2 Specification, Section 7.1, Page 21

  29. Test 2a: Describe the CPE 2.2 Matching Process Continued The CPE Names in Known Instance Set (K1-KN) come from the CPE Dictionary Target system = instance of target platform Step1 A candidate (“given”) CPE Name (X) or an expression (E) of multiple CPE Names connected by Boolean operators (aka “language statement”) OVAL testing produces this list of “known CPE Names” (K1- KN) identifying the target system Step 2 Step 3 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. Matching algorithm returns true if an item (N) in the K list matches X or E, it returns false if no match is found. Step 4

  30. 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.

  31. Test 2b: Describe the CPE Matching Algorithm Continued 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

  32. Test 2b: Describe the CPE Matching Algorithm Continued

  33. 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.

  34. 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.

  35. Test 2c: Functional Step A Example 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. 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

  37. Test 2c: Functional Step B Example 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. 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

  39. 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

  40. 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.

  41. Alternative Algorithm Example With the Same Logic

  42. 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.

  43. 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.

  44. 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.

More Related