Threats and how we counter them have become key considerations in a system’s cybersecurity architecture and design. This applies whether we are designing a new system, addressing regulatory requirements to operate in a particular mission environment, or just working to meet organizational needs. Adoption of zero trust strategies, security by design guidance, and DevSecOps are core to a system’s cybersecurity architecture and design in both the public and private sector.
In this blog post, we discuss a method that combines information about security requirements, controls, and capabilities with analysis regarding cyber threats to enable more effective risk-guided system planning. In plain language, it’s a way of creating a crosswalk from system and security requirements to threats. To adhere to already established federal government policies and guidelines while maintaining alignment with industry standards, we used four primary types of data:
- Defense Information Systems Agency (DISA) Control Correlations Identifiers (CCIs)are used to express individual technical or procedural requirements and how they connect to higher-level control objectives. CCIs are identified with unique codes (e.g., CCI-000015) which are maintained by DISA. This creates an ability to trace security requirements from their origin (e.g., regulations, information assurance frameworks) to low-level implementation choices, allowing organizations to readily demonstrate compliance with multiple information assurance frameworks. They are primarily used by DoW agencies and contractors, but they are good for many activities that are common across other sectors, such as compliance tracking, auditing and reporting, and standardization. CCIs are mapped to multiple regulatory frameworks as well, which allows us to objectively roll up and compare related compliance assessment results across disparate technologies. If you work with Security Technical Implementation Guides (STIGs) or NIST compliance frameworks, it is likely you’ll encounter and use CCIs.
- National Institute of Standards and Technology (NIST) Security and Privacy Controls for Information Systems and Organizations (SP 800-53) standardizes security and privacy safeguards for information systems. This publication details controls that are designed to protect the confidentiality, integrity, and availability of information systems. The control standards are flexible and approach security with a risk-based focus. Due to its wide use in the government as well as industry for defining security requirements for information systems and auditing them, it is a great baseline source for best practices.
- The MITRE ATT&CK Framework is used heavily to abstract the behavior of threat actors in a way that makes information sharing possible, allows behavior emulation for internal training, and creates opportunity for systems architects and security practitioners to apply strategic investments for the protection of interconnected systems. The framework is used in many products and applications across industries, and specific matrices have been created for industrial control systems, mobile devices, and enterprise systems. In this work we primarily focus on the enterprise matrix because it is the most similar to the environments that we developed this method for.
- MITRE Detection, Denial, and Disruption Framework Empowering Network Defense (D3FEND) Countermeasures act as a complement to the MITRE ATT&CK Framework. This recently developed ontology provides a descriptive language for cybersecurity capabilities, primarily targeted at the defender’s perspective, and a method for relating ATT&CK TTPs to D3FEND through semantic connections. To support use of the ontology, MITRE developed many resources that show connections to D3FEND and allow for the development of tools like their D3FEND Profile Studio and D3FEND CAD. These tools enable modeling of D3FEND, which allows us to express the cyber terrain of interest in a manner that connects it to the potential threats of interest.
Beyond the requirements for the data, we sought to make our approach a repeatable process to provide actionable information for leaders and analysts at the strategic, operational, and tactical levels of an organization.
Relationships and Linkages Between Data Sources
The data sources we have used so far tend to share at least some commonalities (i.e., keys where we can merge the data to gain new insights). These keys are not often exactly aligned. As noted, our work primarily utilizes the MITRE datasets for ATT&CK and D3FEND, including their references to CCI and STIG data.
Both the ATT&CK and D3FEND data are represented computationally, in both cases using monolithic JSON files: ATT&CK is a knowledge base implemented in STIXv2 format, and the D3FEND data is an ontology structured as a graph network with semantic information about the relationship type between nodes. There is a CSV of D3FEND that we used to programmatically correlate CCIs and 800-53 controls and to enable visual inspection of the mappings along the way.
We developed functions in Python to create scripts that leveraged connections between ATT&CK, D3FEND, and other datasets. Our choice of Python enabled us to use existing libraries such as mitreattack-python, stix2, and rdflib. These libraries were particularly helpful in developing the scripts. There are a number of issues that arise in developing automated approaches including, particularly, the lack of exact string matches among data sources, which made it more challenging to develop linkages between data sources. Label normalization and expert validation, especially early in the process of data cleaning and collection, can provide great benefits to the automating process and validity of the resulting crosswalk.
Transformation/Composition Example
This example highlights the process of aligning a set of tools, techniques, and practices (TTPs) to a selected operational terrain. The cybersecurity capabilities deployed on a terrain must already be described with either D3FEND or NIST 800-53r5 controls to express the effectiveness of those defensive countermeasures against the TTPs. Effectiveness, the degree to which a capability addresses a threat, is represented by five categories: covered (alerted + blocked), blocked, alerted, open, and unmapped. To follow this process
1) Analysts start with a list of TTPs of interest.
2) Use the MITRE D3FEND data to assemble a list of effects each countermeasure has on that TTP. These effects currently have 34 values, but for our purposes we are interested in just three of them: block (we have thwarted an attack), alert (we are alerted that an attack is accomplished or underway), and open (we fail to be alerted to an attack of this kind).
3) Assign weights to the three effects such that block is optimal, alert is OK, and open is the least desirable.
4) For each TTP, sort the list of countermeasure effects by their weights. The overall effectiveness of the countermeasure on that TTP is selected from the highest (best) weight.
5) From there, associate a list of TTPs with each of the countermeasure effectiveness categories.
6) Use that information for whatever analysis drove the exercise, such as resource allocation for security in development or operations.
Limitations With Our Transformation Approach
As with many methods that rely upon disparate resources and datasets, there are limitations to this approach. We are connecting many different resources, often using semantic mappings provided by other organizations. While we must trust that the mappings were created in a method that makes them accurate, the base resource is attempting to convey a slightly different understanding of the information contained within. These crosswalks make a generalization between the scopes of the resources, and if there happens to be any nuances to the translation, the nuances will be inherited by the result. To mitigate the potential for inheritance of inaccurate or misrepresentative information, an information security professional or subject matter expert should go over the input data, the process, and the output to ensure the highest degree of accuracy.
While our hope is that the process itself is stable, there are some things within that may lead to misinterpretation. By using the connections between D3FEND and ATT&CK as our primary means of expressing threat, there is potential for simplification and abstraction of the threat landscape. TTPs are not a perfect representation of what is physically happening or being done by a threat actor. They offer a means of abstraction that in some cases allows loss of details. This can lead to a risk from the misinterpretation of coverage and variations in what is actually discoverable. It is always important to validate results and not simply rely upon a mapping to ensure knowledge of an attack surface. Additionally, TTPs focus on known behaviors. This means that a novel approach or attack might not be covered.
Practical Use Cases for Terrain Threat Mapping
We have identified the following areas as potential spaces that could use this process:
- Potential threat/gap analysis of cyber terrain. With this method we can compare the known TTPs of an adversary to the TTPs that the cyber terrain is able to detect or block.
- Security investment and prioritization. By mapping many cyber terrain elements, it is possible to compare them to each other and inform a risk-based approach to improving security.
- Cyber threat exercise development. Quickly compare what the red and blue teams are capable of to identify gaps. Identify prioritization of efforts, or duplicative efforts in an exercise. Provide a method of creating visualizations quickly to enhance the exercise.
- Translation of requirements. Many audits require proof of implementation of controls in different frameworks; through this process there is a way to show coverage or similarity between different audit requirements. This includes becoming a source of data for high value asset audits.
- Solution comparison. By utilizing this mapping process, it becomes possible to perform a comparison of vendor offerings, solutions, and proposed implementations on equal ground
- Dashboarding applications. The mappings and relationships can be used to assist with the creation or to inform cybersecurity dashboard applications for executives or defense industrial base partners.
In addition to use cases that are specifically targeted at the application of the mapping process for threat interpretation, it is possible that this process could lead to improvements in alignment of nomenclature, semantical precision, and other features of the models that would, in the end, enhance their utility in development and operations.
Expanding the Process
In the future, through the connections to ATT&CK, CCIs, and NIST 800-53r5, we can expand this process into different domains. Occasionally a TTP does not align with any artifacts associated with D3FEND, CCI, or 800-53. This does not mean that the TTP is irrelevant, just that we don’t have a relationship expressed yet. With further development, it may be possible to reduce these gaps. There are also other relevant applications that this process can connect to.
The DoD has offered guidance for zero trust that MITRE has helpfully translated into NIST 800-53r5 controls. With this process, security architects and analysts would be able to develop a crosswalk that expresses zero trust in CCIs, ATT&CK, and D3FEND. Similar to the Cloud Security Alliance’s Cloud Control Matrix (CCM), having a method and tool that maps controls for multiple standards and regulations could simplify the auditing process and clarify communications between teams with different priorities, such as engineering and sales teams. We are considering cross-walking NIST SP 800-160 Volume 2, Revision 1 Developing Cyber-Resilient Systems: A Systems Security Engineering Approach to consider the resilience of a system as well. In addition, a connection to the Critical Security Controls developed by the Center for Internet Security (CIS) could be useful for possible relevance with the STRIDE-LM threat model and industry compliance standards.
In addition to linking with other domains, there can be adaptations coming from the continual improvements of the existing data sources. In the version 18 release of ATT&CK, for example, it is expected that TTPs will start to include log locations as potential data sources for identifying TTPs. This will change ATT&CK detection guidance into a detection strategy focused system. This expands the ability of ATT&CK in event correlation and in combination with D3FEND can help further our attempts to define coverage. With these updates, there may be a way to better define the relevance of a TTP to a kind of terrain.
By keeping these practical considerations in mind—data that is publicly accessible, accurate, current, and versatile—we lay a solid foundation for finding meaningful connections with this method. When the source material is curated by trustworthy and knowledgeable custodians, its reliability boosts confidence in the connections that are drawn and encourages broader adoption of those shared, public resources. As the ecosystem of openly‑available controls, requirements, and threat intelligence continues to evolve, this correlation methodology will become ever more robust. This progression promises improved use cases that streamline workflows for development teams, and enable stronger, more resilient security architectures, and system design.
