Automate mappings to data sources in attack_update script

netfl0 commented 7 months ago

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

netfl0 commented 7 months ago

9c67018c3b941bf685c49f1ea3f97053a3233be2

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

aamedina commented 7 months ago

How can I help on this?

netfl0 commented 7 months ago

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

ikiril01 commented 7 months ago

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.