/
CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE);  Da CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE);  Da

CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE); Da - PowerPoint Presentation

briana-ranney
briana-ranney . @briana-ranney
Follow
379 views
Uploaded On 2017-11-11

CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE); Da - PPT Presentation

CPE Naming Specification Outline MITRE 1 CPE Specification Stack Naming Matching Representation Binding Language Dictionary The diagram below illustrates the stack relationship among the various specifications comprising v23 of the Common Product Enumeration ID: 604538

wfn edition attribute cpe edition wfn cpe attribute target attributes product binding names context conformant values wfns string step

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "CPE Core Team: Brant Cheikes and Mary Pa..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

CPE Core Team: Brant Cheikes and Mary Parmelee (MITRE); Dave Waltermire, Paul Cichonski, Harold Booth and Chris McCormick (NIST); Jim Ronayne and Shane Shaffer (DOD); Seth Hanford (Cisco); Kent Landfield (McAfee); Tim Keanini (nCircle)

CPE Naming Specification Outline

MITRE

1Slide2

CPE Specification StackNaming

Matching

Representation

(Binding)

Language

Dictionary

The diagram below illustrates the stack relationship

among the various specifications comprising v2.3 of the Common Product Enumeration (

CPE)

standard.

Naming is at the bottom of the stack—it defines

a the general concept of a well-formed

name

Defines

the logical structure of well-formed names, and requirements on attributes and values used to form names

Provides

informative guidance relating to the use of names and the different contexts where they may be

usedSlide3

CPE 2.3 Naming Specification Executive Summary (1)In v2.3 we introduce new features in CPE names that make those names non-conformant with the v2.2 specificationWe distinguish “v2.2 conformant names” from “v2.3 conformant names”We

define a mechanical translation between versions of namesWe define a Well-Formed Name (WFN) as a referring expression

Interpretation depends on context of use3Slide4

CPE 2.3 Naming Specification Executive Summary (2)We define a WFN as a conceptual data structure which can be bound to a version-conformant machine-readable representationWe retain the URI binding for

backward compatibility w/ CPE v2.2 and to facilitate interoperability with v2.2

conformant SCAP tools and contentWe define a new formatted string binding for use by CPE v2.3 conformant SCAP tools and content4Slide5

Naming Specification ScopeIn scope:The logical structure of Well-Formed CPE NamesProcedures for binding well-formed names to their encodings for exchange among machinesProcedures for translating between

bindingsOut of scope:Criteria for determining “correct” or “valid” values for attributes of products

Procedures for comparing/matching names5Slide6

Well-Formed CPE NamesMITRE

6Slide7

Well-Formed CPE NamesA well-formed CPE name (WFN) is an unordered set of attribute-value pairsMust satisfy these criteria:Attributes selected from a fixed vocabularyEach attribute appears at most once in a nameValues of attributes are character strings

Some reserved and special charactersSome attributes may have specified valid values, for most others we recommended that values be chosen from valid-values lists

7Slide8

WFNs: Conceptual Data StructuresWFN is a conceptual data structureA kind of “normal form” for product identifiers and identifying expressionsThere shall be no requirement that SCAP tools use WFNs internallyWhen discussing WFNs in the spec, we will use the following written representation:[a1=“v1”,a2=“v2”,…]

Ex1: [part=“a”,vendor=“adobe”,…]

Ex2: [part=“o”,version=“3.*”]8Slide9

WFNs: Legal Attributes (1/2)Shall be no mandatory/optional distinctionAll attributes are effectively optionalAll seven v2.2 components become allowed attributes of WFNs in 2.3:

Part, Vendor, Product, Version, Update, Edition and LanguageThese will have the same meanings in v2.3 as in v2.2

NB: the edition attribute will be deprecated in v2.3—its use allowed only under certain circumstances9Slide10

WFNs: Legal Attributes (2/2)WFNs shall allow four new legal attributes:sw_edition (“software edition”)target_sw

(“target software platform”)target_hw (“target hardware platform”)

other_edition (“other edition data not included elsewhere”)We will not convert legacy dictionary content to use these new attributesIf any of these four attributes are used in a WFN, the (deprecated) edition attribute must not

be used

10Slide11

WFNs: Attribute ValuesAttributes values are character stringsUS-ASCII character setExcluding whitespace and CTRL charactersWe will specify a maximum string lengthReserved characters:

colon (:), fwd_slash

(/), double-quoteThese must be percent-encoded when embedded in value stringsSpecial characters:Question-mark (?), asterisk (*)

11Slide12

WFNs are Referring ExpressionsA WFN is a kind of referring expressionIt denotes something (or set of things) in the worldThat which is denoted is called the referent

Determining the referent of a WFN depends on its context of use

Ex: “The president of the US” has different referents depending on temporal contextUpper-stack specifications may define contexts of use in which attribute values have special interpretations

12Slide13

Inventory ContextInventory context is the context of use in which an asset inventory tool reports lists of names of products believed to be installed within an enterpriseEach WFN on the inventory list is intended to have a single product as its referent, but the inventory tool may only be able to provide a partial description of that product

In this context, a WFN is ambiguous if there is more than one possible referent

13Slide14

Catalog ContextCatalog context is the context of use in which an organization creates an authoritative listing of names of distinct productsEach WFN in the catalog is intended to have a single product as its referent, and is assumed to fully describe

that product to the best knowledge of the catalog curatorNo requirement that each product in the catalog exists either in the world or in the enterprise’s installed inventory

14Slide15

Applicability ContextApplicability context is the context of use in which two WFNs (a “source” and a “target”) are compared to determine whether the referents of the source and target are disjointBoth the source and the target may be ambiguous—i.e., have multiple referents in the worldDisjointness

is determined by reference to a catalogThe catalog serves as a proxy for the world

15Slide16

BindingsMITRE

16Slide17

TermsTo bind a name means:Convert a WFN to a machine-readable representation suitable for interchange among SCAP applicationsTo unbind a name means:

To convert a machine-readable representation of a CPE identifier into a WFN

17Slide18

Overview (1/2)For interoperability purposes, we will define two alternative bindings for a WFN:A URI binding for use when exchanging CPE information with CPE 2.2 conformant SCAP toolsA formatted string binding for use when exchanging CPE information with CPE 2.3 conformant SCAP tools

18Slide19

Overview (2/2)In general, the procedure for translating a CPE 2.2-conformant bound name to a CPE 2.3-conformant bound name takes two steps:First unbind the name into a WFNBind the resulting WFN to the desired target binding

19Slide20

Binding a WFN to a formatted string (1/2)The specified binding of WFN shall be a formatted string prefixed with “cpe-2.3:/”Iterate through WFN attributes in this order:part, vendor, product, version, update, edition, sw_edition, target_sw, target_hw, other_edition, languageIf edition attribute is used, treat as equivalent to sw_edition, and skip target_sw, target_hw, and other_edition; otherwise ignore edition

20Slide21

Binding a WFN to a formatted string (2/2)Concatenate value strings together, separating each one with a colon:If the attribute is absent in the WFN, encode its value as

‘*’Thus every attribute value appears explicitly in the bound formTBD: do we need to be able to elide trailing “:*” substrings?

21Slide22

Ex: WFN to formatted string“Foo Bar for C++ Professional Edition version 1.3 for 32-bit systems”WFN: [part=“a”,vendor=“

foo”,product=“

bar_for_c++”,version=“1.3”,update=“-”,sw_edition=“professional”,target_hw=“x32”]Bound form:cpe-2.3:/a:foo:bar_for_c++:1.3:-:professional:*:x32:*:*

target_sw

,

other_edition

and language

unspecified, bound to wildcards

22Slide23

Unbinding a CPE-2.3 NameStraightforward process:Parse out the attribute value strings in order:Part, vendor, product, version, update, sw_edition, target_sw,

target_hw, other_edition, language

No need to bother with percent-encoded characters since attribute value strings are in normal form23Slide24

Binding a WFN to a URI (1/2)Step 1: normalize all value stringsDelete each occurrence of the 2.3-defined special characters (‘?’ and ‘*’)Percent-encode all RFC-3986 “reserved” charactersStep 2: If the edition attribute is not used in the WFN, create a value for it by “packing” the four other edition-related attributes (next two slides

)

24Slide25

Packing (1/2)Initialize the edition attribute of the WFN to be the empty stringIterate over the four edition-related attributes:sw_edition, target_sw, target_hw

, other_editionAppend to the edition string:

concatenate “-” and the attribute valueIf the attribute value is empty or not specified, use “”NB: the result is a new string, prefixed with a hyphen, in which each edition-related attribute is concatenated in a fixed order separated by hyphens

25Slide26

Packing (2/2): Examples“…:-professional-winxp-x64-v88:…” (all four)“…:---x32-:…” (only target HW; three leading hyphens, one trailing)“…:--winxp-x32-:…” (middle two)

26Slide27

Binding a WFN to a URI (2/2)Step 3: Populate the URI template:cpe:/<part>:<vendor>:<product> … etc.Step 4:

Step thru each corresponding attribute in the

WFN, retrieving the corresponding attribute-value pair from the input WFNIf the attribute is absent in the WFN, encode it as a blank component valueStep 5 (opt): After the template is fully populated:From the right-most end, delete trailing colons (“:”) until the first non-colon is reached

27Slide28

Unbinding a 2.2 NameStep 1: Parse out the seven componentsStep 2: Unpack the edition component (next slide)Step 3: Decode all percent-encoded characters except colon, slash, dquoteStep 4: Delete each occurrence of the 2.3 special characters (“?” and “*”)

Step 5: Replace blank values with “*”

28Slide29

UnpackingUnpacking performed when unbinding a 2.2 name into a WFNThe “edition” attribute of the 2.2 name is inspected for a leading hyphen, and if present, the four subdelimited

values are parsed out into the four 2.3 edition-related attributesIf no leading hyphen is found, the 2.2 edition attribute is

simply copied to the (deprecated) 2.3 edition attribute29Slide30

Example: WFN to URIWFN: [vendor=“microsoft”,product=“c#”,

update=“-”,target_hw=“x64”]Normalize the strings and pack the edition attribute: [vendor

=“microsoft”,product=“c%23”,update=“-”,edition=“---x64”]URI after step 4:cpe:/:microsoft:c%23::-:---x64:

URI after step

5:

cpe

:/:microsoft:c%23::-:---x64

30Slide31

ConclusionMITRE

How does this solution address community issues?

31Slide32

Does this provide a solution to community issues? No prefix property—no defined hierarchical relationship among attributesV2.2 URI binding supportedV2.3 introduces a formatted string binding

V2.3 names may incorporate special characters which may have special meaningsV2.3 names minimize the need for percent encoding

We’ve narrowly scoped the spec to focus on structure and format, leaving meanings and interpretations to upper-stack specs32