Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Operating systems should be recognized as specializations of software #632

Open
9 of 15 tasks
ajnelson-nist opened this issue Sep 13, 2024 · 3 comments · May be fixed by #633 or #636
Open
9 of 15 tasks

Operating systems should be recognized as specializations of software #632

ajnelson-nist opened this issue Sep 13, 2024 · 3 comments · May be fixed by #633 or #636
Labels
Change Proposal
Milestone
UCO 1.4.0

Comments

@ajnelson-nist
Copy link
Contributor

ajnelson-nist commented Sep 13, 2024 •
edited
Loading

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 (or 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 ajnelson-nist added this to the UCO 1.4.0 milestone Sep 13, 2024
ajnelson-nist added a commit that referenced this issue Sep 13, 2024
@ajnelson-nist
Prepare OperatingSystem to become a subclass of Software
62ebeab 
A follow-on patch will regenerate Make-managed files.

References:
* #632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist ajnelson-nist linked a pull request Sep 13, 2024 that will close this issue
Open
13 tasks
@ajnelson-nist ajnelson-nist linked a pull request Sep 13, 2024 that will close this issue
Issue 632: Prepare OperatingSystem to become a subclass of Software #633
Open
13 tasks
ajnelson-nist added a commit that referenced this issue Sep 13, 2024
@ajnelson-nist
Regenerate Make-managed files
40b285a 
References:
* #632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist ajnelson-nist mentioned this issue Sep 13, 2024
Open
17 tasks
@packet-rat
Copy link

packet-rat commented Sep 13, 2024 via email

ajnelson-nist added a commit that referenced this issue Oct 16, 2024
@ajnelson-nist
Change OperatingSystem parent class to Software; update previously-in…
2238622 
…-common property placement

A follow-on patch will regenerate Make-managed files.

References:
* #632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist ajnelson-nist linked a pull request Oct 16, 2024 that will close this issue
Draft
14 tasks
@ajnelson-nist ajnelson-nist linked a pull request Oct 16, 2024 that will close this issue
Issue 632: Change OperatingSystem parent class to Software #636
Draft
14 tasks
ajnelson-nist added a commit that referenced this issue Oct 16, 2024
@ajnelson-nist
Change OperatingSystem parent class to Software; update previously-in…
38c0fb3 
…-common property placement

A follow-on patch will regenerate Make-managed files.

References:
* #632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit that referenced this issue Oct 16, 2024
@ajnelson-nist
Regenerate Make-managed files
ca5ef43 
References:
* #632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Oct 16, 2024
@ajnelson-nist
Bump UCO to current state of unstable
8c55711 
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Oct 16, 2024
@ajnelson-nist
Bump UCO to current state of unstable-2.0.0
6dabc0d 
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Oct 16, 2024
@ajnelson-nist
Bump unstable pointers
ff32f1d 
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Oct 16, 2024
@ajnelson-nist
Regenerate Make-managed files
d45c080 
References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Oct 16, 2024
@ajnelson-nist
Migrate software properties of operating systems into new objects; ad…
73d429d 
…d relationships and provenance

A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Oct 16, 2024
@ajnelson-nist
Regenerate Make-managed files
3799583 
References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Oct 17, 2024
@ajnelson-nist
Bump unstable pointers
06e6586 
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Oct 17, 2024
@ajnelson-nist
Regenerate Make-managed files
57e2fbc 
References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Oct 17, 2024
@ajnelson-nist
Migrate software properties of operating systems into new objects; ad…
da056fc 
…d relationships

A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Oct 17, 2024
@ajnelson-nist
Regenerate Make-managed files
fb8600c 
References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Oct 17, 2024
@ajnelson-nist
Migrate software properties of operating systems into new facets
285fa97 
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Oct 17, 2024
@ajnelson-nist
Regenerate Make-managed files
4c92580 
References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Oct 17, 2024
@ajnelson-nist
Bump unstable pointers
b58a425 
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
This was referenced Oct 17, 2024
Merged
Merged
@ajnelson-nist
Copy link
Contributor Author

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.

ajnelson-nist added a commit to ajnelson-nist/CASE-Examples-QC that referenced this issue Oct 21, 2024
@ajnelson-nist
Bump pointers and regenerate Make-managed files
2e84bad 
References:
* ucoProject/UCO#632

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@sbarnum
Copy link
Contributor

sbarnum commented Oct 24, 2024

This looks good to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Change Proposal
Projects
None yet
Milestone
UCO 1.4.0
3 participants
@sbarnum @packet-rat @ajnelson-nist