search

casework / CASE

Cyber-investigation Analysis Standard Expression (CASE) Ontology
https://caseontology.org
Apache License 2.0
65 stars 22 forks source link

Add dataproperty observable:pathItems to observable:PathRelationFacet #84

Closed kadevgraaf-tno closed 2 years ago

kadevgraaf-tno commented 2 years ago

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

ajnelson-nist commented 2 years ago

Hi @kadevgraaf-tno ,

I'm not quite sure I understand what the representation need is, independent of Hansken. We should develop the competency for working this through the UCO proposal process; may we use an example from the Crossover Scenario?

Crossover has a disk image, identified in the graph as kb:F3FD304E-EF6C-4CBD-94CB-425880F82748, stored as a file with basename LGE Nexus 5 Full Image.raw.

Are you able to explain your desired property implementation using that node?

(I realize there may be a copy-paste error with that data from another scenario, as the filePath base name doesn't line up with the fileName. Assume filePath has the correct full path for the purposes of your illustration. @cyberinvestigationexpress , any thoughts what happened there?)

kadevgraaf-tno commented 2 years ago

Hi @ajnelson-nist ,

Thanks for your feedback!

Now that I think about it, I am not sure what the representation need is independent of Hansken, or even if there is a need to include it to support Hansken :)

In the crossover example I read: "uco-observable:filePath": "E:\\Evidence\\UFED Samsung GSM SM-G925F Galaxy S6 Edge 2018_12_11 (002)\\Physical Boot Loader (Recommended) 01\\blk0_sda.bin",

The application reading a Hansken Export file/API can easily reconstruct the observable:pathItems from uco-observable:filePath, using // as a separator / string explode param. Hence there is not really a need to export this, other than for convenience.

Do you think this is sound reasoning? I am okay with closing this issue/request. I will try to make another issue/addition request that we can discuss next Friday.

Kind regards, Klaas

ajnelson-nist commented 2 years ago

@kadevgraaf-tno , thank you for helping me understand the request.

This information can be available if the CASE export instantiates each file and directory as a graph object, and relates every file or directory to its parent object. In that Crossover example path, we could get this table of results ...

ID OWL Class fileName filePath
kb:file-system-0a48cb49-7616-4c88-b0a3-ba2e4f38e85f uco-observable:FileSystem
kb:directory-12000ec0-9517-47a0-983e-b163e0d24c71 uco-observable:Directory E:
kb:directory-2316292f-deb3-499d-af89-816dd9fe0bfa uco-observable:Directory Evidence E:\\Evidence
kb:directory-33143216-418f-4ab8-8560-d308736be685 uco-observable:Directory UFED Samsung GSM SM-G925F Galaxy S6 Edge 2018_12_11 (002) E:\\Evidence\\UFED Samsung GSM SM-G925F Galaxy S6 Edge 2018_12_11 (002)
kb:directory-4217f57d-1a72-4808-86ed-285ab144b026 uco-observable:Directory Physical Boot Loader (Recommended) 01 E:\\Evidence\\UFED Samsung GSM SM-G925F Galaxy S6 Edge 2018_12_11 (002)\\Physical Boot Loader (Recommended) 01
kb:file-540fc6e8-f5c6-4f64-bd06-bd7f9301db7f uco-observable:File blk0_sda.bin E:\\Evidence\\UFED Samsung GSM SM-G925F Galaxy S6 Edge 2018_12_11 (002)\\Physical Boot Loader (Recommended) 01\\blk0_sda.bin

... from this SPARQL query:

SELECT DISTINCT ?nObject ?nType ?lFileName ?lFilePath
WHERE {
  ?nObject a ?nType .
  OPTIONAL {
    ?nObject uco-core:hasFacet ?nFileFacet .
    ?nFileFacet uco-observable:filePath ?lFilePath .
    OPTIONAL {
      ?nFileFacet uco-observable:fileName ?lFileName .
    }
  }

  # Limit objects to those in the "Child Of" chain between the file system and the image file.
  kb:file-540fc6e8-f5c6-4f64-bd06-bd7f9301db7f tmp:childOf* ?nObject .
  ?nObject tmp:childOf* kb:file-system-0a48cb49-7616-4c88-b0a3-ba2e4f38e85f .
}
ORDER BY ?lFilePath

A few implementation asides:

CONSTRUCT {
  ?nChild tmp:childOf ?nParent .
}
WHERE {
  ?nRelationship
    a uco-observable:ObservableRelationship ;
    uco-core:kindOfRelationship "Child_Of" ;
    uco-core:source ?nChild ;
    uco-core:target ?nParent ;
    .
}

As for reasons why one would want to instantiate every directory - it's useful for someone who wants to keep records of every file system object. It is a considerable amount of "Graph weight" to do so. However, there are some situations tracking every Directory can be more helpful than relying on just a full file path as a string to store all of the lineage information. One reason is: Say one of the directories in the middle of the path gets its name corrupted. (This is a decently frequent problem working with character encodings, where a string may have been incorrectly transcoded as files migrated between operating system environments.) If the corruption is sufficiently problematic, all paths at and below that directory may not be readable.

ajnelson-nist commented 2 years ago

I missed @kadevgraaf-tno 's remark above that this issue is OK to close, and I also have talked with him about my last response. I'll close the issue out now.