Background

This Issue is a duplicate of UCO Issue 488, filed because UCO Issue 488 left handling typo review within CASE as out-of-scope.

Requirements

Requirement 1

Requirement 1 from UCO Issue 488 should carry over to CASE.

Risk / Benefit analysis

Benefits

• Aligns testing practices between UCO and CASE on design-vocabulary typo detection.

Risks

• UCO Issue 488 noted it was leaving making an exportable pytest function as out-of-scope. This Issue does not suggest anything more sophisticated than copying and pasting a pytest function, which creates a potential point of code-drift.

Competencies demonstrated

Competencies of UCO Issue 488 apply to CASE as well.

Fortunately, no typos were found, and the non-existent concept owl:ontologyIRI is already addressed in PR 118.

Solution suggestion

• Start implementation from the branch in CASE PR 118.
• Copy the pytest function test_rdf_design_vocabularies_defined from UCO.
• Copy the pytest unit test call logistics from UCO.

Coordination

• Tracking in Jira ticket ONT-490

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-10-26
• Solution announced to OCs on 2022-10-26
• Solutions Approval to be discussed in OC meeting, 2022-11-17
• Solutions Approval vote occurred, passing, on 2022-11-17
• Solutions development phase completed.
• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page

Issue ported from old casework github repo (issue 18).
Original author: casework

So DiskPartition has the following properties:

• mountPoint
• partitionID
• partitionLength
• partitionOffset
• spaceLeft
• spaceUsed
• totalSpace
• diskPartitionType
• createdTime

These properties seem to suggest that this property bundle should be placed in a Trace.
However, in plaso's use case, it needs to be placed in a Relationship object and only use a subset of these properties
(image -> partOffset = 4 -> the partition)
Should we create two separate property bundles like we did with File and PathRelation?

Issue ported from old casework github repo (issue 21).
Original author: casework

When I'm creating a trace with an Account property bundle, can I add SimpleName and SimpleAddress
directly on the trace as well? If not, how would I structure that?

Hi all and @ajnelson-nist in particular.

Since Investigation:Authorization was wrongly mentioned in the uco-core-da.ttl file (ucoProject/UCO#209 ), I should mention that either investigation:endTime rdfs:domain investigation:Authorization (and same for startTime), or these two properties should not be listed in blank nodes under investigation:Authorization.

Background

Requirements

Remove the text "Type" from the UCO ontology for the following Facet:

• tool.ttl:ToolConfigurationTypeFacet

so that it becomes

• tool.ttl:ToolConfigurationFacet

Requirement 1

Replace all occurances of the text "ToolConfigurationTypeFacet" with "ToolConfigurationFacet"
e.g. *.replace(current="ToolConfigurationTypeFacet", new="ToolConfigurationFacet")
within the:

• tool.ttl file (current)

  359   tool:ToolConfigurationTypeFacet
                          :
  365	    rdfs:label "ToolConfigurationTypeFacet"@en ;
                          :
  379       sh:targetClass tool:ToolConfigurationTypeFacet ;      

• tool.ttl file (after change)

  359   tool:ToolConfigurationFacet
                          :
  365	    rdfs:label "ToolConfigurationFacet"@en ;
                          :
  379       sh:targetClass tool:ToolConfigurationFacet ;      

Requirement 2

Check all examples within the master branch of:
 https://github.com/casework/CASE-Examples/tree/master/examples/

for any references affected by the change.
i.e. run a keyword search across all the files in the above folder, and all its sub-folders, for "ToolConfigurationTypeFacet"
Known changes:

• master/examples/illustrations/configured_tool/configured_tool.json (3 changes)

   24   {
   25       "@id": "kb:Tool-be707329-48fe-4d5d-84f3-7978ba63869e",
                        :
   35               "@type": "uco-tool:ToolConfigurationTypeFacet",    

   92   {
   93       "@id": "kb:Tool-f40e2a5f-7fdf-491f-8c87-b4cb766a6377",
                        :
  103               "@type": "uco-tool:ToolConfigurationTypeFacet",    

  160   {
  161       "@id": "kb:Tool-134e3cc0-7f74-4ea2-9ac1-3c447f4f6195",
                        :
  171              "@type": "uco-tool:ToolConfigurationTypeFacet",    

• master/examples/illustrations/Oresteia/Oresteia.json (2 changes)

 1110    {
 1111       "@id": "kb:tool2-uuid",
                        :
 1121               "@type": "uco-tool:ToolConfigurationTypeFacet",   

 1172    {
 1173       "@id": "kb:tool3-uuid",
                   :
 1182               "@type": "uco-tool:ToolConfigurationTypeFacet",    

Risk / Benefit analysis

Benefits

The changes provides better conformance with the standard CASE Facet guidance

Risks

1. Any developer code which currently hard codes the json-ld output using the existing "ToolConfigurationTypeFacet" name will need to amended to allow compability with future UCO\CASE versions.
   Note: Code which automatically generates output data directly from the versioned *.ttl files will be unaffected by the change.
2. Forked examples may not, by default, have the change in their existing copy.

Competencies demonstrated

After the change, re-run a text search across all the files in the following repositories:

Competency 1

Competency Question 1.1

Check that no hits are generated for the text pattern "ToolConfigurationTypeFacet" (case insensitive)

Result 1.1

The result should not return any Hits

Competency Question 1.2

Check that hits are generated for the text pattern "ToolConfigurationFacet" (case insensitive)

Result 1.2

Check that all hits are an exact match for "ToolConfigurationFacet" (case sensitive)

• tool.ttl (3 hits)
• configured_tool.json (3 hits)
• Oresteia.json (2 hits)

Solution suggestion

Make the changes suggested above.

Coordination

• Tracking in Jira ticket OC-260
• Administrative review completed
• Requirements to be discussed in OC meeting, 2022-08-16
• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solution announced to OCs on (TODO-date)
• Solutions Approval to be discussed in OC meeting, date TBD
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Implementation has not been merged into develop

• Milestone linked
• Documentation logged in pending release page

The "Email" in the README.md is not existent (any more).

Issue ported from old casework github repo (issue 22).
Original author: casework

How do we deal with artifacts that can determine that a particular account is the "owner"

• Do we have an "isOwner" property, or do something else?

There is some ambiguity and arguments about how to represent contact information.
Discuss below and a label will be added when the community is ready to vote.

This issue is related to issue #7.

Issue ported from old casework github repo (issue 14).
Original author: casework

Why is there only a sentTime timestamp in Message? I have other potential timestamps such as "created", "received", "uploaded", "downloaded", "deleted", etc. Having specific hardcoded timestamps in property bundles makes this very limiting.

This snippet failed to trigger a validation error:

{
    "@context": {
        "case-investigation": "https://ontology.caseontology.org/case/investigation/",
        "kb": "http://example.org/kb/",
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "uco-action": "https://ontology.unifiedcyberontology.org/uco/action/",
        "uco-core": "https://ontology.unifiedcyberontology.org/uco/core/",
        "uco-identity": "https://ontology.unifiedcyberontology.org/uco/identity/",
        "uco-location": "https://ontology.unifiedcyberontology.org/uco/location/",
        "uco-observable": "https://ontology.unifiedcyberontology.org/uco/observable/",
        "uco-tool": "https://ontology.unifiedcyberontology.org/uco/tool/",
        "uco-types": "https://ontology.unifiedcyberontology.org/uco/types/",
        "uco-vocabulary": "https://ontology.unifiedcyberontology.org/uco/vocabulary/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@graph": [
        {
            "@id": "kb:organization-2b3b98e2-aea2-4270-876a-7f9917623cb6",
            "@type": "uco-core:UcoObject",
            "uco-core:name": {"@id": "Cyber Domain Ontology"}
        }
    ]
}

Issue ported from old casework github repo (issue 17).
Original author: casework

Why is fileSystemType in both File and FileSystem property bundles?

Issue ported from old casework github repo (issue 37).
Original author: mike-parkhill

When importing a diverse set of trace objects you need to inspect the members of the PropertyBundle array to determine what the Trace relates to. This can be cumbersome since the logic on the ingesting side is going to be different based on the child types.

For example:

{
          "@type": "Trace",
          "@id": "https://www.netresec.com/20a91459-8fbb-4b90-a3fb-b4aa7f776a66",
          "createdBy": "https://www.netresec.com/1c7484fe-63f1-5af8-b4fb-e2386ab3c4b0",
          "createdTime": "2018-02-15T19:01:12.6271184Z",
          "propertyBundle": [
            {
              "@type": "File",
              "accessedTime": "2007-12-17T03:32:30.3990520Z",
              "extension": "html",
              "fileName": "index.html",
              "isDirectory": false,
              "sizeInBytes": 98500
            },
            {
              "@type": "ContentData",
              "dataPayloadReferenceURL": "D:\\NetworkMinerProfessional_2-2\\AssembledFiles\\151.193.224.81\\TCP-80\\index.html",
              "hash": [
                {
                  "@type": "Hash",
                  "hashMethod": "MD5",
                  "hashValue": "abdb151dfd5775c05b47c0f4ea1cd3d7"
                }
              ],
              "sizeInBytes": 98500
            }

The above JSON is obviously a File object with metadata and content data. It would be nice to know this without having to iterate the bundle looking to see if it contains a File child. The more types of Trace bundles we support the messier this is going to get. Adding a @bundletype attribute or something would simplify ingestion greatly.

Issue ported from old casework github repo (issue 32).
Original author: sbarnum

The source and target properties of "relationship3" and "relationship4" are reversed.

In v0.1.0 of the ontology there is a core "Identity" object and a propertybundle "Identity" object.
These should be renamed. The glossary terms of the ontology should be unique to make supporting tools work effectively and avoid confusion for mappers.

Issue ported from old casework github repo (issue 15).
Original author: casework

Why is there a separate isRead for SMSMessage? A regular message like "WhatsApp" could also have this field.

Response by sbarnum:

I don't know if there is any specific reason for it to be in SMSMessage specifically rather than in Message.

I believe it originally came from mapping the Hansken model in and Hansken has 'read' as a property of textMessage.

I would agree that it seems like it would be appropriate to move to Message.

If nobody disagrees we can add an issue to the UCO tracker proposing moving isRead from SMSMessage to Message property bundle and then deleting the SMSMessage property bundle since isRead is its only current property.

Response by casework:

Agreed.

Define 3 namespace types, where 1 & 2 are maintained by CASE dev team:

1. CASE (case.example.org) - CASE-approved property bundles, promoted from Community namespace by voting body (Official Namespace)
2. CASE Community (cc.example.org) - Property bundles promoted by individuals that would benefit the community
3. Individual (my company.com) - unique property bundles that would not necessarily benefit others outside your use cases

Background

A new issue needs to be worked through w.r.t. the proposed strategy of using the versionIRI as a concept prefix.

If a concept is defined with the versionIRI as part of its IRI, there is nothing in OWL that induces the existence of the unversioned IRI form. E.g. http://example.org/ontology/0.1.0/File does not imply the existence of http://example.org/ontology/File.

Ultimately, the effect of this is that if a knowledge base intends to pin a version of CASE to be used, this is not easily possible.

Requirements

Requirement 1

Allow to pin a particular version of CASE in a knowledge base by applying its versionIRI.

Requirement 2

Allow to pin the most recent version of CASE in a knowledge base by default

Risk / Benefit analysis

Benefits

CASE allows adopters of the standard to refer to either a particular version of CASE, or to apply the default most recent version of CASE.

Risks

The submitter is unaware of risks associated with this change

Competencies demonstrated

Competency 1

Competency Question 1.1

Result 1.1

Competency Question 1.2

Result 1.2

Solution suggestion

Define within the knowledge base an all-encompassing owl:Ontology, and have it import the versionIRI of CASE. Management issues around detection of multiple conflicting versionIRIs for a single ontology can then be handled with a SHACL rule within this proposal on Github:

UCO should perform OWL 2 DL review with SHACL-SPARQL (Change Proposal #406)

So, if our frequently-exercised knowledge base IRI for example individuals, http://example.org/kb/, were to involve pinning a used version of CASE, the correct answer would be to include this in the graph pertaining to that prefix:

<http://example.org/kb>
    a owl:Ontology ;
    owl:imports <https://ontology.caseontology.org/case/case/0.9.0> ;
    .

I ran verify.py against all the examples in this directory, and got verification issues (terms not in case.ttl) with these files:

• Oresteia.json
• accounts.json
• bulk_extractor_forensic_path.json
• file.json
• forensic_lifecycle.json
• message.json
• multipart_file.json
• raw_data.json

Background

Discussion on CASE Issue 136 suggests that an InvestigativeAction should always result in the creation of at least one ProvenanceRecord.

Requirements

Requirement 1

CASE should enforce that an InvestigativeAction results in at least one ProvenanceRecord.

As an implementation note, this would be done with a qualified SHACL constraint.

Edited 2024-02-15: "Must" relaxed to "should".

Requirement 2

CASE should describe in a mechanically discoverable way that an InvestigativeAction is expected to always result in at least one ProvenanceRecord.

As an implementation note, this would be done with a qualified minimum cardinality in an OWL Restriction.

Risk / Benefit analysis

Benefits

1. Requiring a ProvenanceRecord always be generated induces a chain of custody tie in forensic processing for resultant objects of InvestigativeActions.
2. Reintroduction of OWL constructs will assist with OWL-specific review mechanisms that do not appear to be possible in SHACL, such as set-satisfiability (e.g. determining through set-theoretic analysis whether a class or restriction has accidentally ended up equating to the empty set, rendering usage conformant with the specification impossible).
   1. This is acknowledged to be a broader issue than this one proposal. However, a minimum cardinality restriction appears to the submitter to be a "safe" reintroduction in terms of complexity.

Risks

1. Existing SHACL shapes require a ProvenanceRecord always have one member UcoObject. Thus, this proposal would induce a significant requirement on InvestigativeActions: They must always result in something aside from the ProvenanceRecord.
   1. Note that an object being a result of an action does not necessarily imply that the object was created by the action. This stemmed from discussion on UCO Issue 558.
   2. It is possible the definition of ProvenanceRecord is too stringent. It is somewhat a separate concern that there might exist a class of InvestigativeActions that truly have no results. Perhaps: "This action found all files within this directory. There were none."
   3. NOTE: Risk 1 mitigated with resolution of UCO Issue 599. ProvenanceRecords may now be empty.
2. Some Actions might be desired to be defined in a manner that attempt to restrict the results to a specific class, e.g., IP addresses. If such an action-class were introduced, it could never be an InvestigativeAction, because an InvestigativeAction would be required to include a ProvenanceRecord among its results. Hence, this proposal would end up inducing an upstream design constraint on UCO: action:result can never be constrained with owl:allValuesFrom, because UCO doesn't "know" about case-investigation:ProvenanceRecord.
3. This proposal does not specify whether there must only be one ProvenanceRecord among the results. This is an inconclusive point from the discussion on CASE Issue 136, and could be affected depending on whether the committee decides a subaction's ProvenanceRecord should also be recorded in the parent action's results.
4. This proposal suggests restoring OWL practices, starting with a description of at least one of the outputs for any InvestigativeAction. CASE and UCO previously abandoned OWL in UCO 0.7.0 / CASE 0.5.0. This proposal starts a disciplined reintroduction of OWL constructs, testing with the UCO-OWL syntax review mechanisms.
   1. UCO Change Proposal 23 housed discussion, though it appears that document was not exported from the access-controlled UCO Confluence space. (I don't think there is a reason it wasn't, aside from document exports only becoming a mandated part of the proposal process in later releases.)
   2. A test focused on the syntax used will be added in a separate proposal to UCO.
5. Due to needing SHACL qualified shapes, the CASE testing infrastructure also needs to require pySHACL >= 0.24.0, which incorporates a resolution to pySHACL Issue 213.
6. (Added 2024-02-15.) In information sharing situations, some data might be restricted from being shared or alluded to, e.g., from legally imposed redactions. If Org1 shares part of a graph with Org2, and includes some InvestigativeAction for, say, its timing and tool-use relevance, but doesn't share the identifier for the generated ProvenanceRecord, the shared data should by itself still be conformant to UCO, and should not impose UCO validation errors when folded into the receiving organization's knowledge base.

Competencies demonstrated

Competencies are omitted from this proposal, as the effects are new restrictions on data, and hence do not enable new expressive abilities.

Solution suggestion

For CASE 1.x.0, add the following to investigation.ttl:

investigation:InvestigativeAction
	rdfs:subClassOf [
		a owl:Restriction ;
		owl:onProperty uco-action:result ;
		owl:onClass investigation:ProvenanceRecord ;
		owl:minQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
	] ;
	sh:property [
		sh:message "An InvestigativeAction should have a ProvenanceRecord among its results.  This will be a requirement in CASE 2.0.0."@en ;
		sh:path uco-action:result ;
		sh:qualifiedMinCount "1"^^xsd:integer ;
		sh:qualifiedValueShape [
			a sh:NodeShape ;
			sh:class investigation:ProvenanceRecord ;
		] ;
		sh:severity sh:Warning ;
	] ;
	.

For CASE 2.0.0, remove the sh:message and sh:severity triples from the added sh:PropertyShape.

Coordination

• Tracking in Jira ticket ONT-493

• Administrative review completed, proposal announced to Ontology Committees (OCs) on Jan. 26, 2024
• Requirements to be discussed in OC meeting, date Feb.15, 2024
• Risk 1 addressed - InvestigativeActions that have no non-ProvenanceRecord results confirmed supportable.
• Requirements to be discussed in OC meeting, date TBD.

• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solution announced to OCs on TODO-date
• Solutions Approval to be discussed in OC meeting, date TBD
• 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 (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

The CASE Ontology Committee had discussed in the past whether InvestigativeActions would always have a ProvenanceRecord among their outputs. I recall, informally, we had said yes, this is a requirement. However, we had not encoded this in SHACL or OWL.

I have found a few logistical issues with requiring a ProvenanceRecord as output. While I don't think these are necessarily counter-arguments, they seem to need clarification if we move towards encoding the generated-ProvenanceRecord expectation.

1. A ProvenanceRecord must have at least one member. This is a requirement inherited from uco-core:ContextualCompilation, ProvenanceRecord's superclass. By my understanding of what CASE had not formally encoded, that ProvenanceRecord should have members that are either (1) inputs to the InvestigativeAction, or (2) other results of the InvestigativeAction.
2. I do not think uco-action:subaction was considered as part of the discussion, because it had not been exercised in CASE-Examples or the CASE website.¹ It is not quite clear how that property is supposed to be used with InvestigativeAction, namely whether any sub-action of an InvestigativeAction is also an InvestigativeAction. The answer to that question might complicate requiring a ProvenanceRecord as output.

Let's take this example graph, which renders an action that takes a JPEG file as input and uses a (made-up) tool, "ExampleJpegAnalyzer," to analyze the JPEG's contents in a couple ways. The tool unconditionally calls multiple independent, tool-internal functions as part of its execution, look_up_location, ocr and others. The ocr function yields a file. This graph omits some triples for the sake of discussion.

kb:tool-1
	a uco-tool:AnalyticTool ;
	uco-core:name "ExampleJpegAnalyzer" ;
	.

kb:jpeg-i1
	a uco-observable:RasterPicture ;
	.
kb:provenance-record-i1
	a case-investigation:ProvenanceRecord ;
	uco-core:object kb:jpeg-i1 ;
	.

kb:action-1
	a case-investigation:InvestigativeAction ;
	uco-action:instrument kb:tool-1 ;
	uco-action:object
		kb:jpeg-i1 ,
		kb:provenance-record-i1
		;
	uco-action:subaction kb:action-2 ;
	uco-action:result kb:provenance-record-o1 ;
	.

kb:action-2
	a uco-action:Action ;
	uco-core:description "Store any OCR-recognized text in a file." ;
	uco-action:object kb:jpeg-i1 ;
	uco-action:result kb:ocr-text-results-file-1 ;
	.
kb:ocr-text-results-file-1
	a uco-observable:File ;
	.

Question 1: Is kb:action-2 a InvestigativeAction? If so, and if all InvestigativeActions need to generate a ProvenanceRecord, how do the members of its ProvenanceRecord relate to the parent action's ProvenanceRecord?

Question 2: What are the members of the output ProvenanceRecord, kb:provenance-record-o1?

Question 2.1: Is kb:jpeg-i1 a member, recording that it was seen and/or handled?

Question 2.2: Is kb:ocr-text-results-file-1 in kb:provenance-record-o1? Is the answer to this influenced by whether kb:action-2 is or is not a InvestigativeAction?

I intend to take responses to these questions and propose OWL and SHACL encodings to capture the consensus.

Issue ported from old casework github repo (issue 29).
Original author: sbarnum

The example uses a "partIndex" property on the DiskPartition property bundle (e.g. relationship6).
This is not a valid property for v0.1.0.
The valid properties of DiskPartition for v0.1.0 are:

• mountPoint
• partitionID
• partitionLength
• partitionOffset
• spaceLeft
• spaceUsed
• totalSpace
• diskPartitionType
• createdTime

When generating data classes from development branch, we noticed a few missing fields

Here is the list of observable

• URLVisitFacet has urlTransitionType field which is missing sh:datatype vocabulary:URLTransitionTypeVocab ;
• byteStringValue missing rdfs:range xsd:string ;
• destinationFlags missing rdfs:range xsd:string ;
• lastTimeContacted missing rdfs:range xsd:dateTime ;

This is proposed as a FastTrack change

Background

Most properties in CASE are optional. Setting minCount = 1 is enforced by SHACL makes a property required. This constraint will create problems in use cases in which a property is known to have existed but the value is not available.

Requirements

Requirement 1

Allow adopters to create an object when the existence of an object is known but an associated property is not known.

Risk / Benefit analysis

The proposed change allows adopters to decide which property is needed, except when it is ontologically necessary.

Benefits

Allow adopters to decide which property is needed.

Risks

The submitter is unaware of risks associated with this change.

Competencies demonstrated

Adopter creates an object when the existence of an object is known but an associated property is not known.

Solution suggestion

Change minCount to 0 from 1 on the following Investigation properties:

• authorizationType
• authorizationIdentifier
• authorizationForm

Coordination

• Tracking in Jira ticket ONT-482
• Administrative review completed
• Solutions Approval to be discussed in OC meeting, date 2022-08-16
• Solutions Approval vote occurred, not passing, on 2022-08-16
• Solutions development phase completed.
• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page

Issue ported from old casework github repo (issue 28).
Original author: mike-parkhill

We often have workflows that involve exporting out data to a third-party tool and then after the user has done what they need to in the third-party tool (e.g. picture categorization, annotations, etc.) they want to bring the data back into our system. In order to aid merging back data it would be nice to have a way of including our own unique ids on the objects. Presumably other tools in the chain could want the same, so a collection of "system ids" is probably required.

Issue ported from old casework github repo (issue 19).
Original author: casework

For the "File" property bundle, what are considered to have a file system type?
Besides the obvious ones like NTFS and EXT4 there are also things like TAR and 7z that are included because they have file-like properties (filepath, MAC times, etc)
Do we consider other file systems that don't have the traditional file-like properties but have other properties to extract a file? (eg. SQLiteBlob, Encryption, Compression, etc.)
These file types obviously don't have MAC times and filePath, but they have other properties used to grab files.
SQLiteBlob uses the parameters: tableName, columnName, and rowCondition or rowIndex
Encryption uses the parameters: key, IV, method, and cipher mode
Encoding uses the parameters: method

Issue ported from old casework github repo (issue 36).
Original author: mike-parkhill

Just looking at some sample output from Network Miner and see that they're outputting "TCP, HTTP" for the Protocols field of the NetworkConnection object. Just wondering if it would make sense to make this field an array so it's clear that multiple protocols might apply? Or, do we want to agree on a way of describing that HTTP over TCP was being used?

This is required for the Python API Autogeneration feature to work and should occur for the first stable release of the ontology (before v1.0.0).

Background

For a growing number of investigations, there is a need to represent cryptowallets and the account(s) they contain.

Crypto wallets can be hosted by an online service, or stored in a software wallet application, or secured using a hardware wallet.

Requirements

Requirement 1: CASE must be able to represent what cryptoaddress(es) were stored in a given cryptowallet.

Requirement 2: CASE must be able to represent how much cryptocurrency was stored in a given cryptoaddress at a point in time.

Requirement 3: CASE must be able to represent multiple measurements of the balance of a crypto wallet.

Benefits

• Representing cryptowallets and cryptoaddresses is necessary for various cyber-investigations, including Dark Web activities and cryptocurrency transactions.
• (Noted during administrative review) QUDT employs owl:versionIRI, giving CDO a chance to try versionIRI practices under consideration for CASE's and UCO's versioning.

Risks

• (Noted during administrative review) Some proposals under draft are considering importing ontologies outside of the UCO/CASE ontologies. None have been accepted yet. This proposals includes incorporating QUDT. (It remains to be reviewed whether this would be adoption of certain provided classes, or importing QUDT.)
• (Noted during administrative review) One logistical risk pertaining to usage of QUDT is that its ontology resources only transmit from their namespace IRIs via plaintext HTTP. TLS fails with a 404 message. Transmission risks can be mitigated by CASE tracking the QUDT public Github repository as a Git submodule.
• (Noted during administrative review) Usage of QUDT for unitary measurements introduces a design a pattern to CASE that is not used elsewhere in UCO-housed concepts. One concept where unitary measurement could be applied is the UCO property observable:storageCapacityInBytes - that property could reduce its name to storageCapacity and use the unit:BYTE unit of measure. In short, adoption of this proposal induces a need in CASE to explain why some numeric properties are represented with qudt:unit and others aren't.

Competencies demonstrated

Competency 1

The cryptoaddress(es) that were stored in a given cryptowallet, and how much cryptocurrency they had.

Admin. note - For this proposal, the competencies should include a sample JSON-LD snippet and two SPARQL queries demonstrating satisfaction of the above competency statement, i.e. SELECT ?nCryptoWallet ?xCryptoAddress and SELECT ?nCryptoWallet ?xQuantity, with the latter demonstrating something similar to usage of http://qudt.org/vocab/unit/AUD. (?x prefix is where the admin. review was unclear on what value(s) or value form(s), node or literal, should be returned.)

Solution summary

1. Add CryptoWalletFacet with the following properties:

cryptoWalletIdentifier (string): the identifier of a wallet
cryptoWalletName (string): the name assigned to a wallet
cryptoWalletCreatedTime (date): when the wallet was created
cryptoWalletSeed (string): a series of words for accessing crypto associated with the wallet.

2. Add CryptoAddressFacet with the following properties, using qudt.org ontology to represent currency:

cryptoAddress (string): reference to CryptocurrencyAddress containing the value of the cryptocurrency address
cryptoCurrencyType (string): the type of cryptocurrency in the wallet
cryptoAddressFormat (string): P2SH (BASE58)
cryptoAddressName (string): the name assigned to the cryptocurrency address
cryptoAddressCreatedTime (date): when the cryptocurrency address was created
cryptoAddressBalance (currency - qudt): the total amount of cryptocurrency in the cryptocurrency address
cryptoAddressCompletedTransactionCount (integer): how many transactions have been completed using the cryptocurrency address
cryptoAddressTotalSent (currency - qudt): the total amount of cryptocurrency sent by the cryptocurrency address
cryptoAddressTotalReceived (currency - qudt): the total amount of cryptocurrency received by the cryptocurrency address
cryptoAddressPendingTransactionCount (integer: how many transactions are pending for the cryptocurrency address

3. Add CryptocurrencyAddress observableObject (subClassOf observable:DigitalAddress)

4. Create example using public data: Wallet Explorer (https://www.walletexplorer.com/wallet/335f3892f622984f

5. Add unit test showing potential errors in property usage and how to avoid them

Coordination

• Tracking in Jira ticket ONT-478
• Administrative review to be completed
  • Development of competency queries is in progress here.
• Requirements to be discussed in Ontology Committee (OC) meeting, date TBD

• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solutions Approval to be discussed in OC meeting, date TBD
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Implementation has not been merged into develop

• Milestone linked
• Documentation logged in pending release page

Background

The Hanksen trace export meta-model has a property pathItems, which is a string value-list of "The individual items that make up the path property.". There is seemingly no coresponding CASE property. It is related to Hansken Property path with description "The logical path where the trace is located on the image, including the name of the trace itself.", which is mappable to observable:path in observable:PathRelationFacet.

Requirements

Requirement 1: add dataproperty observable:pathItems with rdfs:label "The individual items that make up the path property." with rdfs:range xsd:string and minvalue 0, maxvalue * in the SHACL shapes defined with observable:PathRelationFacet.

Benefits

Extend the PathRelationFacet and CASE in general to support the conversion of Hansken trace export data to JSON-LD with CASE ontology constructions.

Risks

The submitter is unaware of risks associated with this change

Competencies demonstrated

Competency 1

Solution summary

Issue ported from old casework github repo (issue 26).
Original author: sbarnum

In the example, two of the Relationship objects near the end have Attachment property bundles specifying mimeType and sizeInBytes properties.
These properties are not valid on the Attachment property bundle.
The Attachment property bundle only has a single valid property, 'url'.

The mimeType and sizeInBytes properties should be expressed using a ContentData property bundle on the attachment_file1 and attachment_file2 objects.

Source of Issue:

• https://caseontology.org/examples/asgard/ (Step-1): Line# 70 ~ 72
  • These three lines are not 'legal' UCO/CASE properties.

The following three lines are not 'legal' UCO/CASE properties:
--- Current (Incorrect) Lines ---
{
"@type": "iPhoneDevice",
"uniqueID": "B3858A69A29375E6C706226B3633A3A11EB2A774",
"ownerName": "Loki iPhone"
},
--- Corrected (maybe) Lines should be like below: ---
{
"@type": "uco-observable:MobileDeviceFacet",
"uco-core:name": "iPhoneDevice",
"uco-observable:objectGUID": "B3858A69A29375E6C706226B3633A3A11EB2A774",
"uco-observable:owner": "Loki iPhone"
},

Issue ported from old casework github repo (issue 31).
Original author: sbarnum

Examples within the case repo show the emailAddress property of the EmailAccount property bundle as a string.

The EmailAccount property bundle class in UCO (leveraged by CASE) specifies the emailAddress property as a reference to a CyberItem (Trace) object. This follows a pattern where properties representing information that have their own property bundles are captured as references to instances of objects capturing that information rather than embedding it natively. This avoids confusion among producers on where to capture the info and yields greater consistency (one way to do things) and better analytic pivotability.

The examples should be updated appropriately.

Trace origin is not addressed yet within the CASE/UCO ontology.

Ex: I have a property bundle with a MD5sum and a SHA1sum, both are created from different tools. How do I specify the different parents?

Background

UCO Issue 541 introduced general uco-core:Events.

CASE's Investigation class has, to date, been encoded as a uco-core:ContextualCompilation. (This class design predates my own involvement in CASE, so I can only guess to motives for this.)

ContextualCompilation provides a "Set" construct that lets arbitrary items be grouped together, using uco-core:object.

Requirements

Requirement 1

Investigation should exercise Event.

Requirement 2

Investigations must maintain the ability to link InvestigativeActions, ProvenanceRecords, and other CASE classes that tie to investigative contexts.

This proposal does not impose a requirement they need to be linked with the same predicate as today, but other developments in UCO might mean they would no longer be linked the same way.

Risk / Benefit analysis

Benefits

• This appears, to the proposer, to align investigations with a more concrete experience than an abstract "Compilation of objections that share a context." As currently modeled, Investigation is more a representation of the set of things pertaining to an investigation, rather than the investigation itself.

Risks

• An in-flight proposal on the UCO tracker affects how Events could be required to behave differently from ContextualCompilations, so this might not be a backwards-compatible proposal. UCO Issue 544 introduces a disjoint pair of classes, endurants and perdurants. Under that proposal, Event would fall under Perdurant. While not written in the current proposal's state, it is likely that Compilation would be interpreted as an Endurant. If all that is accepted, an Investigation would not be able to be a ContextualCompilation and Event, as the classes would be disjoint.
• The endurant/perdurant proposal also introduces a relating predicate, participatesIn, domain endurant, range perdurant; and perdurantProperPartOf, domain perdurant, range perdurant. This would possibly change how InvestigativeActions relate to Investigations, as they may need to use perdurantProperPartOf (or some subproperty), while anything else (e.g. ProvenanceRecords) would need to use participatesIn.
• uco-core:object is a vaguely-described linking predicate with no RDFS domain specified and a nearly-maximally general UcoObject range, so it is not clear if existing data would need to be changed.

Competencies demonstrated

(Competencies deferred for discussion.)

Competency 1

Competency Question 1.1

Result 1.1

Competency Question 1.2

Result 1.2

Solution suggestion

For CASE 1.x.0, BEFORE merging of UCO Issue 544, add to Investigation's definition:

investigation:Investigation
    rdfs:subClassOf uco-core:Event ;
    .

AFTER merging of Issue 544 (assuming UCO Ontology Committee votes so), subtract this subclassing:

investigation:Investigation
    rdfs:subClassOf uco-core:ContextualCompilation ;
    .

uco-core:object can retain its usage on Investigation, but I suggest this is thanks to a lack of specification, which does not feel future-proofed. This SHACL shape can be added to maintain current data behavior, but Issue 544 could also obviate the property:

investigation:Investigation
    sh:property [
        a sh:PropertyShape ;
        sh:class uco-core:UcoObject ;
        sh:nodeKind sh:IRI ;
        sh:path uco-core:object ;
    ] ;
    .

Note: That shape also omits the minimum-1 constraint on uco-core:object. I am not sure if that constraint was purposefully intended to fail SHACL validation on an investigation containing no objects, or if it was an overzealous translation of an owl:someValuesFrom restriction.

By the time of UCO 2.0.0's release and CASE 2.0.0's release, I think Investigation should no longer be a ContextualCompilation.

Coordination

• Tracking in Jira ticket ONT-492

• Administrative review completed, proposal announced to Ontology Committees (OCs) on Nov.17, 2023
• Requirements to be discussed in OC meeting, date Nov.28, 2023

• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solution announced to OCs on TODO-date
• Solutions Approval to be discussed in OC meeting, date TBD
• 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 (or N/A)
• Milestone linked
• Documentation logged in pending release page

"..., that's the question."
(attributed to: W.Shakespeare)

Issue ported from old casework github repo (issue 23).
Original author: casework

What is the "callType" property in PhoneCall pb used for? INCOMING/OUTGOING? VIDEO/AUDIO? something else?

Moving forward, once CASE is exposed as an RDF endpoint I believe following OWL's recommendation for ontology versioning makes sense.

Thoughts?

Issue ported from old casework github repo (issue 20).
Original author: casework

• I have run into issues dealing with Volumes:
  • How would I convert a DFVFS path spec like the following?:

    OS: location=C:\image.qcow2
    QCOW: -
    LVM: location=/lvm2, volume_index=1
    TSK: location=/a_dir/a_file.txt

• How do I deal with the LVM level? Do I put that in the Relationship object or Trace? or both?

Issue ported from old casework github repo (issue 16).
Original author: casework

Clarifications on when to use "PhoneAccount" or "EmailAccount" vs "Contact" is needed.

Bug description

requirements.txt identifies a requirement for isodate==0.5.4 which utilizes calls use_2to3 which is incompatible with setuptools > v58.
https://stackoverflow.com/questions/69100275/error-while-downloading-the-requirements-using-pip-install-setup-command-use-2

This causes the installation pip install -r requirements.txt to fail as isodate cannot be installed.

Steps to reproduce

• Install setuptools > v58 (pip install setuptools=59.0.0)
• pip install -r requirements.txt

Coordination

• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page