Devices should have CPEs associable

[ajnelson-nist]

(Edited after announcement: NIST IR 7695 is the CPE naming specification, but was initially called the CPE specification in this post.)

Background

The observable:cpeid property is currently associated with observable:Software. The CPE naming specification, NIST IR 7695, also defines CPEs that are associable with hardware, through use of a "part" attribute value of h. E.g., this is a CPE Well-Formed-Name for a device manufactured by a company named "ExampleCo", and named "ExampleTablet" with, with the device version described as non-applicable:

cpe:2.3:h:exampleco:exampletablet:-:*:*:*:*:*:*:*

The CPE Dictionary from the National Vulnerability Database lists other examples of CPEs for hardware. After downloading and unzipping the dictionary, this command ...

grep 'cpe:2.3:h:' official-cpe-dictionary_v2.3.xml

... returns over 60,000 CPE names today.

Requirements

Requirement 1

Because UCO provides the ability to record a Software object's CPE, UCO should also support the ability to record a Device object's CPE, in line with the CPE naming specification.

Risk / Benefit analysis

Benefits

• Adding CPEs to devices brings UCO's modeling closer in line with modeling in CPE.
• Adding CPEs to devices expands the ability to correlate Device specialized subclasses more specific than would be encoded in UCO, such as particular models of phones.

Risks

Because devices would always fall under the Part attribute-value h, denoting classes of hardware devices, it also seems appropriate to constrain the CPE pattern to read like this ...

observable:DeviceFacet
	sh:property [
		sh:path observable:cpeid ;
		sh:pattern "^cpe:2.3:h:.+" ;
	] ;
	.

... except, observable:cpeid does not state what version of CPE the field is meant to conform to. Since CPE 2.3 has been around since 2011, this pattern would encode the assumption that CPE 2.3 is intended. While this is likely, given current known usage of CPE (the CPE Dictionary XML from NVD contains no instances of the string cpe:2.2, and over one million instances of the string cpe:2.3), it would technically be a backwards-incompatible change because UCO currently has no restrictions encoded anywhere on observable:cpeid.

Competencies demonstrated

Competency 1

An organization doing asset inventory logs a particular ExampleTablet. They use ex:hadInventoryNumber to log property numbers.

@prefix ex: <http://example.org/ontology/> .

ex:hadInventoryNumber
	a owl:DatatypeProperty ;
	rdfs:domain observable:Device ;
	rdfs:range xsd:string ;
	.

When inventorying a particular tablet, this is added to their knowledge base:

{
    "@context": {
        "ex": "http://example.org/ontology/",
        "kb": "http://example.org/kb/",
        "core": "https://ontology.unifiedcyberontology.org/uco/core/",
        "observable": "https://ontology.unifiedcyberontology.org/uco/observable/"
    },
    "@graph": [
        {
            "@id": "kb:Device-b1432774-082d-4eda-ad2e-fcdbe159d37c",
            "@type": "observable:Tablet",
            "ex:hadInventoryNumber": "TAB-1234",
            "core:hasFacet": {
                "@id": "kb:DeviceFacet-57721427-8a91-4b2a-a685-8de72cabdebc",
                "@type": "observable:DeviceFacet",
                "observable:cpeid": "cpe:2.3:h:exampleco:exampletablet:-:*:*:*:*:*:*:*",
                "observable:serialNumber": "XYZ56780000000002"
            }
        }
    ]
}

Competency Question 1.1

What are the CPEs for inventoried devices?

PREFIX ex: <http://example.org/ontology/>
SELECT ?lInventoryNumber ?lCPEID
WHERE {
	?nDevice
		ex:hadInventoryNumber ?lInventoryNumber ;
		core:hasFacet / observable:cpeid ?lCPEID ;
		.
}
ORDER BY ?lCPEID

Result 1.1

?lInventoryNumber	?lCPEID
TAB-1234	cpe:2.3:h:exampleco:exampletablet:-:*:*:*:*:*:*:*

Solution suggestion

Copy the cpeid property shape currently in SoftwareFacet to DeviceFacet, adding this to observable.ttl:

observable:DeviceFacet
	sh:property [
		sh:datatype xsd:string ;
		sh:maxCount "1"^^xsd:integer ;
		sh:nodeKind sh:Literal ;
		sh:path observable:cpeid ;
	] ;
	.

I am fine with my examples being transcribed and credited.

Coordination

• Tracking in Jira ticket OCUCO-320
• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2024-08-02
• Requirements to be discussed in OC meeting, 2024-08-20
• Requirements Review vote occurred, passing, on 2024-08-20
• Requirements development phase completed.
• Solution announced to OCs on 2024-10-21
• Solutions Approval to be discussed in OC meeting, 2024-11-21
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next release
• develop state with backwards-compatible implementation merged into develop-2.0.0
• Backwards-incompatible implementation merged into develop-2.0.0 (N/A)
• Milestone linked
• Documentation logged in pending release page
• Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
• Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

[ajnelson-nist]

On last week's call, there was a request to encode a warning on finding a CPE version newer than 2.3.

[ajnelson-nist]

Apologies: the CPE version point was meant for #626 . I've moved the checklist item over to that Issue.

[sbarnum]

This CP makes sense to me.