Automate mappings to data sources in attack_update script

[netfl0]

No description provided.

[netfl0]

feature/238-automate-mappings-to-data-sources-in-attack_update-script @ikiril01

[netfl0]

9c67018

not sure what why commit didn't show up from the linked branch...

[aamedina]

How can I help on this?

[netfl0]

@ikiril01 is going to have something here shortly, I stubbed out the onto design pattern.

[ikiril01]

I added the remaining ATT&CK data source mappings here: feature/238-automate-mappings-to-data-sources-in-attack_update-script...ikiril01:d3fend-ontology:feature/238-automate-mappings-to-data-sources-in-attack_update-script

Here are some comments on the data sources that didn't have exact mappings. EDIT - strikethrough for those that have been added as new digital artifacts or are deemed no longer necessary:

• Malware Repository: D3FEND doesn't have a concept of a repository (which would be something like a Database + File Storage) so it's mapped broadly to Database.
• WMI: Windows Management Instrumentation provides a standard set of interfaces for obtaining management data from remote machines, so its more akin to an API. There's no API entity currently in D3FEND so it's mapped broadly to System Service Software, since it does run as a service.
• Image: this refers to a VM image in ATT&CK, so the closest reasonable mapping (broadly) was to a D3FEND Software Package.
• Sensor Health: in ATT&CK this refers to system telemetry around status, etc. Since this is typically captured as a log file, the closest (broadly) mapping was to a D3FEND log.
• Pod: in ATT&CK this refers to a Kubernetes Pod, which is a grouping of containers that share namespaces and volumes and are typically designed for a single use-case. There's no Pod in D3FEND, so the narrower mapping to a Container Image seemed like the best fit.
• Drive: ATT&CK describes this as a non-volatile formatted drive with at least one partition that has a mount point, so the closest broader mapping was to Secondary Storage.
• Snapshot: ATT&CK describes this as a snapshot (point-in-time copy) of a Cloud volume, so the closest broader mapping was to a File (since snapshots are stored as files).
• Persona: There's no concept of a persona/user profile (different from user account) in D3FEND, so this was broadly mapped to a Digital Information Bearer.
• Named Pipe: D3FEND does have a Pipe digital artifact, which would be the superclass of a Named Pipe, so this was a slightly broader mapping.
• Cloud Service: ATT&CK defines this as "Infrastructure, platforms, or software that are hosted on-premise or by third-party providers, made available to users through network connections and/or APIs", so a narrower mapping to Software was used, since this doesn't account for the platform/infrastructure components.
• Instance: ATT&CK defines this as "A virtual server environment which runs workloads, hosted on-premise or by third-party cloud providers" so the closest mapping (broadly) in D3FEND was to Server, which may be slightly inaccurate since Instances can abstractions of multiple servers.
• Internet Scan: D3FEND has no concept of scans as digital artifacts, so the closest reasonable mapping (broadly) was to Internet Network Traffic.
• Asset: in ATT&CK this encompasses asset inventories and software inventories, so the closest mapping (broadly) was to Database.
• Operational Database: in ATT&CK this refers to operational technology (OT) databases used for storing events/alarms/measurements/etc. so the closest mapping (broadly) was to Database.

[ikiril01]

Added Malware/Malware Repository and related classes for having a more accurate mapping to DS0004:

Added Malware/MalwareRepository classes
Updated seeAlso to isDefinedBy for MaliciousSoftware
Updated DS0004 mapping to MalwareRepository

[ikiril01]

Added Disk Image for having a more accurate mapping to DS0007

Added DiskImage for use with VM images etc.; update DS0007 mapping ac…

[ikiril01]

In the DBPedia entry for Event Logging (https://dbpedia.org/page/Logging_(software)) they mention as errors etc. being events, so this actually lines up with the ATT&CK data source description for Sensor Health. Accordingly, I updated DS0013 as being an exact mapping to Event Log.

ikiril01@680e991

[ikiril01]

Struggling a bit on how to accurately model Kubernetes Pods (based on https://attack.mitre.org/datasources/DS0014/) in D3FEND. The problem is that pods are an abstraction (i.e., grouping containers that share namespaces and volumes and are typically designed for a single use-case) on Containers, and therefore they don't inherently encapsulate Container Images or Container Runtimes. Kubernetes has their definition here: https://kubernetes.io/docs/concepts/workloads/pods/

[aamedina]

Struggling a bit on how to accurately model Kubernetes Pods (based on https://attack.mitre.org/datasources/DS0014/) in D3FEND. The problem is that pods are an abstraction (i.e., grouping containers that share namespaces and volumes and are typically designed for a single use-case) on Containers, and therefore they don't inherently encapsulate Container Images or Container Runtimes. Kubernetes has their definition here: https://kubernetes.io/docs/concepts/workloads/pods/

Can you share a draft class for the Pod? My initial impression are its basic semantics are d3f:Pod d3f:contains d3f:ContainerImage and d3f:Pod d3f:runs d3f:ContainerProcess. I use d3f:contains for its transitivity during inference across artifacts in a knowledge graph, so if container images "contain" other artifacts of interest connected by the ontology, I could find them in a SPARQL query starting with the d3f:Pod individual transitively.

[ikiril01]

Struggling a bit on how to accurately model Kubernetes Pods (based on https://attack.mitre.org/datasources/DS0014/) in D3FEND. The problem is that pods are an abstraction (i.e., grouping containers that share namespaces and volumes and are typically designed for a single use-case) on Containers, and therefore they don't inherently encapsulate Container Images or Container Runtimes. Kubernetes has their definition here: https://kubernetes.io/docs/concepts/workloads/pods/

Can you share a draft class for the Pod? My initial impression are its basic semantics are d3f:Pod d3f:contains d3f:ContainerImage and d3f:Pod d3f:runs d3f:ContainerProcess. I use d3f:contains for its transitivity during inference across artifacts in a knowledge graph, so if container images "contain" other artifacts of interest connected by the ontology, I could find them in a SPARQL query starting with the d3f:Pod individual transitively.

What you suggested is along the lines of what was I thinking of: d3f:Pod contains multiple d3f:ContainerImage and d3f:Pod runs multiple d3f:ContainerProcess. However - this describes a running Pod, but Pods can also be deployed and not running. This is my struggle, as I feel like even Pods that are not running can be considered as Digital Artifacts since they provide information on their respective Containers etc. Maybe I'm just being overly pedantic here.

[aamedina]

Struggling a bit on how to accurately model Kubernetes Pods (based on https://attack.mitre.org/datasources/DS0014/) in D3FEND. The problem is that pods are an abstraction (i.e., grouping containers that share namespaces and volumes and are typically designed for a single use-case) on Containers, and therefore they don't inherently encapsulate Container Images or Container Runtimes. Kubernetes has their definition here: https://kubernetes.io/docs/concepts/workloads/pods/

Can you share a draft class for the Pod? My initial impression are its basic semantics are d3f:Pod d3f:contains d3f:ContainerImage and d3f:Pod d3f:runs d3f:ContainerProcess. I use d3f:contains for its transitivity during inference across artifacts in a knowledge graph, so if container images "contain" other artifacts of interest connected by the ontology, I could find them in a SPARQL query starting with the d3f:Pod individual transitively.

What you suggested is along the lines of what was I thinking of: d3f:Pod contains multiple d3f:ContainerImage and d3f:Pod runs multiple d3f:ContainerProcess. However - this describes a running Pod, but Pods can also be deployed and not running. This is my struggle, as I feel like even Pods that are not running can be considered as Digital Artifacts since they provide information on their respective Containers etc. Maybe I'm just being overly pedantic here.

The way I interpret this is not that every individual pod is necessarily "running", but that semantically Pods "run" ContainerProcesses. Also I think this is where the some/all logical distinction comes into play w/OWL but I am not 100% on that...

[ikiril01]

Struggling a bit on how to accurately model Kubernetes Pods (based on https://attack.mitre.org/datasources/DS0014/) in D3FEND. The problem is that pods are an abstraction (i.e., grouping containers that share namespaces and volumes and are typically designed for a single use-case) on Containers, and therefore they don't inherently encapsulate Container Images or Container Runtimes. Kubernetes has their definition here: https://kubernetes.io/docs/concepts/workloads/pods/

Can you share a draft class for the Pod? My initial impression are its basic semantics are d3f:Pod d3f:contains d3f:ContainerImage and d3f:Pod d3f:runs d3f:ContainerProcess. I use d3f:contains for its transitivity during inference across artifacts in a knowledge graph, so if container images "contain" other artifacts of interest connected by the ontology, I could find them in a SPARQL query starting with the d3f:Pod individual transitively.

What you suggested is along the lines of what was I thinking of: d3f:Pod contains multiple d3f:ContainerImage and d3f:Pod runs multiple d3f:ContainerProcess. However - this describes a running Pod, but Pods can also be deployed and not running. This is my struggle, as I feel like even Pods that are not running can be considered as Digital Artifacts since they provide information on their respective Containers etc. Maybe I'm just being overly pedantic here.

The way I interpret this is not that every individual pod is necessarily "running", but that semantically Pods "run" ContainerProcesses. Also I think this is where the some/all logical distinction comes into play w/OWL but I am not 100% on that...

Thanks - that is helpful. I agree, if we say may-run and may-contain, that should cover both running and not running cases. I'll go in that direction.

[ikiril01]

Added Pod and subsequently updated DS0014 mappings to "exactly".

https://github.com/ikiril01/d3fend-ontology/blob/feature/238-automate-mappings-to-data-sources-in-attack_update-script/src/ontology/d3fend-protege.ttl#L3800-L3810

[ikiril01]

Added NamePipe and subsequently updated DS0023 mapping to "exactly".

ikiril01@a20ef49

[ikiril01]

After reading the Wikipedia page on Secondary Storage more closely, I think it maps nearly exactly to ATT&CK's definition of "Drive", so I updated the mapping accordingly.

[ikiril01]

Added SoftwareTelemetryLog/EndpointSensorTelemetryLog for mapping to DS0013: Sensory Health.

ikiril01@f39ee11

[ikiril01]

Added Snapshot/VM Snapshot/Volume Snapshot.

ikiril01@1f0edb2

[ikiril01]

Added User Profile for mapping to DS0021 (Persona).

ikiril01@7daef98