Welcome to this journey of blog posts which will be a series on implementations of MITRE ATT&CK for Incident Response Teams. Each post aims to build on top of the previous one. As for any roadmap, application of the several steps depends heavily on the experience, maturity, and ability of the intended environment.

The rationale for the series was to adopt MITRE ATT&CK® into the recommendations provided to customers having faced an incident and lay the foundation of further expansion of the use of MITRE ATT&CK in other use cases and services Check Point Incident Response Team (CPIRT) is providing.

This is as such complementary to the MITRE ATT&CK coverage Check Point’s solutions are providing and to how Check Point is leveraging the framework.

Although the CPIRT recommendations are expressed as per reporting to the customer and as such part of the post-incident activities, they tie into the preparation phase of the incident response cycle as well.

None of the blog posts claims to provide the sole solution for the problem that was to be solved. The proposed solutions are potentially only one way of approaching the issue but could be applicable outside of the CPIRT environment.

MITRE ATT&CK as a common vocabulary in reporting

In this first blog post, we will present a possible initial step in the adoption of MITRE ATT&CK into the reporting activities of an Incident Response Team. Therefore MITRE ATT&CK will be introduced, followed by the problem statement, a proposed practical solution, and potential use cases.

MITRE ATT&CK is a knowledge base of adversary TTPs (Tactics, Techniques, and Procedures) based on real-world observations. One cannot talk about TTPs without referring to David Bianco’s Pyramid of Pain. A simplified conclusion is that TTPs are not only tough for the defender to get a grip on, but they’re equally hard for the perpetrators to change, inherently providing the best of options for a defender to implement Courses of Action – Deny, Disrupt, Degrade, Deceive, or Destroy – affecting the perpetrator’s goals.

At the top-level ATT&CK describes the Tactics. As per MITRE, Tactics represent the “why” of an ATT&CK technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. For example, an adversary may want to achieve credential access.

The levels below the Tactics are the (Sub-)Techniques. Techniques represent “how” an adversary achieves a tactical goal by performing an action. For example, an adversary may dump credentials to achieve credential access. Sub-Techniques are a more specific description of the adversarial behaviour used to achieve a goal. They describe behaviour at a lower level than a technique. For example, an adversary may dump credentials by accessing the Local Security Authority (LSA) Secrets.

After conducting a root cause analysis of an incident that has occurred, Incident Response Teams present a final report to the customer. The report will lay out the activities performed by the perpetrator(s) based on the results from the investigation with the available data at hand.

The descriptions of these activities are usually performed in a natural language and is not standardised, let alone structured in the sense that it could be easily ingested in any automated pipeline if one wishes to do so. On top of this, messages – recommendations in this context – are never conveyed the same way as it is bound to the individual and even point in time, nor is there 0% uncertainty the audience interprets the messages as intended. This may cause the customer to wrongly understand what may have happened and may lead to drawing wrong conclusions as to what to do next.

There is, however, a way to at least try and use a smaller finite set of common techniques used by the perpetrators. As per introduction, MITRE ATT&CK does provide such a common knowledge base.

A practical implementation could look like this: another individual, be it team member, supervisor or even someone from another team in your organisation – think CTI Analyst, Pentester, Researcher, … – screens the report and identifies the sentences or parts thereof which indicates the activities performed by the perpetrator. These are then transformed into the relevant (sub)techniques from the MITRE ATT&CK framework. The results should be cross-checked with the writer of the report.

Below is a snippet from a report as an example.

“Due to many of the organizations internet facing assets appearing to be susceptible to SSH brute forcing, it is hypothesized a SSH brute forcing campaign has successfully accessed one of those public facing hosts and laterally moved through the environment installing malicious software.”

This short paragraph contains the following candidates to be transformed into (Sub-)Techniques.

“Due to many of the organizations internet facing assets appearing to be susceptible to SSH brute forcing, it is hypothesized a SSH brute forcing campaign has successfully accessed one of those public facing hosts and laterally moved through the environment installing malicious software.”

Addressing each identified parts of the phrase, the following table can be established.

SSH T1021.004
Brute forcing T1110
Accessed one of those public facing hosts T1133
Installing malicious software TA0040

It is worth noting that the transformation of the identified parts into MITRE ATT&CK TTPs is also prone to variations depending on the individual screening the report. It is therefore important to verify the results with the writer of the report to reduce the occurrences of incorrect transformations.

Yet some of the transformation may lead to discussions and require clarification to get to a result. For example, installing malicious software has not a relevant (Sub-)Technique but has several Tactics where it may be relevant. The one chosen here was the most appropriate, given the details on how that software was then used in the environment.

Be mindful that not all actions or activities must nor will have a representation in ATT&CK. ATT&CK was built on actions that were observed and reported and thus provided enough context to embody the (Sub-)Technique into ATT&CK. In other words: ATT&CK is not complete.

Finally, a list of ATT&CK Tactics and (Sub-)Techniques is by no means a replacement of any of the parts of a report written by an analyst.

It comes to no surprise that the resulting table is only a steppingstone to additional information within MITRE ATT&CK. We will cover how to incorporate the provided mitigations and detections into the reporting in upcoming blog posts.

While the proposed solution and implementation is primarily focused on providing a standardised transformation of the recommendations in a post-incident Incident Response report, the approach is applicable to any source of unstructured information, be it news coverages, blog posts, security advisories, etc …

Additional use cases may include:

  • Communicating in a coherent manner through the consistent use of well-defined terminology.
  • Exchanging structured information with other teams such as Cyber Threat Intelligence.
  • Performing incident observations, and statistical reporting in the context of VERIS for example.
  • Building and executing atomic tests, micro emulations or full attack scenario emulations challenging and verifying the implemented security controls, mitigations, and/or detections in the context of purple teaming exercises or continuous security validations.

Establishing hypothesis a perpetrator has been using the identified (Sub-)Techniques in your environment and performing a threat hunt to test the hypothesis. This would obviously stem from any source other than the actual incident.

Conclusion

We covered a rather simple initial step to start adopting MITRE ATT&CK into reporting, which is by coincidence also applicable for any source of reporting that does not include MITRE ATT&CK references yet.

The transformation into ATT&CK Tactics and (Sub-)Techniques will require some effort but demonstrates its immediate benefits in communicating with the customer and its long-term benefits when considering additional internal and external use cases.

References

You may also like