Operating systems should be recognized as specializations of software

[ajnelson-nist]

Background

observable:OperatingSystem is currently a direct subclass of observable:ObservableObject, with no relationship to observable:Software.

Issue 596 proposes a restructuring of classes pertaining to software, including making OperatingSystem a direct subclass of Software.

Issue 626 implements a constraint on describing operating systems with observable:cpeid, that is reliant on OperatingSystem being a subclass of Software as is consistent with the CPE model (i.e., in NISTIR 7695).

To the proposer's understanding, there is no operating system that is not, at least in part, software.

This proposal is almost a fast-track change to change the parent class of OperatingSystem to Software; however, while reviewing data for demonstration, some property movements between Facets became apparent.

Requirements

Requirement 583-2

This requirement is ported from Issue 596, and is a reduction of a requirement ported from Issue 583:

Ability to characterize different types of software objects
At a minimum this should include Software, and OperatingSystem.

Requirement 1

To prevent data placement confusion and synchronization issues, OperatingSystemFacet and SoftwareFacet must share no properties. Any shared properties should be placed only in SoftwareFacet.

Currently, they both have the properties observable:manufacurer and observable:version.

(This requirement is in addition to Issues 583 and 596, and was realized when sketching example data.)

Risk / Benefit analysis

Benefits

• This proposal progresses software restructuring that is not blocked waiting on feedback.

Risks

1. This change will exercise a part of Facets that might appear less than intuitive to users, though nothing will have changed about Facet design with this proposal. To describe an operating system with software characteristics, the properties will go in a SoftwareFacet attached to the OperatingSystem. Structurally, this is because while OperatingSystem would subclass Software, OperatingSystemFacet and SoftwareFacet remain independent classes.
2. While this proposal will remove some properties from observable:OperatingSystemFacet, UCO's current design practice of declining rdfs:domain and generally not using "Domain-reviewing" shapes (e.g. with sh:targetSubjectsOf and sh:targetObjectsOf) mean in UCO 2.0.0, it will not be an error to keep using observable:manufacturer or observable:version on observable:OperatingSystemFacet. Further, following current practice, users will be more free to use those properties on observable:OperatingSystemFacet, because SHACL usage is currently only defined in property shapes attached to classes. It will be possible for a user to record "observable:version": 1 as an integer, and UCO's SHACL will not flag it as an error. Adddressing this requires a global revision of UCO's property-review practice to follow what was done in only a few cases (e.g., types:repeatsKey for Issue 602, and core:objectStatus for Issue 549). This will need to be discussed separately, as there might need to be considerations for generated documentation.
   1. If the properties should be disallowed from observable:OperatingSystemFacet, specific shapes can be added for UCO 2.0.0 that flag their usage as an error. This would be a special-case handling of only two properties.
   2. Being able to provide migration guidance in UCO 1.4.0 before UCO 2.0.0 potentially mitigates this risk without needing to address the underlying UCO design matters.

Competencies demonstrated

Competency 1

A workstation has an instance of an operating system from Example OS Company.

{
    "@context": {
        "core": "https://ontology.unifiedcyberontology.org/uco/core/",
        "identity": "https://ontology.unifiedcyberontology.org/uco/identity/",
        "kb": "http://example.org/kb/",
        "observable": "https://ontology.unifiedcyberontology.org/uco/observable/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@graph": [
        {
            "@id": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54",
            "@type": "identity:Organization",
            "core:name": "Example OS Company"
        },
        {
            "@id": "kb:OperatingSystem-427dd103-2553-4ccc-ad57-1df4e88b174d",
            "@type": "observable:OperatingSystem",
            "core:description": "The Example Operating System instance deployed on workstation B-203-22",
            "core:hasFacet": [
                {
                    "@id": "kb:SoftwareFacet-1bde46c5-4648-493c-b9dc-56477191d5c6",
                    "@type": "observable:SoftwareFacet",
                    "observable:cpeid": "cpe:2.3:o:exampleosco:exampleos:40:*:*:*:*:*:*:*",
                    "observable:language": "en-us",
                    "observable:manufacturer": {
                        "@id": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54"
                    },
                    "observable:version": "40"
                },
                {
                    "@id": "kb:OperatingSystemFacet-35047ef2-ffd6-45e8-8b3c-2e8e4bfe7c2b",
                    "@type": "observable:OperatingSystemFacet",
                    "observable:bitness": "64",
                    "observable:installDate": {
                        "@type": "xsd:dateTime",
                        "@value": "2024-09-13T09:00:00-04:00"
                    }
                }
            ]
        }
    ]
}

Competency Question 1.1

What is the query and result for finding the version of this operating system, specifying the specific Facet needed?

Result 1.1

SPARQL query:

SELECT ?lVersion
WHERE {
	?nOperatingSystem
		a observable:OperatingSystem ;
		core:hasFacet ?nFacet ;
		.
	?nFacet
		a observable:SoftwareFacet ;
		observable:version ?lVersion ;
		.
}

Result:

lVersion
40

Competency Question 1.2

Alternatively, how can the version of the operating system be found, without regard for what Facet is housing it?

Result 1.2

SPARQL query:

SELECT ?lVersion
WHERE {
	?nOperatingSystem
		a observable:OperatingSystem ;
		core:hasFacet / observable:version ?lVersion ;
		.
}

Result:

lVersion
40

This is one motivation for removing observable:version from what would become a redundant placement in OperatingSystemFacet.

Solution suggestion

For UCO 1.4.0, implement the following warnings for backwards compatiblity:

• Add a warning-shape to observable:OperatingSystem, that its instances must also be typed as observable:Software. This is as was done with moving observable:AlternateDataStream in Issue 590.
• Add new property shapes for observable:version and observable:manufacturer to observable:OperatingSystemFacet, setting only the constraint that they have a maximum-use count of 0, with a severity of sh:Warning.

For UCO 2.0.0:

• Change the parent class of observable:OperatingSystem to observable:Software.
• Remove the class warning shape put in place for UCO 1.4.0.
• Remove all property shapes for observable:version and observable:manufacturer from observable:OperatingSystemFacet; OR, remove the two properties' shapes that were in UCO 1.3.0, and upgrade the severity for the properties' warning shapes to sh:Violation (the SHACL default).

Coordination

• Tracking in Jira ticket OCUCO-324
• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2024-09-13
• Requirements to be discussed in OC meeting, 2024-09-26
• Requirements Review vote occurred, passing, on 2024-09-26
• Requirements development phase completed.
• Solution announced to OCs on 2024-10-16
• Solutions Approval to be discussed in OC meeting, 2024-10-24
• Solutions Approval vote occurred, passing, on 2024-10-24
• 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
• Milestone linked
• Documentation logged in pending release pages
• 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

[packet-rat]

?The Machine” opined and: In the context of emerging SBOM (Software Bill of Materials) information models, "Operating System" and "Software" are indeed treated with specific hierarchical relationships. 1. Software: This is the broad category that encompasses all forms of computer programs, including applications, utilities, and operating systems. It generally refers to any set of instructions that direct a computer to perform specific tasks. 2. Operating System (OS): An operating system is a specific type of software that manages computer hardware and software resources and provides common services for computer programs. Hierarchical Relationship In most SBOM information models, the "Operating System" is considered a subclass of "Software." This means: · Software is the parent class that includes all types of software. · Operating System is a specialized category within the broader class of Software. Example Representation Here’s a simplified representation of the hierarchical relationship: Software │ ├── Application Software │ ├── Word Processor │ ├── Web Browser │ └── Email Client │ ├── System Software │ ├── Operating System │ │ ├── Windows │ │ ├── Linux │ │ └── macOS │ ├── Device Drivers │ └── Utility Programs SBOM Standards and Models Standards such as SPDX (Software Package Data Exchange) and CycloneDX offer frameworks for defining and managing SBOMs. These standards help ensure that the relationship between "Operating System" and "Software" is clearly defined and consistently represented. · SPDX: The SPDX specification provides a structured way to describe the components and dependencies of software, including operating systems as part of the overall software ecosystem. · CycloneDX: CycloneDX is another SBOM standard that supports detailed descriptions of software components, including operating systems as specific entries within the broader software category. Importance in SBOM Understanding the relationship between operating systems and other software components is crucial for: · Security: Identifying vulnerabilities and managing patches effectively. · Compliance: Ensuring adherence to licensing and regulatory requirements. · Dependency Management: Recognizing how different software components interact and depend on one another. In conclusion, within SBOM information models, the "Operating System" is indeed treated as a direct subclass of "Software," reflecting its role as a fundamental type of system software within the broader software category. [A blue circle with text Description automatically generated] Patrick Maroney | Principal – Cybersecurity | AT&T Services, Inc. Threat Analytics e: ***@***.******@***.***> | p: 732.615.5287 [Image] From: Alex Nelson ***@***.***> Date: Friday, September 13, 2024 at 11:30 AM To: ucoProject/UCO ***@***.***> Cc: Subscribed ***@***.***> Subject: [ucoProject/UCO] Operating systems should be recognized as specializations of software (Issue #632) Background observable: OperatingSystem is currently a direct subclass of observbable: ObservableObject, with no relationship to observable: Software. Issue 596 proposes a restructuring of classes pertaining to software, including making OperatingSystem Background observable:OperatingSystem is currently a direct subclass of observbable:ObservableObject, with no relationship to observable:Software. Issue 596<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/596__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHiFfcglw$> proposes a restructuring of classes pertaining to software, including making OperatingSystem a direct subclass of Software. Issue 626<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/626__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHYlIVsTA$> implements a constraint on describing operating systems with observable:cpeid, that is reliant on OperatingSystem being a subclass of Software as is consistent with the CPE model (i.e., in NISTIR 7695<https://urldefense.com/v3/__https:/nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHH8Bdg0Q$>). To the proposer's understanding, there is no operating system that is not, at least in part, software. This proposal is almost a fast-track change to change the parent class of OperatingSystem to Software; however, while reviewing data for demonstration, some property movements between Facets became apparent. Requirements Requirement 583-2 This requirement is ported from Issue 596, and is a reduction of a requirement ported from Issue 583<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/583__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHKEBG-NI$>: Ability to characterize different types of software objects At a minimum this should include Software, and OperatingSystem. Requirement 1 To prevent data placement confusion and synchronization issues, OperatingSystemFacet and SoftwareFacet must share no properties. Any shared properties should be placed only in SoftwareFacet. Currently, they both have the properties observable:manufacurer and observable:version. (This requirement is in addition to Issues 583 and 596, and was realized when sketching example data.) Risk / Benefit analysis Benefits * This proposal progresses software restructuring that is not blocked waiting on feedback. Risks 1. This change will exercise a part of Facets that might appear less than intuitive to users, though nothing will have changed about Facet design with this proposal. To describe an operating system with software characteristics, the properties will go in a SoftwareFacet attached to the OperatingSystem. Structurally, this is because while OperatingSystem would subclass Software, OperatingSystemFacet and SoftwareFacet remain independent classes. 2. While this proposal will remove some properties from observable:OperatingSystemFacet, UCO's current design practice of declining rdfs:domain and generally not using "Domain-reviewing" shapes (e.g. with sh:targetSubjectsOf and sh:targetObjectsOf) mean in UCO 2.0.0, it will not be an error to keep using observable:manufacturer or observable:version on observable:OperatingSystemFacet. Further, following current practice, users will be more free to use those properties on observable:OperatingSystemFacet, because SHACL usage is currently only defined in property shapes attached to classes. It will be possible for a user to record "observable:version": 1 as an integer, and UCO's SHACL will not flag it as an error. Adddressing this requires a global revision of UCO's property-review practice to follow what was done in only a few cases (e.g., types:repeatsKey<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/pull/607/files*diff-8b2786612dfe2bd9e7391e3e5483adc00670659e8a0c61682f57224f45e45d17R364-R368__;Iw!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHdnswLjg$> for Issue 602, and core:objectStatus<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/pull/631/files*diff-36fbd057dbb7e09c10fa272a10fe2ce47e0a6dc859b39b56cd1466e7578c1b9dR732-R736__;Iw!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacH6NKxGAE$> for Issue 549). This will need to be discussed separately, as there might need to be considerations for generated documentation. * If the properties should be disallowed from observable:OperatingSystemFacet, specific shapes can be added for UCO 2.0.0 that flag their usage as an error. This would be a special-case handling of only two properties. * Being able to provide migration guidance in UCO 1.4.0 before UCO 2.0.0 potentially mitigates this risk without needing to address the underlying UCO design matters. Competencies demonstrated Competency 1 A workstation has an instance of an operating system from Example OS Company. { ***@***.***": { "core": "https://ontology.unifiedcyberontology.org/uco/core/<https://urldefense.com/v3/__https:/ontology.unifiedcyberontology.org/uco/core/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHfChLmA0$>", "identity": "https://ontology.unifiedcyberontology.org/uco/identity/<https://urldefense.com/v3/__https:/ontology.unifiedcyberontology.org/uco/identity/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHexRTjZU$>", "kb": "http://example.org/kb/<https://urldefense.com/v3/__http:/example.org/kb/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHsICJI4I$>", "observable": "https://ontology.unifiedcyberontology.org/uco/observable/<https://urldefense.com/v3/__https:/ontology.unifiedcyberontology.org/uco/observable/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHq9HKIgU$>", "xsd": "http://www.w3.org/2001/XMLSchema#<https://urldefense.com/v3/__http:/www.w3.org/2001/XMLSchema*__;Iw!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacH5g9EO7E$>" }, ***@***.***": [ { ***@***.***": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54", ***@***.***": "identity:Organization", "core:name": "Example OS Company" }, { ***@***.***": "kb:OperatingSystem-427dd103-2553-4ccc-ad57-1df4e88b174d", ***@***.***": "observable:OperatingSystem", "core:description": "The Example Operating System instance deployed on workstation B-203-22", "core:hasFacet": [ { ***@***.***": "kb:SoftwareFacet-1bde46c5-4648-493c-b9dc-56477191d5c6", ***@***.***": "observable:SoftwareFacet", "observable:cpeid": "cpe:2.3:o:exampleosco:exampleos:40:*:*:*:*:*:*:*", "observable:language": "en-us", "observable:manufacturer": { ***@***.***": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54" }, "observable:version": "40" }, { ***@***.***": "kb:OperatingSystemFacet-35047ef2-ffd6-45e8-8b3c-2e8e4bfe7c2b", ***@***.***": "observable:OperatingSystemFacet", "observable:bitness": "64", "observable:installDate": { ***@***.***": "xsd:dateTime", ***@***.***": "2024-09-13T09:00:00-04:00" } } ] } ] } Competency Question 1.1 What is the query and result for finding the version of this operating system, specifying the specific Facet needed? Result 1.1 SPARQL query: SELECT ?lVersion WHERE { ?nOperatingSystem a observable:OperatingSystem ; core:hasFacet ?nFacet ; . ?nFacet a observable:SoftwareFacet ; observable:version ?lVersion ; . } Result: lVersion 40 Competency Question 1.2 Alternatively, how can the version of the operating system be found, without regard for what Facet is housing it? Result 1.2 SPARQL query: SELECT ?lVersion WHERE { ?nOperatingSystem a observable:OperatingSystem ; core:hasFacet / observable:version ?lVersion ; . } Result: lVersion 40 This is one motivation for removing observable:version from what would become a redundant placement in OperatingSystemFacet. Solution suggestion For UCO 1.4.0, implement the following warnings for backwards compatiblity: * Add a warning-shape to observable:OperatingSystem, that its instances must also be typed as observable:Software. This is as was done with moving observable:AlternateDataStream in Issue 590<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/590__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHf7h_agM$>. * Add new property shapes for observable:version and observable:manufacturer to observable:OperatingSystemFacet, setting only the constraint that they have a maximum-use count of 0, with a severity of sh:Warning. For UCO 2.0.0: * Change the parent class of observable:OperatingSystem to observable:Software. * Remove the class warning shape put in place for UCO 1.4.0. * Remove all property shapes for observable:version and observable:manufacturer from observable:OperatingSystemFacet; OR, remove the two properties' shapes that were in UCO 1.3.0, and upgrade the severity for the properties' warning shapes to sh:Violation (the SHACL default). — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/632__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHXhvxp5I$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AAYSFYKDNLDPJPDORIFOKVDZWMAG3AVCNFSM6AAAAABOFTLMJCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUZDKMJRGE2DIMQ__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacH6ogRPDg$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ajnelson-nist]

PRs #633 and #636 provide the implementations for UCO 1.4.0 and 2.0.0. (PR 636 currently has a noisy Git diff, but after #635 is merged it should simplify.)

All of the CASE example repositories needed updates to move manufacturer and version properties into SoftwareFacets. This frequently induced creating OperatingSystem objects and tying ObservableRelationships, because the housing OperatingSystemFacets were often on Device objects, and it seemed problematic to put a SoftwareFacet directly onto a Device object. Those interested in the total patch-effects should see the "remediation" links on PRs 633 or 636.

[sbarnum]

This looks good to me