d3fend-ontology
d3fend-ontology copied to clipboard
d3fend
Automate mappings to data sources in attack_update script
9c67018c3b941bf685c49f1ea3f97053a3233be2
not sure what why commit didn't show up from the linked branch...
@ikiril01 is going to have something here shortly, I stubbed out the onto design pattern.
I added the remaining ATT&CK data source mappings here: https://github.com/d3fend/d3fend-ontology/compare/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.
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
Added Disk Image for having a more accurate mapping to DS0007
Added DiskImage for use with VM images etc.; update DS0007 mapping ac…
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.
https://github.com/ikiril01/d3fend-ontology/commit/680e991d97b9508273ad98f225a80372d052f1b2
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/
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.
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:ContainerImageandd3f: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.
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:ContainerImageandd3f: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:Podcontains multipled3f:ContainerImageandd3f:Podruns multipled3f: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...
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:ContainerImageandd3f: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:Podcontains multipled3f:ContainerImageandd3f:Podruns multipled3f: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.
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
Added NamePipe and subsequently updated DS0023 mapping to "exactly".
https://github.com/ikiril01/d3fend-ontology/commit/a20ef4967b4041768ef49a83f2763b13b292adfe
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.
Added SoftwareTelemetryLog/EndpointSensorTelemetryLog for mapping to DS0013: Sensory Health.
https://github.com/ikiril01/d3fend-ontology/commit/f39ee1137e3ae788421e97bec578334900c1b22d
Added Snapshot/VM Snapshot/Volume Snapshot.
https://github.com/ikiril01/d3fend-ontology/commit/1f0edb21143542dda2e34b7e5a1c43eebca53188
Added User Profile for mapping to DS0021 (Persona).
https://github.com/ikiril01/d3fend-ontology/commit/7daef98ff3611a08ee56f7a0c24f1758a7563d25
Added Discovery Network Traffic for mapping to DS0035 (Internet Scan).
https://github.com/ikiril01/d3fend-ontology/commit/b667e34dcde5e3dbd939292482689221c3236d3d
Added Asset Metadata for mapping to DS0039 (Asset).
https://github.com/ikiril01/d3fend-ontology/commit/119c840ebf48ec45c567af0ae87ca31bf50b0d5f
Added Historian/Process Databases for mapping to DS0040 (Operational Database).
https://github.com/ikiril01/d3fend-ontology/commit/50a289360b298669b077c15be032e34a892326e5
Current mappings. New digital artifacts in bold, low confidence mappings in italics with question marks.
| ATT&CK DS ID | ATT&CK DS Name | Mapping Type | D3FEND DA Mapping |
|---|---|---|---|
| DS0001 | Firmware (ATTACK) | exactly | Firmware |
| DS0002 | User Account (ATTACK) | exactly | UserAccount |
| DS0003 | Scheduled Job (ATTACK) | exactly | ScheduledJob |
| DS0004 | Malware Repository (ATTACK) | exactly | MalwareRepository |
| DS0005 | WMI (ATTACK) | narrower | SystemServiceSoftware ?? |
| DS0006 | Web Credential (ATTACK) | exactly | Credential |
| DS0007 | Image (ATTACK) | exactly | DiskImage |
| DS0008 | Kernel (ATTACK) | exactly | Kernel |
| DS0009 | Process (ATTACK) | exactly | Process |
| DS0010 | Cloud Storage (ATTACK) | exactly | CloudStorage |
| DS0011 | Module (ATTACK) | exactly | ObjectFile |
| DS0012 | Script (ATTACK) | exactly | ExecutableScript |
| DS0013 | Sensor Health (ATTACK) | exactly | EndpointSensorTelemetryLog |
| DS0014 | Pod (ATTACK) | exactly | Pod |
| DS0015 | Application Log (ATTACK) | exactly | Log |
| DS0016 | Drive (ATTACK) | exactly | SecondaryStorage |
| DS0017 | Command (ATTACK) | exactly | Command |
| DS0018 | Firewall (ATTACK) | exactly | Firewall |
| DS0019 | Service (ATTACK) | exactly | ServiceApplicationProcess ?? |
| DS0020 | Snapshot (ATTACK) | exactly | VolumeSnapshot |
| DS0021 | Persona (ATTACK) | broader | UserProfile |
| DS0022 | File (ATTACK) | exactly | File |
| DS0023 | Named Pipe (ATTACK) | exactly | NamedPipe |
| DS0024 | Windows Registry (ATTACK) | exactly | WindowsRegistry |
| DS0025 | Cloud Service (ATTACK) | narrower | Software ?? |
| DS0026 | Active Directory (ATTACK) | exactly | SystemConfigurationDatabase ?? |
| DS0027 | Driver (ATTACK) | exactly | HardwareDriver |
| DS0028 | Logon Session (ATTACK)" | exactly | LoginSession |
| DS0029 | Network Traffic (ATTACK) | exactly | NetworkTraffic |
| DS0030 | Instance (ATTACK) | broader | Server ?? |
| DS0032 | Container (ATTACK) | exactly | ContainerImage |
| DS0033 | Network Share (ATTACK) | narrower | FileShareService |
| DS0034 | Volume (ATTACK) | exactly | Volume |
| DS0035 | Internet Scan (ATTACK) | exactly | DiscoveryNetworkTraffic |
| DS0036 | Group (ATTACK) | exactly | UserGroup |
| DS0037 | Certificate | exactly | Certificate |
| DS0038 | Domain Name | exactly | DomainName |
| DS0039 | Asset (ATTACK) | broader | AssetMetadata |
| DS0040 | Operational Database (ATTACK) | narrower | HistorianDatabase, ProcessDatabase |
| DS0041 | Application Vetting (ATTACK) | exactly | CodeAnalyzer |
| DS0042 | User Interface (ATTACK) | exactly | GraphicalUserInterface |