Defining ATT&CK Data Sources

As part of the revamping process of ATT&CK data sources, we have defined an initial methodology that will help us improve the definition of current data sources. The idea behind this methodology is to ensure same quality of information among data sources, and provide additional information or metadata related to data sources in order to get a better understanding of them.

Data Source Object

Currently, data sources are metadata provided for each (sub)technique. However, in order to be able to add metadata to each data source, we have proposed the definition of a data source object as part of the ATT&CK model.

Data_Source_Object

Relationships & Sub Data Sources

As part of the new metadata provided by ATT&CK data sources, we proposed the following concepts: relationships and data components. These concepts will help us to represent adversary behavior from a data perspective. In addition, they might be good reference to start mapping telemetry collected in your environment to specific sub(techniques) and/or tactics.

Sub_Technique_Data_Components

Where can you find Data Sources Objects?

We are storing this new metadata using YAML files, so you can access this content programatically.

- name: Service
  definition: Information about software programs that run in the background and typically start with the operating system.
  collection_layers:
    - host
  platforms:
    - Windows
  contributors: 
    - ATT&CK
  data_components:
    - name: service creation
      type: activity
      relationships:
        - source_data_element: user
          relationship: created
          target_data_element: service
  references:
    - https://docs.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications
    - https://www.linux.com/news/introduction-services-runlevels-and-rcd-scripts/

In the image above, you can see the structure of the Service data source as an example of the content you will find within each YAML file.

Based on our initial research, we have identified relationships such as: A user has created a Service

We are grouping these type of relationships within the data component: Service Creation.

How can we consume this information?

The idea of storing all this data using YAML files is to facilitate the consumption of data sources definition content. So, feel free to use any tool that can handle yaml files and that is available for you. We have prepared a Jupyter notebook using libraries such attackcti, pandas, and yaml to give you an example of how can you gather up to date ATT&CK knowledge and YAML files' content, so you can merge all this information. You can find the notebook in the following link.

Something you need to consider when consuming the data within each YAML file is that some of the names of current data sources has been changed based on the propoed methodology. We are also providing a YAML file showing current and proposed data sources names. The structure of the YAML files is showed below: On the left, you can see the current names of data sources and on the right you can see the proposed name.

Sensor health and status: Sensor log
Access tokens: Access token
PowerShell logs: Powershell log
API monitoring: API
Application logs: Application log
File monitoring: File
Authentication logs: Authentication log
Named Pipes: Named pipe
Process monitoring: Process
Process use of network: Process
Process command-line parameters: Process
DLL monitoring: Module
Loaded DLLs: Module
Windows Registry: Windows registry
DNS records: DNS record
Digital certificate logs: Digital certificate log
WMI Objects: WMI object
Services: Service

GitHub