In the first blog of this series, we constructed a list of identified ATT&CK® (Sub-)Techniques and the Tactics relevant for a given incident.
In this second blog post, we’ll decompose the JSON data structure for enterprise-attack.json provided on Github by MITRE. This file can be considered as the backend information storage for the MITRE ATT&CK® website. We’ll cover the elements that are of interest for automating pulling information from the JSON file and generating overviews of the collections of identified ATT&CK® (Sub-)Techniques with the available mitigations and detections from the ATT&CK® framework. We’ll extent this information with the help of the CIS Controls – MITRE ATT&CK® mappings and eventually the NIST 800-53 Rev 5 controls – MITRE ATT&CK® mappings. As a result, there will be a presentation of the CIS Controls and/or NIST 800-53 Rev 5 coverage for each proposed mitigation, should these be implemented. We don’t stop there though. We’ll also include the Open Source Security Events Metadata (OSSEM) Detection Model in the detections part, and throw in Atomic Red Team™ tests into the party to generate an initial validations part.
In the JSON data structure, the objects element is an array that virtually contains all information from the MITRE ATT&CK®.
The attack-pattern GUID of a given (Sub-)Technique is required to find the relations with the related mitigations and detections. The values of the GUIDs are within an object called type.
The available types are:
We will be covering some other types from the list to construct the information blocks we need as we go.
There’s a relationship schema as the author understands the data structure at the bottom of the article.
The given (Sub-)Technique is defined in an array called external_references¸ an array containing source_name-, external_id-, and url-value pairs. The array object with the "source_name": "mitre-attack" pair will refer in external_id to the ID used across MITRE ATT&CK® to denominate (Sub-)Techniques, such as T1110.001. The url is the (Sub-)Techniques page on the MITRE ATT&CK® website.
As such we can work out the attack-pattern ID tied to the relevant (Sub-)Technique.
As per example screenshot below, we now have this information available to us:
You may note that another array object, kill_chain_phases is expanded. The defined pairs phase_name will provide the relationship of the given (Sub-)Technique with the Tactic(s). Some (Sub-)Techniques are found in multiple Tactics, so depending on the incident, not all of the Tactics are relevant for the (Sub-)Technique at hand.
In the example above, the Sub-Technique T1110.001 is to be found in the Tactic credential-access.
The name-value pair is the name of the (Sub-)Technique. Here we’re dealing with Password Guessing.
The description-value pair is the last one we need to point out here. This adheres to the naming and provides the available information in MITRE ATT&CK® to describe the (Sub-)Technique.
So we’ve added following information to the previous list:
With the above elements, we can construct an overview of multiple ATT&CK® (Sub-)Techniques representing the information available on the website.
Now we want to construct the collection of possible mitigations for all identified ATT&CK® (Sub-)Techniques.
Therefore, we need to look for the relationship_type with a value of mitigates and the target_ref-value pair for the selected (Sub-)Techniques. For the example that would be the following array objects (only two out of four are shown here):
For each of the mitigations per (Sub-)Technique, we’d love to present the mitigation name associated with it. If you look closely to the objects above, there’s nowhere a mitigation name to be found. According to the webpage, we should be looking at M1051 Update Software and M1032 Multi-Factor Authentication respectively.
It turns out these are defined in course-of-action type objects. So, let’s take a look at the first source_ref-value pairs from the screenshots above.
Now we have the information elements we were expecting. The external_id-value pair is representing the mitigation ID, the url-value pair the webpage for this mitigation, and the name-value pair providing a human-readable mitigation name.
Notice that the description-value pair is rather limited. The description from the previous object is more detailed and relevant to the Sub-Technique at hand.
For each mitigation related to the treated (Sub-)Techniques, we have the following information available:
And for each course of action:
We essentially construct an overview based on MITRE ATT&CK®’s website.
The CIS Controls with MITRE ATT&CK® mapping provided by the CIS Controls website, provides a means to include the CIS Controls per identified mitigation. This would allow for a security architect or responsible to demonstrate which CIS Controls would be applied by properly implementing the mitigation.
Below depicts an extract of this complete Excel workbook.
Some caveats are applicable. The mapping by the Center of Internet Security is performed against MITRE ATT&CK® v8.2, whereas at the time of writing MITRE ATT&CK® itself is at v12.1. Also, our use-case does not yet require the CIS Controls description. We opted for generating and using a stripped-down version of the original Excel workbook. After a couple of iterations, we established a mapping against MITRE ATT&CK® v12.1 and generated a JSON STIX alike file containing the same information.
Digging a little bit around, one may find a very similar project from the Center of Threat Informed Defense tackling the mapping with NIST 800-53 Rev 4 and Rev 5. As this mapping is also provided as a JSON STIX file, the next natural step was to incorporate this option as well. At the time of writing, the mapping was performed against MITRE ATT&CK® v10.
We will not dive deeper into the data structure of the CIS Controls and NIST 800-53 controls mapping but will continue addressing another portion of available information in the MITRE ATT&CK® JSON file.
We use a similar approach to collect all related detection information tied to identified ATT&CK® (Sub-)Techniques.
We pivot from the attack-pattern GUID from before but look for the relationship_type with a value of detects.
Only one result of the two is shown here.
As you’ll notice, the construction of the value for source_ref is slightly different and is no longer indicating a course-of-action, but a x-mitre-data-component. The description-value pair is useful as it is the most specific description available for the combination of the (Sub-)Technique with this particular detection.
The following information is now available to compose the information for the detections.
Let’s search for objects with a type-x-mitre-data-component pair and an id-value pair with the x-mitre-data-component ID.
As with the results for the mitigations based on the attack-pattern relation, there’s a name defined and a generic description is available. However, there are no detection ID nor detection data sources defined.
The list of available information is expanded with:
Then we look up the objects with type-x-mitre-data-source value pairs and id-value pair with the x_mitre_data_source_ref.
This provides the last elements we wanted to collect:
This is the last part we addressed from the MITRE webpage.
Notice that the previously mentioned x_mitre_collection_layers are not displayed on the webpage for the (Sub-)Technique. We need to open up the relevant webpage for the detection.
The OSSEM-DM JSON file is not STIX structured and is fairly easier to map to the set of identified MITRE ATT&CK® (Sub-)Techniques.
An extract from this JSON file for one of the T1110.001 mappings is shown below.
As with the data structure of the CIS Controls and NIST 800-53 Rev 5 mappings, we’ll not dive deeper, yet from the example given, the following fields may require your attention: name, event_id, event_platform, audit_category, audit_sub_category, channel, log_source, and filter_in to establish the required information for detections.
As a last addition, let’s take a look at the Atomic Red Team™ library. From the website’s FAQ, it explains the following “[..] a library of simple tests that every security team can execute to test their controls. Tests are focused, have few dependencies, and are defined in a structured format that can be used by automation frameworks.” There are a couple of JSON Navigator Layers available at the Github project source, the one chosen was in atomics/Indexes to basically parse the file and filter for the currently existing tests. No other information is collected.
Now we’ve covered the data structure of the most important data source, the ATT&CK® STIX JSON file. This enables us to pivot against the other available data sources. We’ve chosen for the CIS Controls, OSSEM-DM and Atomic Red Team™ because of its available resources, community support and maintenance.
We’re now able to automate the process now we have assembled all information relevant to generate additional recommendations based on a set of identified MITRE ATT&CK® (Sub-)Techniques and know where to find the information.
A Powershell module, AttackIrReporting.psm, and a Python script, AttackIrReporting.py, are available on Github to generate the set of Word or txt documents covering an introduction to the observed set of ATT&CK® (Sub-)Techniques, an overview of the associated mitigations and linked CIS Controls and/or NIST 800-53 controls, an overview of the associated detections, mapped with the OSSEM-DM, and an initial mapping with the available Atomic Red Team test for single focused validation purposes. It should not stop there however as other types of assessments may provide a set of identified ATT&CK® (Sub-)Techniques from which the module builds upon.
A word of caution is at its place here. The generation of the mitigations and detections should be considered as complementary to what an analyst has identified as recommendations already during their investigation. On top of this, the generation may produce a vast number of additional recommendations, which may overwhelm the intended audience. A reduced, yet not necessarily simplified, list is then warranted as to make it feasible for the intended audience. At the same time, the validations only provide focused tests and it is worth noting that a chain of tests provides a better reflection of how activities happen leading up to the incident.
From the identification of a set of ATT&CK® (Sub-)Techniques from the previous blog post, we are now able to take this one step further: generate in an automated manner a set of documents containing the information from the ATT&CK® knowledge base, extend this with CIS Controls and NIST 800-53 coverage, and map to the OSSEM-DM and Atomic Red Team available data sources.
The decomposition of the JSON data structure allows to collect other data fields that were not used for this specific use case.
In the next blog post, we will be constructing two possible visualisations building from the set of identified ATT&CK® (Sub-)Techniques.
