0. Status of the Specification

CASE 1.0.0 is the first full release of the Cyber-investigation Analysis Standard Expression (CASE), which builds on and extends the Unified Cyber Ontology (UCO).

CASE 1.0.0 provides a stable version for adopters to use. Following SemVer, additive improvements will continue to be accepted, but backwards-incompatible changes will be scheduled only for the 2.0.0 release, which will come after at least 6 months to possibly 12 months.

Details of support for migrating from earlier versions of CASE to CASE 1.0.0 can be found at: Releases Archive.

1. Introduction

This ontology design document provides the specification for the CASE 1.0.0 ontology. The document covers: (1) the ontology engineering choices made in creating the CASE ontology, including the W3C standard ontology language (OWL 2), the knowledge representation approach including ontology design patterns, and the supported encodings; (2) the principal classes of entities included in the ontology to represent the cyber-investigation domain; and (3) the re-use of the Unified Cyber Ontology (UCO). Current documentation for UCO is available here.

1.1 The purpose of the CASE ontology

The growing number of investigations involving digital evidence from various data sources is driving the demand for a standard way to represent, analyze, and exchange pertinent information. The purpose of CASE is to provide a common language to support automated normalization, interoperation, combination and validation of varied information sources to facilitate analysis and exploration of investigative questions (who, when, how long, where). This ontology-based standard promotes the consistency and reliability of investigative information, and enhances analysis capabilities, including searching, correlation, contextual analysis, pattern recognition, machine learning, and visualization. To this end, CASE provides a standardized, machine-understandable representation for information commonly analyzed and exchanged by people and systems during investigations involving digital evidence. CASE also ensures that analysis results can be protected and traced back to their source(s), keeping track of when, where and who used which tools to perform investigative actions on data sources.

1.2 Domain of the CASE ontology

The principal domain of CASE is investigations involving digital evidence, including in criminal, cybersecurity, and intelligence contexts. The cyber-investigation domain places special requirements on the representation of investigation data, due to the nature of evidence and the need for traceability and flexibility in describing data with different degrees of certainty and/or at different stages of the investigation. These requirements are reflected in the namespace architecture and the design patterns used in the ontology.

1.3 Scope of the CASE ontology

The scope of the CASE ontology covers investigations in any context, including in criminal, cybersecurity, and intelligence. Digital evidence includes data sources (mobile devices, storage media, memory) and well-known digital objects such as files and folders, messages (email, chat), documents (PDF, Word), multimedia (pictures, video, audio) and logs (browser history, events). CASE ensures that analysis results can be traced back to their source(s), keeping track of when, where and who used which tools to perform investigative actions on data sources. These details are generally referred to as provenance (e.g., chain of custody) and lineage (e.g., chain of evidence). CASE aligns with the PROV-O ontology to support enhanced provenance tracking that is needed in more mature operating environments. Furthermore, data markings are baked into CASE to support protection of information.

1.4 Relationship to the Unified Cyber Ontology (UCO)

The CASE ontology is an extension of the Unified Cyber Ontology (UCO), which is imported by CASE. CASE re-uses concepts from UCO to represent objects in the cyber domain that are of interest in an investigation. Section 2 provides background about CASE as an extension of UCO. Section 7 addresses details of how CASE uses UCO concepts.

1.5 How to read this document

This document contains two main foci: (1) explanation of the formal organization, including the knowledge representation standards and structures used in CASE (Sections 3 – 5); (2) description of the specific domain content of the CASE ontology (Sections 6).

The format for CASE-compliant instance data is addressed in Section 8.

The full concrete specification of CASE 1.0.0 is expressed in the W3C OWL 2 Turtle (.ttl) syntax.

The latest release may be accessed from the CASE Community Release web page: https://caseontology.org/releases/archive/ .

1.6 Summary of important changes since the CASE prototype (CASE 0.1)

The initial CASE prototype was released in 2017 as a proof of concept. Early applications were developed to support use of the prototype.

The CASE prototype took shortcuts in the interest of quickly developing a proof of concept. Among those was the copying of concepts from the Unified Cyber Ontology (UCO) into the CASE prototype namespace. Subsequently, following ontological best practices beginning with version 0.2.0, the CASE ontology has been published with concepts specific to the domain of investigation in the CASE namespace and importation of general concepts for the cyber domain from UCO. The CASE community provided a Migration Guide for early adopters, as well as release notes describing changes and updates.

Significantly, the class Trace was changed to CyberItem, the class PropertyBundle was changed to Facet, and the property propertyBundle, was changed to uco-core:hasFacet.

1.7 Summary of important changes since CASE 0.2.0

CASE 0.2.0 (August 2020) implemented significant re-engineering based on ontology best practices. Concurrently, the CASE Community conducted a development process to ensure that CASE 1.0 would cover the domain concepts needed for a Minimum Viable Product (MVP) that could be used to encode cyber investigation data for exchange and analysis. CASE 0.2 incorporated some new concepts based on the early results of that process. The main part of that work is reflected in the expanded domain coverage of concepts in CASE 1.0.0.

Specific enhancements and expansion of CASE versions leading to CASE 1.0.0 are described in the release notes for each incremental version.

2. CASE as an Extension of the Unified Cyber Ontology (UCO)

2.1. CASE represents cyber-investigations

The purpose of CASE is to define concepts for representing cyber-investigations. Essential concepts for the representation of investigations include InvestigativeAction (human and tools) and ProvenanceRecord for tracking when, where and who performed investigative actions on data sources, with what tool when applicable, and evidence-based hypothesis evaluation (e.g., probability of evidence given alternative hypotheses).

• Casey, Barnum, Griffith, Snyder, van Beek, Nelson (2017) Advancing coordinated cyber-investigations and tool interoperability using a community developed specification language

• Casey, Barnum, Griffith, Snyder, van Beek, Nelson (2018) The Evolution of Expressing and Exchanging Cyber-Investigation Information in a Standardized Form

• Casey, Biasiotti, Turchi (2017) Using Standardization and Ontology to Enhance Data Protection and Intelligent Analysis

• Chabot, Bertauxa, Nicolle, Kechadi (2015) An ontology-based approach for the reconstruction and analysis of digital incidents timelines

• Casey, Back, Barnum (2015) Leveraging CybOX™ to standardize representation and exchange of digital forensic information

The fundamental objects that CASE imports from UCO include ObservableObject, Location, Tool and Identity, as well as Action, Annotation, and Relationship objects. The full list of CASE concepts is provided in Section 8.

For other concepts in the cyber domain, CASE imports UCO.

2.2. CASE imports UCO for general cyber-domain concepts

CASE imports the UCO ontology for use in representing objects and events that may be related to investigations (for example, computer files and electronic devices), but which are not inherently investigative concepts. By re-using cyber-domain concepts already defined by UCO, CASE takes advantage of work that experts have already done to represent the semantics of that domain in a machine-interpretable formalism. The UCO ontology includes both a model of the cyber-domain as understood by domain experts, and a terminology used by experts to describe the cyber-domain.

With the release of CASE 1.0.0, the version of UCO that is imported will match, starting with UCO 1.0.0.

2.3. CASE aligns with ontology design patterns of UCO

The fundamental objects of study in cyber-investigations are the perceptible results of an event of interest. To represent these objects and their context, CASE makes use of ontology design patterns implemented in UCO, including those for Facet, ObservableObject, and Relationship.

2.3.1.    Facet and Observable Object

An Observable Object can be enriched with one of more Facets, each with its own set of properties. Facets provide flexibility for representing the wide variety of data structures that can be encountered in cyber domains, and permit custom (non-standard) properties to be added if needed for internal or proprietary systems.

Further design details about Facet and ObservableObject are provided in the UCO Design Document.

In UCO, ObservableObject is an owl:Class whose instances represent individuals in the cyber domain. Certain aspects of those individuals are described using properties defined on the ObservableObject class; however, other descriptions may be applied to the instance by linking it to one or more Facet-instances. UCO defines Facet as an owl:Class representing a grouping of properties. Property assignment – that is, descriptions of individuals – using Facets differs from descriptions by properties defined directly on the ObservableObject class of which an individual is an instance.

Properties defined on the class ObservableObject are those whose values are not expected to change when an individual is described, while the properties defined in a Facet class are used to assign values that may be updated in the future. Properties can include date-time stamps, the contents of an ObservableObject, the hash values (e.g., MD5 and SHA256) of the data, and other details. Properties are attributed to an ObservableObject using Facets (“hasFacet”), effectively using duck typing (enriching the object with the pattern relating Facet instances to instances of ObservableObject).

A Facet is represented by an owl:Class. However, its instances are not domain individuals (e.g., files, accounts). Instead, they are anonymous individuals that organize properties to describe other individuals which are instances of Observable Object (or one of its subclasses).

The current range of UCO Facet subclasses with their associated definitions and properties are searchable in the Classes Tree.

An important use of subclasses is in the properties deviceType and filesystemType, which are fields that house free-form text descriptions of the type of device that an analyst has encountered. The `@type` field should be preferred when a subclass of `observable:Device` or `observable:FileSystem` are defined and known to the analyst. When those are not known, `deviceType` and `filesystemType` should be used to cover the representation gap. Be aware that with the breadth of types available, full coverage is acknowledged as an impossible problem. The CDO community welcomes feedback on knowledge gaps so taxonomic classes can be standardized, and interoperability improved.

2.3.2.    References

Within a Facet, certain Properties reference another object that is linked immutably, i.e., the link will never change. Such linked objects are represented using an identifier reference that specifies the @id of another object. For example, the manufacturer of a device is represented as a reference within the DeviceFacet:

https://github.com/casework/CASE-Examples/blob/master/examples/illustrations/device/device.json

2.3.3.    Relationships

In addition to using Properties as defined in OWL 2, UCO defines a class, Relationship, in order to represent information about relationships (such as their duration) that cannot be captured otherwise. For those familiar with UML, a UCO Relationship is similar in structure and purpose to a UML Association Class.

As a general rule, a link between two objects should be represented as an independent Relationship object specifying the type of connection (a.k.a. external relationship). An example “contained-within” Relationship is the representation of a SIM card contained within a mobile device:

https://github.com/casework/CASE-Examples/tree/master/examples/illustrations/mobile_device_and_sim_card

2.3.4.    Domain Assertions

In the OWL 2 language, domain assertions (i.e., using rdfs:domain) are not constraints on the use of properties. They are expressions of knowledge about the kind of thing to which a property is expected to apply, and those assertions can be used as the basis of an inference that an individual that is the subject of such a property is of a specific kind. [Include explanation of Open World Assumption and consequences of reasoning based on it.]

Domain assertions for properties are included in the CASE ontology to capture knowledge about the type(s) of entity to which a property normally applies. However, CASE implements a design pattern in which those domain assertions are defined in a separate namespace (and ontology document) that may optionally not be loaded with the main ontology. This is to prevent unwanted inferences (based on domain assertions) about the types of individual entities, in applications where an  imposition of domain types on individual entities whose specific type is either unknown or may conflict with the expected type, may result in unwanted consequences.

2.4. Cooperation of the CASE and UCO Communities

The CASE Community has formalized its working relationship with the UCO Community, including written guidance on common software development practices.

3.   Domain and Scope of CASE

3.1. Cyber-investigation

Cyber-investigation is the principal domain of the CASE ontology, and is defined most broadly to cover any context, including in criminal, cybersecurity, and intelligence. In cybersecurity contexts, the detection of a potential incident by a Security Operations Center (SOC) is the starting point of an investigation that can lead to Digital Forensics & Incident Response (DFIR), and ultimately legal action (e.g., regulatory compliance, criminal prosecution). In criminal contexts, the reporting of an offense initiates an investigation, followed by preservation and analysis of evidence, with the aim of apprehending and prosecuting perpetrators. In intelligence contexts, such as counter-terrorism operations, an investigation can combine information from various sources to support analysis and decision-making.

3.2. Provenance

In any investigation, it is important to maintain links between data sources, their treatment, and analysis results. CASE includes concepts for keeping track of when, where and who used which tools to perform investigative actions on data sources. These details are generally referred to as provenance (e.g., chain of custody) and lineage (e.g., chain of evidence). CASE tracks provenance and lineage with the combination of ProvenanceRecords and InvestigativeActions on data as shown here.

CASE aligns with the PROV-O ontology to support enhanced provenance tracking that is needed in more mature operating environments. The PROV-O enhanced representing of the Urgent Evidence scenario is depicted here.

4.   CASE is an OWL Ontology

4.1. Introduction

The CASE ontology is a representation of the cyber-investigation domain created using the OWL 2 Web Ontology Language (informally, “OWL 2”). OWL 2 is a W3C Recommendation (https://www.w3.org/TR/owl2-overview/ ). The primary rationale for using OWL 2 is compatibility with other OWL 2 ontologies, enabling reuse of existing representations such as the Semantic Sensor Network (SSN) ontology and the Quantity, Unit, Dimension and Type (QUDT) ontology. The widespread use of OWL 2 supporting Semantic Web provides a stable foundation for development and interoperability. 

4.2. Profile of OWL

To ensure compatibility with other OWL ontologies, CASE uses OWL DL rather than more restrictive profiles or OWL Full.[1] The original OWL profiles OWL Lite and OWL 1 DL are considered valid profiles of OWL 2 (see Section 1 at that URL). CASE probably will not be able to support more restrictive OWL Profiles.

Throughout the development of CASE and UCO, consideration has been given to the constraints of OWL profiles. See definitions of the OWL 2 profiles: https://www.w3.org/TR/owl2-profiles/ .

Currently, it is necessary to check whether CASE and UCO violate a constraint of OWL 2 DL: (https://www.w3.org/TR/owl-syntax/#Entity_Declarations_and_Typing ). Note the typing constraint in 5.8.1 Typing Constraints of OWL 2 DL: “No IRI I is declared in Ax [a set of axioms] to be both a class and a datatype.”]

5.   CASE Ontology Architecture and Namespaces

The CASE ontology extends UCO with the Investigation namespaces and associated domain specific vocabulary.

• The namespace for the CASE ontology is https://ontology.caseontology.org/case/. UCO and CASE now have a similar IRI structure, including use of sub-ontologies implemented as independently importable namespaces.

• CASE now provides the Investigation sub-ontology, with the IRI https://ontology.caseontology.org/case/investigation/. Enumerations supporting this sub-ontology are in the vocabulary sub-ontology, with the IRI https://ontology.caseontology.org/case/vocabulary/. These files were imported without revision, aside from minimal IRI string substitution, from UCO.

Alexander Nelson [Insert a diagram of CASE namespace and import structure. In this one, UCO could be shown as one shaded block, with a detailed diagram of UCO namespaces used by CASE shown later.]

6.   Ontology Design Patterns Used in CASE

6.1. Introduction

This section presents the principal ontology design patterns used in CASE 1.0. As introduced in Section 2.3, some CASE design patterns are based on those of UCO. Other patterns, including those used for representing investigations and provenance, are unique to CASE. The CASE ontology patterns described in this section should be considered best practices for extensions of CASE.

The CASE bundle header provides context for the investigation and represented information.

{
  "@context":{
    "": "http://example.org/kb#",
    "@vocab": "http://example.org/ontology/local#",
    "case-core": "https://caseontology.org/ontology/case/core#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "uco-action": "https://unifiedcyberontology.org/ontology/uco/action#",
    "uco-core": "https://unifiedcyberontology.org/ontology/uco/core#",
    "uco-investigation": "https://unifiedcyberontology.org/ontology/uco/investigation#",
    "uco-observable": "https://unifiedcyberontology.org/ontology/uco/observable#",
    "uco-tool": "https://unifiedcyberontology.org/ontology/uco/tool#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@id":":bundle-32467e43-3d56-4a66-a483-db22cb56e6b9",
  "@type":"uco-case:Bundle",
  "uco-case:description":"Investigation of any crime type",
  "uco-case:object":[
    {
      "@id":":investigation-12ea9028-290b-46f9-9c8a-d49d00351a3a",
      "@type":"case-investigation:Investigation",
      "uco-core:name":"Investigation_2021_0415",
      "uco-core:focus":"Robbery",
      "uco-core:description":"The theft of intellectual property",
      "uco-core:object":[list of uuids in bundle OR list of uuids of ProvenanceRecords and InvestigatigveActions
    }
  ]
}

The object property in a CASE bundle header can provide a comprehensive list explicit referencing all objects in the bundle, or a shorter list of PropertyBundles and InvestigativeActions which contain implicit references to all objects in the bundle.

6.3. Tools

The ConfiguredTool object is used to represent tools that are used to treat data, including their configuration options.

{
  "@id": ":configuredtool-771f892b-9830-4d71-b0a2-bcff5072ec80",
  "@type":"uco-tool:ConfiguredTool",
  "uco-tool:name":"dc3dd",
  "uco-tool:toolType":"acquisition",
  "uco-tool:creator":"DC3",
  "uco-tool:version":"7.2.646",
  "uco-configuration:usesConfiguration": {
    "@id": "kb:configuration-33b352c2-478d-4bb1-b758-49df5cc0cd49",
    "@type": "uco-configuration:Configuration",
    "uco-configuration:configurationEntry":[
        {
          "@type":"uco-configuration:ConfigurationEntry",
          "uco-configuration:itemName":"bs",
          "uco-configuration:itemValue":"4k"
        },
        {
          "@type":"uco-configuration:ConfigurationEntry",
          "uco-configuration:itemName":"hash",
          "uco-configuration:itemValue":"md5"
        },
        {
          "@type":"uco-configuration:ConfigurationEntry",
          "uco-configuration:itemName":"log",
          "uco-configuration:itemValue":"dc3dd.log"
        },
        {
          "@type":"uco-configuration:ConfigurationEntry",
          "uco-configuration:itemName":"command_line_arguments",
          "uco-configuration:itemValue":"dc3dd if=/dev/sdc of=sdc.dd bs=4k hash=md5 log=dc3dd.log"
        }
      ]
    }
},

6.2. InvestigativeAction and Role

CASE uses InvestigativeActions to represent actions taken as part of an investigation, including initial evidence collection, subsequent tool processing, analysis activities, and reporting results. As a subclass of Action in UCO, an InvestigativeAction references the location, performer, instrument, and environment as well as the input object and output result.

Notably, the initial InvestigativeAction of seizing/receiving data sources has a null input and a performer property that references a Role. Assigning a Role within a specific context allows the same person to have multiple roles in different contexts. For example, in the Oresteia example, Clytemnestra has the Role of Offender in Crime E and the Role of Victim in Crime F. Also see https://doi.org/10.1016/j.diin.2018.10.001

{
  "@id": "kb:action-20e71c39-3a5a-4d7a-a01d-95dc6545d31e",
  "@type": "case-investigation:InvestigativeAction",
  "uco-core:description": "Items collected at scene",
  "uco-core:hasFacet": {
      "@type": "uco-action:ActionReferences",
      "uco-action:endTime": {
                    "@type": "xsd:dateTime",
                    "@value": "2021-04-01T14:00+00:00"
                },
      "uco-action:location": {
                    "@id": "kb:location-dd8d6513-389c-413f-9f30-cf75e24ad838"
                },
      "uco-action:performer": {
                    "@id": "kb:role-d2cd172c-bc44-429f-be13-d4ea58480852"
                },
      "uco-action:result": [
                    {
                        "@id": "kb:provenancerecord-a5c55cda-c515-4bd5-9f34-f65176ee6d4f"
                    },
                    {
                        "@id": "kb:device-0e3d3524-c19d-4c22-9edd-2a6e65f82bd7"
                   },
                   ... <list all items>
                    {
                        "@id": "kb:device-4358a269-4159-4475-820e-b67660f9c55c"
                    }
                ]
      }
},
{
  "@id": "kb:provenancerecord-a5c55cda-c515-4bd5-9f34-f65176ee6d4",
  "@type": "case-investigation:ProvenanceRecord",
  "case-investigation:exhibitNumber": "URI-1234",
  "case-investigation:rootExhibitNumber": "URI-1234",
  "uco-core:object": {
                "@id": "kb:device-0e3d3524-c19d-4c22-9edd-2a6e65f82bd7"
  }
},
{
  "@id": "kb:location-dd8d6513-389c-413f-9f30-cf75e24ad838",
  "@type": "uco-location:Location",
  "uco-core:description": "Location where evidence was seized",
  "uco-core:hasFacet": {
  "@type": "uco-location:LatLongCoordinatesFacet",
  "uco-location:latitude": "46.537222222222219",
  "uco-location:longitude": "6.5791666666666666",
  }
},
{
  "@id": "kb:role-d2cd172c-bc44-429f-be13-d4ea58480852",
  "@type": "uco-role:Role",
  "uco-core:name": "Investigator"
},
{
  "@id": "kb:identity-b02bc46d-3dbb-49a4-9e6d-27a89f162f96",
  "@type": "uco-identity:Identity",
  "uco-core:hasFacet": [
                {
                    "@type": "uco-identity:SimpleName",
                    "uco-identity:givenName": "James",
                    "uco-identity:familyName": "Reese"
    }
  ]
},

Part of acquiring digital evidence can involve photographing items using a digital camera for documentation. Any Any InvestigativeAction can reference the tool used to treat the data as the instrument which reference a ConfiguredTool object.

       {
            "@id": "kb:analytictool-34eefb72-19c8-42c8-933c-3c1e13372e491",
            "@type": [
                "uco-observable:ObservableObject",
                "uco-tool:AnalyticTool"
            ],
            "uco-core:hasFacet": [
                {
                    "@type": "uco-observable:DeviceFacet",
                    "uco-observable:deviceType": "camera",
                    "uco-observable:manufacturer": "Canon",
                    "uco-observable:model": "PowerShot SX540"
                }
            ],
            "uco-tool:creator": "Canon"
        },
        {
            "@id": "kb:action-5f560f12-2be5-4b9a-a8e8-96aa4e2d0c13",
            "@type": "case-investigation:InvestigativeAction",
            "uco-core:name": "Photographed exhibits",
            "uco-core:hasFacet": {
                "@type": "uco-action:ActionReferences",
                "uco-action:endTime": {
                    "@type": "xsd:dateTime",
                    "@value": "2021-04-01T14:15+00:00"
                },
                "uco-action:instrument": {
                    "@id": "kb:analytictool-34eefb72-19c8-42c8-933c-3c1e13372e491"
                },
                "uco-action:location": {
                    "@id": "kb:location-dd8d6513-389c-413f-9f30-cf75e24ad838"
                },
                "uco-action:performer": {
                    "@id": "kb:role-d2cd172c-bc44-429f-be13-d4ea58480852"
                },
                "uco-action:object": [
                    {
                        "@id": "kb:provenancerecord-a5c55cda-c515-4bd5-9f34-f65176ee6d4f"
                    },
                    {
                        "@id": "kb:device-0e3d3524-c19d-4c22-9edd-2a6e65f82bd7"
                    }
                ],
                "uco-action:result": [
                    {
                        "@id": "kb:provenancerecord-a73ef018-75b2-4522-b485-979ecb36d624"
                    },
                    {
                        "@id": "kb:camera-mediacard-def63f6a-d031-4104-91b9-76f060a0ece9"
                    }
                ]
            },

6.3. Facets of Observable Objects

CASE can enrich ObservableObjects using Facets defined in UCO, as well as custom facets not currently defined in the ontology. For instance, a digital photograph is represented as an ObservableObject with the RasterPictureFacet (see example https://github.com/casework/CASE-Examples/blob/555c756ba7364ee0c4849f14cc1426dc68bc5a48/examples/exif_data.json ). This Figure depicts a digital photograph that has been enriched with a custom Facet to define properties associated with contraband using a chosen scale (e.g., COPINE, SAP).

Figure: Observable Object with Facets that represent properties of a File that is a Picture that a custom facet.

This depicted example can be represented in CASE as follows:

{
            "@id": "kb:file-fa836108-ed37-44b0-9b2b-0b61c4a0590d",
            "@type": "uco-observable:File",
            "uco-core:hasFacet": [
                {
                    "@type": "uco-observable:FileFacet",
                    "uco-observable:fileSystemType": "EXT4",
                    "uco-observable:fileName": "IMG_0123.jpg",
                    "uco-observable:filePath": "/sdcard/IMG_0123.jpg",
                    "uco-observable:extension": "jpg",
                    "uco-observable:sizeInBytes": {
                        "@type": "xsd:long",
                        "@value": 35002
                    }
                },
                {
                    "@type": "uco-observable:RasterPictureFacet",
                    "uco-observable:pictureType": "jpg",
                    "uco-observable:pictureHeight": 12345,
                    "uco-observable:pictureWidth": 12345,
                    "uco-observable:bitsPerPixel": 2
                },
                                {
                    "@type": "example-custom:Contraband",
                    "example-custom:scaleType": "COPINE",
                    "example-custom:scaleCategory": 5
                },
                {
                    "@type": "uco-observable:ContentDataFacet",
                    "uco-observable:byteOrder": "BigEndian",
                    "uco-observable:magicNumber": "/9j/ww==",
                    "uco-observable:mimeType": "image/jpg",
                    "uco-observable:sizeInBytes": {
                        "@type": "xsd:long",
                        "@value": 35000
                    },
                    "uco-observable:dataPayload": "<base 64 encoded data of the file>",
                    "uco-observable:hash": [
                        {
                            "@type": "uco-types:Hash",
                            "uco-types:hashMethod": {
                                "@type": "uco-vocabulary:HashNameVocab",
                                "@value": "SHA256"
                            },
                            "uco-types:hashValue": {
                                "@type": "xsd:hexBinary",
                                "@value": "6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b"
                            }
                        }
                    ]
                }
}

6.4. References

When data contains immutable/unchanging links between objects, this is represented using an embedded reference. For instance, the manufacturer of a device is represented as an embedded reference in the DeviceFacet.

    {
        "@id": "kb:kb:disk-e598c1b3-f76d-4c27-b592-49bfdbf23d11",
        "@type": "uco-observable:Disk",
        "uco-core:hasFacet" [
            {
                "type" "uco-observable:DiskFacet"
                "uco-observable:model" "TOSHIBA_MQ01ABD100"
                "uco-observable:serialNumber" "Z612S32MS"
                "uco-observable:capacity" "1000204886016"
                "uco-observable:manufacturer" "kb:org-toshiba-d7ce213d-7d2c-4dc7-aa57-33d5792f3078"
            }
        ]
    }

As another example, in an email message, the sender and recipient accounts are represented as an embedded reference.

    {
    {
        "@id": "kb:emailmessage-56ee7f1d-6710-421b-b22a-67110ff0d4ff",
        "@type": "uco-observable:EmailMessage",
        "uco-core:hasFacet": [
            {
                "@type": "uco-observable:EmailMessageFacet",
                "uco-observable:subject": "Bank transfer ?",
                "uco-observable:sentTime": {
                    "@type": "xsd:dateTime",
                    "@value": "2018-11-20T00:00:30+00:00"
                },
                "uco-observable:from": {
                    "@id": "kb:emailaccount-75f2bf72-5239-4d2b-9ac5-f6e778bdf877"
                },
                "uco-observable:to": {
                    "@id": "kb:emailaccount-2932a717-db7c-4fa2-b435-28a34538312d"
                }
            }
        ]
    }

6.5. Relationships as Classes

Relationship are intentionally flexible to allow mutable/changeable links or associations to be defined between any object. For instance, a relationship between one object and another (e.g., SIM card in a mobile device) can last for a limited time period, and then can change (e.g., moving the SIM card to another mobile device). The “Contained_Within” relationship is commonly used in CASE. The following example represents the relationship between a SIM card and the mobile device it was contained within.

    {
        "@id": "kb:simcard1-relationship-a1dbff0e-974b-4295-b035-e1bc3271945d",
        "@type": "uco-observable:ObservableRelationship",
        "uco-core:source": {
            "@id": "kb:simcard-24d20c80-f035-40ae-88dd-fc66f70180f6"
        },
        "uco-core:target": {
            "@id": "kb:lge-device-eee670c6-01d4-4e42-bb6b-ebeca149b168"
        },
        "uco-core:kindOfRelationship": {
            "@type": "uco-vocabulary:ObservableObjectRelationshipVocab",
            "@value": "Contained_Within"
        },
        "uco-core:isDirectional": true
    }

A relationship object can be enriched with a Facet such as the physical location of one object within another. In the following example, the DataRangeFacet is used to specify where a partition is located within a piece of storage media or forensic copy.

    {
        "@id": "kb:partition-87d669fc-8ab9-47c6-a66d-af09d73361d5",
        "@type": "uco-observable:ObservableRelationship",
        "uco-core:source": {
            "@id": "kb:userdata-partition-d94cd1b5-5cf7-4642-8927-5ebea573d68e"
        },
        "uco-core:target": {
            "@id": "kb:f3fd304e-ef6c-4cbd-94cb-425880f82748"
        },
        "uco-core:kindOfRelationship": {
            "@type": "uco-vocabulary:ObservableObjectRelationshipVocab",
            "@value": "Contained_Within"
        },
        "uco-core:isDirectional": true,
        "uco-core:hasFacet": [
            {
                "@type": "uco-observable:DataRangeFacet",
                "uco-observable:rangeOffset": 2032140288,
                "uco-observable:rangeSize": 29236373504
            }
        ]
    }

CASE also uses the PathRelationFacet on relationships between a file and its logical location within a file system.

    {
        "@id": "kb:filesystem-relationship-f64f857e-6c87-417f-9166-5aaaed8a6fd2",
        "@type": "uco-observable:ObservableRelationship",
        "uco-core:source": {
            "@id": "kb:downloaded-file-3961dae3-2bca-4ccb-97fd-9919192e81db"
        },
        "uco-core:target": {
            "@id": "kb:filesystem-e2a02b5a-7e7e-489f-ab43-3ffadab4ac82"
        },
        "uco-core:kindOfRelationship": {
            "@type": "uco-vocabulary:ObservableObjectRelationshipVocab",
            "@value": "Contained_Within"
        },
        "uco-core:isDirectional": true,
        "uco-core:hasFacet": [
            {
                "@type": "uco-observable:PathRelationFacet",
                "uco-observable:path": "/img_LGE Nexus 5 Full Image.raw/vol_vol31/media/0/Download/download.jpg"
            }
        ]
    }

6.6. Vocabularies

The vocabularies used in CASE and UCO are semi-open, so that other non-standardized values can be used if the defined vocabulary does not contain a suitable selection. To maintain consistency, it is recommended to add new terms to the vocabulary whenever feasible.

6.7. Separate Namespace for Domain Assertions

CASE follows the UCO pattern of using separate name spaces for domain assertions, and uses the same conventions for naming classes and properties. Within CASE, the Investigation namespace contains concepts and terms specific to cyber-investigations.

6.8. Cyber-investigation patterns

The domain of the CASE ontology is cyber-investigations in general, and includes contextual information about an incident/incident as shown here, as well as provenance information as shown in the next section.

    {
        {
            "@id": "kb:bundle-5715fcf3-6bc8-4996-8f7f-fdf289f31649",
            "@type": "uco-core:Bundle",
            "uco-core:description": "Evidence in cross border investigation into weapon of mass destruction",
            "uco-core:object": [
                {
                    "@id": "kb:investigation2-2ca2b7dd-da07-4ad4-9deb-0a0c4c6ff4f6",
                    "@type": "case-investigation:Investigation",
                    "uco-core:name": "CROSSOVER_2018_12111001",
                    "case-investigation:focus": "Weapon of Mass Destruction (Deathly Hallows)",
                    "uco-core:description": "The subject Ares Lupin was arrested on suspicion of acquiring a weapon of mass destruction. The Samsung smartphone he was carrying was preserved as evidence.",
                    "uco-core:object": [
                        "list of uuids"
                    ]
                }
            ]
        }
    }

6.9. Provenance patterns

Provenance of evidentiary material in an investigation needs to be tracked. Therefore, the CASE ontology includes concepts for representing the source and chain-of-custody (including any operations) for evidence related to an investigation.

    {
        "@id": "kb:provenance-record-b84dc6ca-6187-4fc3-b5f1-c15142b103a8",
        "@type": "case-investigation:ProvenanceRecord",
        "case-investigation:exhibitNumber": "C001-HD1",
        "case-investigation:rootExhibitNumber": "Collection-001",
        "uco-core:description": "Forensic duplicate of hard drive used by subject",
        "uco-core:object": [
            {
                "@id": "kb:hard-drive-d3a2304e-ef6c-4cbd-94cb-425880f88546"
            }
        ]
    },

• In a ProvenanceRecord, the rootExhibitNumber is a unique identifier assigned to a set of objects at the start of their treatment as part of an investigation. A subsequent ProvenanceRecord can reference more than one rootExhibitNumber when information combines multiple sources.

• At any stage during the treatment of data, a unique exhibitNumber can be assigned in a ProvenanceRecord by the performer/instrument to differentiate it from other objects within the given context.

• The optional informedBy relationship between InvestigativeActions explicitly represents backtracking links in the provenance/lineage of an object. An InvestigativeAction can only have one link back to the causal InvestigativeAction.

• The optional derivedFrom relationship between objects explicitly represents backtracking links in the provenance/lineage of an object. An object can have multiple derivedFrom links back to multiple objects. There is currently no way to track the scenario of a bulk input to an InvestigativeAction with multiple outputs that are not explicitly linked to specific parts of the bulk input (this is currently left to the user, but could be discussed in future).

7.   CASE Re-use of Concepts in UCO 

This section describes the re-use of concepts from the Unified Cyber Ontology (UCO). With respect to UCO content, this section is informative, not normative. The authoritative documentation and encodings of UCO are published at the UCO website [https://unifiedcyberontology.org/ ]. With respect to the use of UCO with CASE, however, this section should be considered prescriptive. The UCO concepts discussed herein are those that CASE re-uses directly or may interface with.

7.1. UCO Objects

A UCO object is a representation of a fundamental cyber-relevant concept either directly inherent to the cyber domain or indirectly related to the cyber domain and necessary for contextually characterizing cyber domain concepts and relationships. Within the Unified Cyber Ontology (UCO) structure this is the base class defining the minimal core set of properties to act as a consistent, unifying, and interoperable foundation for all explicit and inter-relatable content objects. Objects and Object Identifiers are described in Sections 3 and 4 of the UCO Design Document.

7.1.1.    Relationships

See Section 6 of the UCO Design Document.

7.2.  UCO Facets

See Section 5 of the UCO Design Document.

7.3.  UCO Vocabularies

See Section 8 of the UCO Design Document.

8.   Instance Data in CASE

 Data represented using the CASE ontology is serialized in the syntax JSON-LD (https://www.w3.org/2018/json-ld-wg/ ; specification: https://www.w3.org/TR/json-ld11/ ). 

9.        License for CASE

 All new inbound code contributions to CASE and specifications must be made using the Apache License, Version 2.0, available at https://www.apache.org/licenses/LICENSE-2.0

Documentation other than specifications will be received and made available under the Creative Commons Attribution 4.0 International License (available at http://creativecommons.org/licenses/by/4.0/ ).

10.        Acknowledgements

Development of CASE began in 2014 as a collaboration between the DoD Cyber Crime Center (DC3) and MITRE, led by Dr. Eoghan Casey and Sean Barnum, involving the National Institute of Standards and Technology (NIST). In response to international interest, this initiative became an open source evolving standard, with hundreds of participants in industry, government and academia around the globe.

Early contributors include the Netherlands Forensic Institute (NFI), the Italian Institute of Legal Informatics and Judicial Systems (IGSG-CNR), FireEye, and University of Lausanne. CASE governance and community coordination were formalized with support of Harm van Beek, Rich Brown, Ryan Griffith, Cory Hall, Christopher Hargreaves, Jessica Hyde, Deborah Nichols, and Martin Westman. Growing international involvement is tracked on the CASE website: https://caseontology.org/community/members.html

[1] “Profiles” is the current W3C designation for subsets of OWL 2 that are restricted for certain representational and/or computational purposes. Other (and past W3C) sources have referred to OWL profiles as “dialects” (e.g., https://graphdb.ontotext.com/documentation/8.0/enterprise/introduction-to-semantic-web.html), “species” (e.g., https://www.w3.org/2007/OWL/wiki/Profile_Explanations ), or “flavors” (e.g., https://www.cambridgesemantics.com/blog/semantic-university/learn-owl-rdfs/flavors-of-owl/).