Cyber Security

In Pursuit of a Gestalt Visualization: Merging MITRE ATT&CK® for Enterprise and ICS to Communicate Adversary Behaviors

(Note: The content of this post is being released jointly with Mandiant. It is co-authored with Daniel Kapellmann Zafra, Keith Lunden, Nathan Brubaker and Gabriel Agboruche. The Mandiant post can be found here.)

Understanding the increasingly complex threats faced by industrial and critical infrastructure organizations is not a simple task. As high-skilled threat actors continue to learn about the unique nuances of operational technology (OT) and industrial control systems (ICS), we increasingly observe attackers exploring a diversity of methods to reach their goals. Defenders face the challenge of systematically analyzing information from these incidents, developing methods to compare results, and communicating the information in a common lexicon. To address this challenge, in January 2020, MITRE released the ATT&CK for ICS knowledge base, which categorizes the tactics, techniques, and procedures (TTPs) used by threat actors targeting ICS.

MITRE’s ATT&CK for ICS knowledge base has succeeded in portraying for the first time the unique sets of threat actor TTPs involved in attacks targeting ICS. It picks up from where the Enterprise knowledge base leaves off to explain the portions of an ICS attack that are out of scope of ATT&CK for Enterprise. However, as the knowledge base becomes more mature and broadly adopted, there are still challenges to address. As threat actors do not respect theoretical boundaries between IT or ICS when moving across OT networks, defenders must remember that ATT&CK for ICS and Enterprise are complementary. As explained by MITRE’s ATT&CK for ICS: Design & Philosophy paper, an understanding of both knowledge bases is necessary for tracking threat actor behaviors across OT incidents.

In this blog, written jointly by Mandiant Threat Intelligence and MITRE, we evaluate the integration of a hybrid ATT&CK matrix visualization that accurately represents the complexity of events across the OT Targeted Attack Lifecycle. Our proposal takes components from the existing ATT&CK knowledge bases and integrates them into a single matrix visualization. It takes into consideration MITRE’s current work in progress aimed at creating a STIX representation of ATT&CK for ICS, incorporating ATT&CK for ICS into the ATT&CK Navigator tool, and representing the IT portions of ICS attacks in ATT&CK for Enterprise. As a result, this proposal focuses not only on data accuracy, but also on the tools and data formats available for users.

Joint Analysis of Enterprise and ICS TTPs to Portray the Full Range of Actor Behaviors

For years, Mandiant has leveraged the ATT&CK for Enterprise knowledge base to map, categorize, and visualize attacker TTPs across a variety of cyber security incidents. When ATT&CK for ICS was first released, Mandiant began to map our threat intelligence data of OT incidents to the new knowledge base to categorize detailed information on TTPs leveraged against ICS assets. While Mandiant found the knowledge base very useful for its unique selection of techniques related to ICS equipment, we noticed how helpful it could be to develop a standard way to group and visualize both Enterprise and ICS TTPs to understand and communicate the full range of actors’ actions in OT environments during most incidents we had observed. We reached out to MITRE to discuss the benefits of joint analysis of Enterprise and ICS ATT&CK techniques and exchanged some ideas on how to best integrate this task as they continued to work on the evolution of these knowledge bases.

Enterprise and ICS TTPs Are Necessary to Account for Activity in Intermediary Systems

One of the main challenges faced by ATT&CK for ICS is categorizing activity from a diverse set of assets present in OT networks. While the knowledge base contains TTPs that effectively explain threats to ICS — such as programmable logical controllers (PLCs) and other embedded systems — it by design does not include techniques related to OT assets that run on similar operating systems, protocols, and applications as enterprise IT assets. These OT systems, which Mandiant defines as intermediary systems, are often used by threat actors as stepping-stones to gain access to ICS. These workstations and servers are typically used for ICS functionalities such as running human machine interface (HMI) software or programming and exchanging data with PLCs.

At the system level, the scope of ATT&CK for ICS includes most of the ICS software and relevant system resources running on these intermediary Windows and Linux-based systems while omitting the underlying OS platform (Figure 2). While the majority of ATT&CK for Enterprise techniques are thus descoped, there remains some overlap in techniques between ATT&CK for ICS and ATT&CK for Enterprise as the system resources granted to ICS software are in-scope for both knowledge bases. However, this artificial divorce of the ICS software from the underlying OS can be inconsistent with an adversaries’ possible overarching control of the compromised asset.

As MITRE’s ATT&CK for ICS was designed to rely on ATT&CK for Enterprise to categorize adversary behaviors in these intermediary systems, there is an opportunity to develop a standard mechanism to analyze and communicate incidents using both knowledge databases simultaneously. As the two knowledge bases still maintain an undefined relationship, it may be difficult for ATT&CK users to understand and interpret incidents consistently. Furthermore, ICS owners and operators who unknowingly discard ATT&CK for Enterprise in favor of ATT&CK for ICS run the risk of missing valuable intelligence applicable to the bulk of their OT assets.

Enterprise and ICS TTPs Are Useful to Foresee Future Attack Scenarios

As MITRE notes in their ATT&CK for ICS: Design & Philosophy paper, the selection of techniques for ATT&CK for ICS is mainly based on available evidence of documented attack activity against ICS and the assumed capabilities of ICS assets. While the analysis of techniques based on previous observations and current capabilities presents a solid preamble to describe threats in retrospect, Mandiant has identified an opportunity for ATT&CK knowledge and tools to support OT security organizations to foresee novel and future scenarios. This is especially relevant in the evolving field of OT security, where asset capabilities are expanding, and we have only observed a small number of well-documented events that have each followed a different attack path based on the target.

MITRE’s intent is to limit the ATT&CK knowledge base to techniques that have been observed against in-scope assets. However, from Mandiant’s perspective as a security vendor, the analysis of exhaustive techniques–including both observed and feasible cases from Enterprise and ICS–is helpful to foresee future scenarios and protect organizations based upon robust and abundant data. Additionally, as new IT technologies such as virtualization or cloud services are adopted by OT organizations and implemented in products from original equipment manufacturers, the knowledge base will require flexibility to explain future threats. Adapting ATT&CK for ICS to the novelty of future ICS incidents enhances the knowledge base’s long-term viability across the industry. This can be accomplished by merging ATT&CK for Enterprise and ICS, as the Enterprise techniques are readily available as future, theoretical ICS technique categories.

A Hybrid ATT&CK Matrix Visualization for OT Security Incidents

To address these observations, Mandiant and MITRE have been exploring ways of visualizing the Enterprise and ICS ATT&CK knowledge bases together as a single matrix visualization. A mixed visualization offers a way for users to track and analyze the full range of tactics and techniques that are present during all stages of the OT Targeted Attack Lifecycle. Another benefit is that a hybrid ATT&CK matrix visualization will help defenders portray future OT incidents that employ tactics and techniques beyond what has currently been observed in the wild. Figure 3 shows our perception of this hybrid visualization that incorporates TTPs from both the Enterprise and ICS ATT&CK knowledge bases into a single matrix. (We note that the tactics presented in the matrix are not arranged in chronological order and do not reflect the temporality of an incident).

This visualization of the hybrid ATT&CK matrix shows in gray the novel tactics and techniques from ATT&CK for ICS, which were placed within the ATT&CK for Enterprise matrix. It shows in blue the overlapping techniques found in both the Enterprise and ICS matrices. The visualization addresses three concerns:

· It presents a holistic view of an incident involving both ICS and Enterprise tactics and techniques throughout the attack lifecycle.

· It eliminates tactic and technique overlaps between the two knowledge bases, for example by combining Defense Evasion techniques into a single tactic.

· It differentiates the abstraction level of techniques contained in the impact tactic categories of both the ATT&CK for Enterprise and ICS knowledge bases.

The separation of the Enterprise Impact and ICS Impact tactics responds to the need to communicate the different abstraction levels of both knowledge bases. While Enterprise Impact focuses on how adversaries impact the integrity or availability of systems and organizations via attacks on IT platforms (e.g. Windows, Linux, etc.), ICS Impact focuses specifically on how attackers impact ICS operations. When analyzing an incident from the scope of the hybrid ATT&CK matrix visualization, it is possible to observe how an attacker can cause ICS impacts directly through an Enterprise impact, such as how Data Encrypted for Impact (T1486) could cause Loss of View (T0829).

As threat actors do not respect theoretical boundaries between IT and ICS when moving across OT networks, the hybrid visualization is based on the concept of intermediary systems as a connector to visualize and communicate the full picture we observe during the OT Targeted Attack Lifecycle. This results in more structured and complete data pertaining to threat actor behaviors. The joint analysis of Enterprise and ICS TTPs following this structure can be especially useful for supporting a use case MITRE defines as Cyber Threat Intelligence Enrichment. The visualization also accounts for different types of scenarios where actors willingly or unwillingly impact ICS assets at any point during their intrusions. Additional benefits can spill across other ATT&CK use cases such as:

· Adversary Emulation: by outlining paths followed by sophisticated actors involved in long campaigns for IT and OT targeting.

· Red Teaming: by having access to comprehensive attack scenarios to test organizations’ security not only based on what has happened but what could happen in the future.

· Behavioral Analytics Development: by identifying risky behavioral patterns in the intersection between OT intermediary systems and ICS.

· Defensive Gap Assessment: by identifying the precise lack of defenses and visibility that threat actors can and have leveraged to interact with different types of systems.

Refining the Hybrid ATT&CK Matrix Visualization for an OT Environment

The hybrid ATT&CK matrix visualization represents a simple solution for holistic analysis of incidents leveraging components from both knowledge bases. The main benefits of such visualization are that it is capable of portraying the full range of tactics and techniques an actor would use across the OT Targeted Attack Lifecycle, and that it also accounts for future incidents that we may not have thought about. However, there is also value in thinking about other alternatives for addressing our concerns — for example, to expand ATT&CK for ICS to reflect everything that could happen in an OT environment.

The main option Mandiant and MITRE evaluated was to identify which of all ATT&CK for Enterprise techniques could feasibly impact intermediary systems interacting with ICS and define alternatives to handle overlaps between both knowledge bases. We particularly analyzed the possibility of making this selection based on type of assets (e.g. OS and software applications) that are likely to be present in an OT network.

Although the idea sounds appealing, our initial analysis suggests that shortlisting ATT&CK for Enterprise techniques that apply to OT intermediary systems may be feasible but would result in limited benefits. The ATT&CK for Enterprise site separates the 184 current techniques into a few different platforms. Table 1 presents these platforms and their distribution.

· Close to 96 percent of the techniques included in the enterprise knowledge base are applicable to Windows devices, and close to half apply for Linux. Considering that most intermediary systems are based on these two operating systems, the feasible reduction of techniques applicable to OT is quite low.

· Devices based on macOS are rare in OT environments, however, we highlight most of the techniques for affecting these devices match with others observed in Windows and Linux. Additionally, we cannot discard the possibility of at least a few asset owners using products based on macOS.

· Cloud products are also rare in industrial environments. However, it is still possible to find them in business applications such as manufacturing execution systems (MES), building management systems (BMS) application backends, or other systems for data storage. Major vendors such as Microsoft and Amazon have recently started offering cloud products, for example, for organizations in energy and utilities. Another example is Microsoft Office 365 suite, which although not critical for production environments, is likely present in at least a few workstations. As a result, we cannot entirely discard cloud infrastructure as a target for future attacks to OT.

Vouching for a Hybrid Visualization to Holistically Approach OT Security

The hybrid ATT&CK matrix visualization can address the need to consider intermediary systems to analyze and understand OT security incidents. While it does not seek to reinvent the wheel by significantly modifying the structure of ATT&CK for Enterprise or ICS, it suggests a way to visualize both sets of tactics and techniques to reflect the full array of present and future threat actor behaviors across the OT Targeted Attack Lifecycle. The hybrid ATT&CK matrix visualization has the capability to reflect some of the most sophisticated OT attack scenarios, as well as fairly simple threat activity that would otherwise remain unobserved.

As ATT&CK for ICS continues to mature and becomes more broadly adopted by the industry, Mandiant hopes that this joint analysis will support MITRE as they continue to build upon the ATT&CK knowledge bases to support our common goal: defending OT networks. Given that attackers do not respect any theoretical boundaries between enterprise or ICS assets, we are convinced that understanding adversary behaviors requires a comprehensive, holistic approach.

The hybrid ATT&CK matrix visualization .xls can be downloaded here

©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 19–03307–6.

In Pursuit of a Gestalt Visualization: Merging MITRE ATT&CK® for Enterprise and ICS to Communicate 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.