ucoProject / UCO

This repository is for development of the Unified Cyber Ontology.
Apache License 2.0
78 stars 34 forks source link

EventFacet Duration #396

Closed kchason closed 2 years ago

kchason commented 2 years ago

Background

The uco-observable:EventFacet contains a property createdDateTime but does not contain any sense of duration by means of a duration attribute or observable:endTime.

As at least one forensic tool has been identified to contain a start, end, and duration, UCO should similarly support the concept of duration.

Requirements

Requirement 1

Add a new property usage observable:endTime to the observable:EventFacet with a cardinality of 0 -> 1. As duration requires units that may add additional complexity, an "end" concept would be sufficient.

Requirement 2

Add a new property usage observable:startTime to the observable:EventFacet with a cardinality of 0 -> 1.

Risk / Benefit analysis

Benefits

Allows the concept of an event that is more than a single moment in time. Such examples may include operating system boot or application update.

Risks

As this is adding a new property and not removing or changing any existing representation, the submitter is unaware of risks associated with this change.

Competencies demonstrated

Competency 1

A user is reviewing results of a forensic investigation and is attempting to correlate all events that occurred on a device at a given point in time.

Competency Question 1.1

Can UCO support the question: What are all of the discrete events that were occurring on a device at 01 JUN 22 @ 19:48:01 EST?

Result 1.1

Selecting all events where the specified time is between EventFacet.startTime and EventFacet.endTime.

Solution suggestion

Add new property as defined in requirement 1.

Coordination

ajnelson-nist commented 2 years ago

The review checklist on PR 399 has been completed. No impact was observed on SHACL validation results.

ajnelson-nist commented 2 years ago

Something I just realized - there is a slight error in the description of this Issue. observable:endTime is not a new property. The association with observable:EventFacet is what this proposal is adding.

ajnelson-nist commented 2 years ago

This proposal digs a bit into UCO's general need to order temporally bound objects. I don't oppose adding another specialized term to set an interval closing. However, UCO should review its handling of time instants versus time intervals.

The W3C Time Ontology provides a figure demonstrating relations between time periods. UCO could project some objects into the Time Ontology and realize a general timeline (and timeline consistency review mechanism), but the projection is somewhat specialized according to whichever classes happen to have beginning-of-interval and end-of-interval time property-pairs, or some lone non-interval time property. E.g. if we add observable:endTime as in this proposal, an EventFacet could project into the Time Ontology like so:

kb:event-1
  a observable:Event;
  core:hasFacet [
    a observable:EventFacet ;
    observable:createdDateTime "2022-01-02T03:04:56Z"^^xsd:dateTime ;
    observable:endTime "2022-01-02T03:04:57Z"^^xsd:dateTime ;
    drafting:hasInterval [
      a time:ProperInterval ;
      time:hasBeginning [
        a time:Instant ;
        rdfs:comment "(Lexical value matches observable:createdDateTime, but the more stringent datatype `xsd:dateTimeStamp` is required in the Time Ontology.)"@en ;
        time:inXSDDateTimeStamp  "2022-01-02T03:04:56Z"^^xsd:dateTimeStamp .
      ] ;
      time:hasEnd [
        a time:Instant ;
        rdfs:comment "(Matches observable:endTime, after considering the same lexical-datatype issue as in the beginning interval.)"@en ;
        time:inXSDDateTimeStamp  "2022-01-02T03:04:57Z"^^xsd:dateTimeStamp .
      ] ;
    ] ;
  ] ;
  .

Projection into the Time Ontology would help us answer a few questions:

Projection into the Time Ontology is out of scope of this proposal, but it does raise one immediately relevant question - why are we defining the time bounds of Events in a Facet?

kchason commented 2 years ago

I was starting on a second proposal to convert the usage of observable:observableCreatedTime to observable:startTime but it really only makes sense for this facet since the others are more discrete occurrences versus a potentially time-bound event such as those this proposal aims to support. But I do think it would make sense to change the usage in this particular instance so the pairing is a lot cleaner.

Regarding the divide between Facet and Object, I thought we've been containing most properties in the Facets so they were more portable. Especially since Action and Relationship tend to be "linking" objects whereas the Event is more of a discrete object.

ajnelson-nist commented 2 years ago

From discussion on the OCs call this morning, this proposal expanded in scope to add startTime to pair with endTime, due to differing semantics between startTime and observableCreatedTime.

ajnelson-nist commented 2 years ago

The review checklist on PR 399 has been completed. No impact was observed on SHACL validation results.

The review checklist has been completed again, incorporating the added startTime usage.

sbarnum commented 2 years ago

Competency 1 - Result 1.1 should say: Selecting all events where the specified time is between EventFacet.startTime and EventFacet.endTime.