ucoProject / UCO

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

Unrestrict Cardinality of `observable:IMEI` in `observable:MobileDeviceFacet` #521

Closed kchason closed 1 year ago

kchason commented 1 year ago

Background

Currently, the property observable:IMEI in the observable:MobileDeviceFacet has a max cardinality of 1. This causes issues with devices that contain multiple SIM ports, as each SIM port has its own IMEI.

In a direct and practical example, a commercial forensics tool (appropriately) identified two IMEIs off the sample mobile device and there's not currently a way to represent this without duplicating a observable:MobileDeviceFacet and associating it with the same observable:Device.

Requirements

Requirement 1

Remove the sh:maxCount from the observable:IMEI property of the observable:MobileDeviceFacet.

Risk / Benefit analysis

Benefits

It allows devices that contain multiple SIM cards to be properly represented.

Risks

There are no known risks to existing adopters since it's loosening restrictions.

Competencies demonstrated

Competency 1

Competency Question 1.1

Allow representation of a device with multiple IMEIs.

Result 1.1

{
    "@id": "xxxxxx",
    "@type": "observable:MobileDevice",
    "core:hasFacet" {
        "@id": "xxxxx",
        "@type": "observable:MobileDeviceFacet",
        "observable:storageCapacityInBytes": 12345,
        "observable:IMEI": [
            "12:ab:34:cd:56:ef:78",
            "12:ab:34:cd:56:ef:79"
        ]
    }
}

Solution suggestion

[
    sh:datatype xsd:string ;
    # sh:maxCount "1"^^xsd:integer ; Remove this property
    sh:nodeKind sh:Literal ;
    sh:path observable:IMEI ;
]

Coordination

ajnelson-nist commented 1 year ago

Thank you, @kchason !

I looked at how we handled the vote scheduling for MIME type expansion (Change Proposal 104, linked off of the UCO 0.9.0 release notes). We did not fast-track that vote.

This hits some of the same potential complexities for interpretation, so we will hold a Requirements Review vote on this one.