A review of how we navigated 2020 and where we’re heading in 2021

With the monumental disruptions, challenges, and hybrid work environments of 2020, we found innovative ways to collaborate and maintain momentum. We started off 2020 by launching ATT&CK for ICS and expanding it over the next few months to feature mitigations and STIX integration. A proposed ATT&CK data sources methodology was introduced, with the goal of more effectively representing adversary behavior from a data perspective. We added sub-techniques to address abstraction imbalances across the knowledge base, and for a few months, the matrix could fit on one slide again. PRE-ATT&CK’s scope was integrated into Enterprise ATT&CK, and two new tactics, Reconnaissance and Resource Development, emerged from the fusion. We released the Network Devices platform, featuring techniques targeting network infrastructure devices. The Cloud domain benefitted from refined Cloud data sources and new Cloud technique content. Our infrastructure team updated ATT&CK Navigator with new elements to enhance your visualization and planning experience. We launched the virtual ATT&CKCon PowerHour, featuring insights from ATT&CK practitioners and the ATT&CK team. Finally, we mapped techniques used in a series of intrusions involving SolarWinds (recently published as a point release to ATT&CK, v8.2) and publicly tracked reports describing those behaviors.

2021 Roadmap

Our objectives for the next 12 months shouldn’t be as disruptive as 2020’s changes. There aren’t significant structural adjustments planned and we’re looking forward to a period of stability. Our chief focus will be on enhancing and enriching content across the ATT&CK platforms and technical domains. We’ll be making incremental updates to core concepts, such as Software and Groups, and working towards a more structured contributions process, while maintaining a biannual release tempo, scheduled for April and October.

Improving and Expanding Mac/Linux | April & October 2021

We first introduced Mac and Linux techniques in 2017 and we’re ramping up our effort to improve and expand the coverage in this space. Our research efforts are ongoing, and we’re coordinating with industry partners to enrich the existing techniques and develop additional content to cover evolving adversary behavior. We’re also venturing into sub-technique exploration and the refactoring of data sources. Our current timeline is targeting macOS updates for the April release and slating Linux updates for the October release. Interested in contributing to this effort? Connect with us or check out our Contributions page.

Evolving ATT&CK Data Sources | April 2021 & October 2021

You may be aware that we’re revamping the process for ATT&CK data sources. Data sources are currently reflected in ATT&CK as properties/field objects of (sub-)techniques and are featured as a list of text strings without additional details or descriptions. With the refactoring, we’re converting the data sources into objects, a role previously only held by tactics, techniques, groups, software and mitigations. With data sources as objects, they’ll have their own corresponding properties, or metadata.

The new metadata provided by data sources includes the concepts of relationships and data components. These concepts will more effectively represent adversary behavior from a data perspective and will provide an additional sub-layer of context to data sources. Data components narrow the identification of security events, but also create a bridge between high- and low-level concepts to inform data collection strategies. They’ll also provide a good reference point to start mapping telemetry collected in your environment to specific sub(techniques) and/or tactics. With the additional context around each data source, the results can be leveraged with more detail when defining data collection strategy for techniques and sub-techniques.

An update of current Enterprise ATT&CK data sources in line with this new methodology is currently planned for the April release, with objects coming in October. Data source refactoring for other ATT&CK domains and platforms are also in progress.

Consolidating Cloud Platforms and Enhancing Data Sources | April 2021

Later this year we’ll be consolidating the AWS, Azure, and GCP platforms into a single Infrastructure as a Service (IaaS) platform. Many of you in the community provided feedback in favor of consolidation, and currently these three platforms share the same set of techniques and sub-techniques. Additionally, an IaaS platform will evolve ATT&CK for Cloud into a more inclusive domain, representing all Cloud Service Providers.

We’re also focused on creating more beneficial data sources for Cloud, shifting from a log-centric approach that isn’t necessarily the most effective for building detections, to aligning to events and API calls within the logs. The approach will mirror the refactoring happening across the rest of Enterprise and will be incorporated in future Cloud updates. IaaS data sources are in progress, and we’ll be expanding coverage to the SaaS, Azure AD, and Office 365 platforms. The initial IaaS data sources are the result of the 2020 revamping that involved normalizing name and structure of data sources across multiple Cloud vendors, with the APIs and events involved in detections across those multiple vendors relevant to a particular data source. The example below features a draft of the Instance data source:

If you have input or opinions on the future platforms or the data sources refactoring, let us know! We want to ensure that the changes we have planned are going to be beneficial to and continue to support your efforts.

Cross-Domain Mapping and Updating ICS Data Sources | October 2021

Along with Enterprise, one of our goals for ATT&CK for ICS this year is updating data sources. Network traffic is a popular source of data in ICS networks, but it often overshadows other valuable data sources, including embedded device logs, application logs, and operational databases. Some of the key elements we’ll be focusing on are processing information, asset management, configuration, performance and statistics, and physical sensors.

We’re also working on cross domain mapping. We’ve always emphasized that adversaries don’t respect theoretical boundaries, so having a deep understanding of how IT platforms are leveraged to access different domains or technology stacks, like ICS and Mobile, is really critical. The cross-domain mappings will help inform how to use the knowledge bases together and will more effectively demonstrate the full gamut and adversary behavior. Over the next few months, we’ll be focusing on mapping significant attacks against ICS, including Stuxnet, Industroyer, the 2015 Ukrainian attacks, and Triton, to Enterprise techniques This is a community effort, so if you have feedback on how you’re currently using mitigations, any input on our data source focus, or would like to contribute to the matrix, we encourage you to connect with us.

Refining and Expanding Mobile | October 2021

A key focus area for Mobile this year is working towards feature equity with Enterprise. This means continuing to refine and enhance our content, including working to identify new techniques, building out Software entries, and enhancing Group information. We’ll also be developing Mobile sub-techniques, which would provide that extra level of detail for the techniques that need it, without significantly expanding the size of the model. In addition to resolving the different levels of granularity between current techniques, sub-techniques would provide enhanced synergy between Mobile and the broader ATT&CK. The integration could potentially include unifying techniques between Mobile and Enterprise and using sub-techniques to differentiate mobile device specifics. Similar to Cloud and Network, the mobile device-specific content would still be separately viewable.

We’ve been coordinating with MITRE Engenuity as they look to examine mobile threats and how to evaluate the types of capabilities and solutions that address the threat. Their eventual goal is to provide public evaluations for Mobile, but there is still a lot of collaboration and awareness building needed to bring the community up to a collective understanding of the mobile threat landscape. Building on the criticality of a collective community understanding of Mobile threats, we kicked off a mini-series highlighting significant threats to mobile devices and we’ll continue walking through mobile security threats and how to use ATT&CK for Mobile to address them in over the next few months. We’re very interested in any adversary behavior targeting mobile devices that you’re seeing in the wild. If you would like to help us build out new techniques, or if you have data or observed behaviors you’d like to share, reach out or take a look at our Contributions page.

Investigating Container-based Techniques | Upcoming

Technique coverage for Container technologies (such as Kubernetes and Docker) have been on our docket for a while, and following the call for input in December, supporting a Center for Threat Informed Defense (CTID) research project, many of you responded with the contributions that informed the draft ATT&CK for Containers. We’re excited about this milestone, but we’re still exploring a few avenues before incorporating the techniques into ATT&CK. Most critically, we’re working to determine if adversary behaviors targeting containers result in objectives other than cryptomining. Our own research and ongoing conversations with contributors seem to point to most behaviors eventually leading to cryptomining activities, even when they involve accessing secrets such as cloud credentials.

With this in mind — we need your expertise and views from the trenches! If you’ve seen or heard of adversaries using containers for purposes such as exfiltration or collection of sensitive data, your input would be invaluable. With a better understanding of how adversary behavior in containers links to the rest of Enterprise, we’ll be able to develop a better approach for adding Containers techniques in a future ATT&CK release. We’re interested in your opinions on any gaps in the matrix or in-the-wild adversary behaviors that are not currently represented — let us know if you’d like to have a conversation!

Unleashing ATT&CK Workbench | Upcoming

Later this year we’re partnering with the CTID to launch a new toolset that will enable you to get behind the wheel and explore, create, annotate and share extensions of ATT&CK. ATT&CK Workbench will provide the tools, infrastructure, and documentation to simplify how you operate and adapt ATT&CK to local environments while staying in sync with upstream sources of ATT&CK content. Ever wanted to add some new procedures to T1531? Or monitor a threat group ATT&CK’s not currently tracking? How about sharing notes with team members on a specific object? Workbench will also enhance our ability to collaborate — you’ll be able to easily contribute techniques, extensions, and enhancements to ATT&CK. We’re excited to see how the community will leverage the toolset to apply the ATT&CK approach to new domains.

Innovating ATT&CKcon | Upcoming

We kicked off the concept of ATT&CKcon in 2018, and our inaugural venture featured around 1,250 virtual and in-person participants. In 2019, ATT&CKcon 2.0 reached more people than ever before, with 7,315 online registrations. With the global pandemic in 2020, we created ATT&CKcon Power Hour, a series of monthly 90-minute virtual power presentations, which have had a reach of over 12,000 to date. We don’t know exactly what ATT&CKcon 3.0 (4.0?) in 2021 will bring, aside from the great speakers sharing their insights from working with ATT&CK in the trenches, but we’re excited to see how it’ll continue to grow. Stay tuned for additional details on what ATT&CKcon 2021 will look like and how you can get involved.

In Closing

Listening to the ATT&CK community, incorporating your feedback, and acting on your input has always been central to our model. ATT&CK is community-driven, and your first-hand knowledge and on-the-ground experience will continue to be critical to our efforts to evolve and expand the framework. We look forward to collaborating with you and appreciate your dedication to helping us improve ATT&CK for the entire community. You can always connect with us via email, Twitter, or Slack.

©2021 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–00841–24.

---

ATT&CK 2021 Roadmap was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.

Discussion around ATT&CK often involves tactics, techniques, procedures, detections, and mitigations, but a significant element is often overlooked: data sources. Data sources for every technique provide valuable context and opportunities to improve your security posture and impact your detection strategy.

This two-part blog series will outline a new methodology to extend ATT&CK’s current data sources. In this post, we explore the current state of data sources and an initial approach to enhance them through data modeling. We’ll define what an ATT&CK data source object represents and how we can extend it to introduce the concept of data components. In our next post we’ll introduce a methodology to help define new ATT&CK data source objects.

The table below outlines our proposed data source object schema:

Where to Find Data Sources Today

Data sources are featured as part of the (sub)technique object properties:

While the current structure only contains the names of the data sources, to understand and effectively apply these data sources, it is necessary to align them with detection technologies, logs, and sensors.

Improving the Current Data Sources in ATT&CK

The MITRE ATT&CK: Design and Philosophy white-paper defines data sources as “information collected by a sensor or logging system that may be used to collect information relevant to identifying the action being performed, sequence of actions, or the results of those actions by an adversary”.

ATT&CK’s data sources provide a way to create a relationship between adversary activity and the telemetry collected in a network environment. This makes data sources one of the most vital aspects when developing detection rules for adversary actions mapped to the framework.

Need some visualizations and audio track to help decipher the relationships between data sources and the number of techniques covered by them? My brother and I recently presented at ATT&CKcon on how you can explore more about data sources metadata and how to use sources to drive successful hunt programs.

We categorized a number of ways to improve the current approach to data sources. Many of these are based on community feedback, and we’re interested in your reactions and comments to our proposed upgrades.

1. Develop Data Source Definitions

Community feedback emphasizes that having definitions for each data source will enhance efficiency while also contributing to data collection strategy development. This will enable ATT&CK users to quickly translate data sources to specific sensors and logs in their environment.

2. Standardize the Name Syntax

Standardizing the naming convention for data sources is another factor that came up during feedback conversations. As we outline in the image below, data sources can be interpreted differently. For example, some data sources are very specific, e.g., Windows Registry, while others, such as Malware Reverse Engineering, have a wider scope. We propose a consistent naming syntax structure that addresses explicitly defined elements of interest from the data being collected such as files, processes, DLLs, etc.

3. Address Redundancy and Overlapping

Another unintended consequence of not having a standard naming structure for data sources is redundancy, which can also lead to overlaps.

Example A: Loaded DLLs and DLL monitoring

The recommended data sources related to DLLs imply two different detection mechanisms; however, both techniques leverage DLLs being loaded to proxy execution of malicious code. Do we collect “Loaded DLLs” or focus on “DLL Monitoring”? Do we do both? Can they just be one data source?

Example B: Collecting process telemetry

All of the information provided by Process Command-line Parameters, Process use of Network, and Process Monitoring refer to a common element of interest, a process. Do we consider that “Process Command-Line Parameters” could be inside of “Process Monitoring”? Can “Process Use of Network” also cover “Process Monitoring” or could it be an independent data source?

Example C: Breaking down or aggregating Windows Event Logs

Finally, data sources such as “Windows Event Logs” have a very broad scope and cover several other data sources. The image below shows some of the data sources that can be grouped under event logs collected from Windows endpoints:

ATT&CK recommends collecting events from data sources such as PowerShell Logs, Windows Event Reporting, WMI objects, and Windows Registry. However, these could be already covered by “Windows Event Logs” as previously shown. Do we group every Windows data source under “Windows Event Logs” or keep them all as independent data sources?

4. Ensure Platform Consistency

There are also data sources that, from a technique’s perspective, are linked to platforms where they can’t feasibly be collected. For example, the image below highlights data sources related to the Windows platform such as PowerShell logs and Windows Registry given for techniques that can be also used on other platforms such as macOS and Linux.

This issue has been addressed to a degree by the release of ATT&CK’s sub-techniques. For instance, in the image below you can see a description of the OS Credential Dumping (T1003) technique, the platforms where it can be performed, and the recommended data sources.

While the field presentation could still lead us to relate PowerShell logs data source to non-Windows platform, once we start digging deeper into sub-technique details, the association between PowerShell logs and non-Windows platforms disappears.

Defining the concept of platforms at a data source level would increase the effectiveness of collection. This could be accomplished by upgrading data sources from a simple property or field value to the status of an object in ATT&CK, similar to a (sub)technique.

A Proposed Methodology to Update ATT&CK’s Data Sources

Based on feedback from the ATT&CK community, it made sense to start providing definitions for each ATT&CK data source. However, we realized right away that without a structure and a methodology to describe data sources, definitions would be a challenge. Even though it was simple to describe data sources such as “Process Monitoring”, “File Monitoring”, “Windows Registry” and even “DLL Monitoring”, data source descriptions for “Disk Forensics”, “Detonation Chamber” or “Third Party Application Logs” are more complex.

We ultimately recognized that we needed to apply data concepts that could help us provide more context to each data source in an organized and standardized way. This would allow us to also identify potential relationships among data sources and improve the mapping of adversary actions to data that we collect.

Our methodology for upgrading ATT&CK’s data sources is captured in the following six ideas:

1. Leverage Data Modeling

A data model is a collection of concepts for organizing data elements and standardizing how they relate to one another. If we apply this basic concept to security data sources, we can start identifying core data elements that could be used to describe a data source in a more structured way. Furthermore, this will help us to identify relationships among data sources and enhance the process of capturing TTPs from adversary actions.

Here is an initial proposed data model for ATT&CK data sources:

Based on this notional model, we can begin to identify relationships between data sources and how they apply to logs and sensors. For example, the image below represents several data elements and relationships identified while working with Sysmon event logs:

2. Define Data Sources Through Data Elements

Data modeling enables us to validate data source names and provide a definition for each one in a standardized way. This is accomplished by leveraging the main data elements present in the data we collect.

We can use the data element to name the data source related to the adversary behavior that we want to collect data about. For example, if an adversary modifies a Windows Registry value, we’ll collect telemetry from the Windows Registry. How the adversary modifies the registry, such as the process or user that performed the action, is additional context we can leverage to help us define the data source.

We can also group related data elements to provide a general idea of what needs to be collected. For example, we can group the data elements that provide metadata about network traffic and name it Netflow.

3. Incorporate Data Modeling and Adversary Modeling

Leveraging data modeling concepts would also enhance ATT&CK’s current approach to mapping a data source to a technique or sub-technique. Breaking down data sources and standardizing the way data elements relate to each other would allow us to start providing more context around adversary behaviors from a data perspective. ATT&CK users could take those concepts and identify what specific events they need to collect to ensure coverage over a specific adversary action.

For example, in the image below, we can add more information to the Windows Registry data source by providing some of the data elements that relate to each other to provide more context around the adversary action. We can go from Windows Registry to ( Process — created — Registry Key).

This is just one relationship that we can map to the Windows Registry data source. However, this additional information will facilitate a better understanding of the specific data we need to collect.

4. Integrate Data Sources into ATT&CK as Objects

The key components in ATT&CK — tactics, techniques, and groups — are defined as objects. The image below demonstrates how the technique object is represented within the framework.

While data sources have always been a property/field object of a technique, it’s time to convert them into objects, with their own corresponding properties.

5. Expand the ATT&CK Data Source Object

Once data sources are integrated as objects in the ATT&CK framework, and we establish a structured way to define data sources, we can start identifying additional information or metadata in the form of properties.

The table below outlines some initial properties we propose starting off with:

These initial properties will advance ATT&CK data sources to the next level and open the door to additional information that will facilitate more efficient data collection strategies.

6. Extend Data Sources with Data Components

Our final proposal is to define data components. The relationships we previously discussed between the data elements related to the data sources (e.g., Process, IP, File, Registry) can be grouped together and provide an additional sub-layer of context to data sources. This concept was developed as part of the Open Source Security Event Metadata (OSSEM) project and presented at ATT&CKcon 2018 and 2019. We refer to this concept as Data Components.

Data Components in action

In the image below, we extended the concept of Process and defined a few data components including Process Creation and Process Network Connection to provide additional context. The outlined method is meant to provide a visualization of how to collect from a Process perspective. These data components were created based on relationships among data elements identified in the available data source telemetry.

The diagram below maps out how ATT&CK could provide information from the data source to the relationships identified among the data elements that define the data source. It’d then be up to you to determine how best to map those data components and relationships to the specific data you collect.

What’s Next

In the second post of this two-part series, we’ll explore a methodology to help define new ATT&CK data source objects and how to implement the methodology with current data sources. We will also release the output of our initial analysis, where we applied these data modeling concepts to draft a sample of the new proposed data source objects. In the interim, we appreciate those who contributed to the discussions around data sources and we look forward to your additional feedback.

©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–00841–11.

---

Defining ATT&CK Data Sources, Part I: Enhancing the Current State was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Part I of this two-part blog series, we reviewed the current state of the data sources and an initial approach to enhancing them through data modeling. We also defined what an ATT&CK data source object represents and extended it to introduce the concept of data components.

In Part II, we’ll explore a methodology to help define new ATT&CK data source objects, how to implement the methodology with current data sources, and share an initial set of data source objects at https://github.com/mitre-attack/attack-datasources.

Formalizing the Methodology

In Part I we proposed defining data sources as objects within the ATT&CK framework and developing a standardized approach to name and define data sources through data modeling concepts. Our methodology to accomplish this objective is captured in five key steps — Identify Sources of Data, Identify Data Elements, Identify Relationships Among Data Elements, Define Data Components, and Assemble the ATT&CK Data Source Object.

Step 1: Identify Sources of Data

Identifying the security events to inform the specific ATT&CK data sources being assessed kickstarts the process. The security events can be uncovered by reviewing the metadata in the event logs that reference the specific data source (i.e., process name, process path, application, image). We recommend complementing this step with documentation or data dictionaries that identify relevant event logs to provide the key context around the data source. It’s important at this phase in the process to document where the data can be collected (collection layer and platform).

Step 2: Identify Data Elements

Extracting data elements found in the available data enables identification of the data elements that could provide the name and the definition of the data source.

Step 3: Identify Relationships Among Data Elements

During the identification of data elements, we can also start documenting the available relationships that will be grouped to enable us to define potential data components.

Step 4: Define Data Components

The output of grouping the relationships is a list of all potential data components that could provide additional context to the data source.

Step 5: Assemble the ATT&CK Data Source Object

Connecting all of the information from previous steps enables us to structure them as properties of the data source object. The table below provides an approach for organizing the combined information into a data source object.

Operationalizing the Methodology

To illustrate how the methodology can be applied to ATT&CK data sources, we feature use cases in the following sections that reflect and operationalize the process.

Starting with the ATT&CK data source that is mapped to the most sub-techniques in the framework, Process Monitoring, we will create our first ATT&CK data source object. Next we will create another ATT&CK data source object around Windows Event Logs, a data source that is key for detecting a significant number of techniques

Windows is leveraged for the use cases, but the approach can and should be applied to other platforms.

Improving Process Monitoring

1) Identifying Sources of Data: In a Windows environment, we can collect information pertaining to “Processes” from built-in event providers such as Microsoft-Windows-Security-Auditing and open third-party tools, including Sysmon.

This step also takes into account the overall security events where a process can be represented as the main data element around an adversary action. This could include actions such as a process connecting to an IP address, modifying a registry, or creating a file. The following image displays security events from the Microsoft-Windows-Security-Auditing provider and the associated context about a process performing an action on an endpoint:

These security events also provide information about other data elements such as “User”, “Port” or “Ip”. This means that security events can be mapped to other data elements depending on the data source and the adversary (sub-)technique.

The source identification process should leverage available documentation about organization-internal security events. We recommend using documentation about your data or examining data source information in open source projects such as DeTT&CT, the Open Source Security Events Metadata (OSSEM), or ATTACK Datamap.

An additional element that we can extract from this step is the data collection location. A simple approach for identifying this information includes documenting the collection layer and platform for the data source:

• Collection Layer: Host
• Platform: Windows

The most effective data collection strategy will be customized to your unique environment. From a collection layer standpoint, this varies depending on how you collect data in your environment, but Process information is generally collected directly from the endpoint. From a platform perspective, this approach can be replicated on other platforms (e.g., Linux, macOS, Android) with the corresponding data collection locations captured.

2) Identifying Data Elements: Once we identify and understand more about sources of data that can be mapped to an ATT&CK data source, we can start identifying data elements within the data fields that could help us eventually represent adversary behavior from a data perspective. The image below displays how we can extend the concept of an event log and capture the data elements featured within it.

We will also use the data elements identified within the data fields to create and improve the naming of data sources and inform the data source definition. Data source designations are represented by the core data element(s). In the case of Process Monitoring, it makes sense for the data source name to contain “Process” but not “Monitoring,” as monitoring is an activity around the data source that is performed by the organization. Our naming and definition adjustments for “Process” are featured below:

• Name: Process
• Definition: Information about instances of computer programs that are being executed by at least one thread.

We can leverage this approach across ATT&CK to strategically remove extraneous wording in data sources.

3) Identifying Relationships Among Data Elements: Once we have a better understanding of the data elements and a more relevant definition for the data source itself, we can start extending the data elements information and identifying relationships that exist among them. These relationships can be defined based on the activity described by the collected telemetry. The following image features relationships identified in the security events that are related to the “Process” data source.

4) Defining Data Components: All of the combined information aspects in the previous steps contribute to the concept of data components in the framework.

Based on the relationships identified among data elements, we can start grouping and developing corresponding designations to inform a high-level overview of the relationships. As highlighted in the image below, some data components can be mapped to one event (Process Creation -> Security 4688) while other components such as “Process Network Connection” involve more than one security event from the same provider.

“Process” now serves as an umbrella over the linked information facets relevant to the ATT&CK data source.

5) Assembling the ATT&CK Data Source Object: Aggregating all of the core outputs from the previous steps and linking them together represents the new “Process” ATT&CK data source object. The table below provides a basic example of it for “Process”:

Improving Windows Event Logs

1) Identifying Sources of Data: Following the established methodology, our first step is to identify the security events we can collect pertaining to “Windows Event Logs”, but it’s immediately apparent that this data source is too broad. The image below displays a few of the Windows event providers that exist under the “Windows Event logs” umbrella.

The next image reveals additional Windows event logs that could also be considered sources of data.

With so many events, how do we define what needs to be collected from a Windows endpoint when an ATT&CK technique recommends “Windows Event Logs” as a data source?

2–3–4) Identifying Data Elements, Relationships and Data Components: We suggest that the current ATT&CK data source Windows Event Logs can be broken down, compared with other data sources for potential overlaps, and replaced. To accomplish this, we can duplicate the process we previously used with Process Monitoring to demonstrate that Windows Event Logs covers several data elements, relationships, data components and even other existing ATT&CK data sources.

5) Assembling the ATT&CK Data Source Object: Assembling the outputs from the process, we can leverage the information from Windows security event logs to create and define a few data source objects.

In addition, we can identify potential new ATT&CK data sources. The User Account case was the result of identifying several data elements and relationships around the telemetry generated when adversaries create a user, enable a user, modify properties of a user account, and even disable user accounts. The table below is an example of what the new ATT&CK data source object would look like.

This new data source could be mapped to ATT&CK techniques such as Account Manipulation (T1098).

Applying the Methodology to (Sub-)Techniques

Now that we’ve operationalized the methodology to enrich ATT&CK data through defined data source objects, how does this apply to techniques and sub-techniques? With the additional context around each data source, we can leverage the results with more context and detail when defining a data collection strategy for techniques and sub-techniques.

Sub-Technique Use Case: T1543.003 Windows Service

T1543 Create and Modify System Process (used to accomplish Persistence and Privilege Escalationtactics) includes the following sub-techniques: Launch Agent, System Service, Windows Service, and Launch Daemon.

We’ll focus on T1543.003 Windows Service to highlight how the additional context provided by the data source objects make it easier to identify potential security events to be collected.

Based on the information provided by the sub-technique, we can start leveraging some of the ATT&CK data objects that can be defined with the methodology. With the additional information from Process, Windows Registry and Service data source objects, we can drill down and use properties such as data components for more specificity from a data perspective.

In the image below, concepts such as data components not only narrow the identification of security events, but also create a bridge between high- and low-level concepts to inform data collection strategies.

Implementing these concepts from an organizational perspective requires identifying what security events are mapped to specific data components. The image above leverages free telemetry examples to illustrate the concepts behind the methodology.

This T1543.003 use case demonstrates how the methodology aligns seamlessly with ATT&CK’s classification as a mid-level framework that breaks down high-level concepts and contextualizes lower-level concepts.

Where can we find initial Data Sources objects?

The initial data source objects that we developed can be found at https://github.com/mitre-attack/attack-datasources in Yaml format for easy consumption. Most of the data components and relationships were defined from a Windows Host perspective and there are many opportunities for contributions from collection layer (i.e. Network, Cloud) and platform (i.e. Mac, Linux) perspectives for applying this methodology.

Outlined below is an example of the Yaml file structure for the Service data source object:

Going Forward

In this two-part series, we introduced, formalized and operationalized the methodology to revamp ATT&CK data sources. We encourage you to test this methodology in your environment and provide feedback about what works and what needs improvement as we consider adopting it for MITRE ATT&CK.

As highlighted both in this post and in Part I, mapping data sources to data elements and identifying their relationships is still a work in progress and we look forward to continuing to develop this concept with community input.

©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–02605–3

---

Defining ATT&CK Data Sources, Part II: Operationalizing the Methodology was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.