Our colleagues from the Center of expertise at Defensys use MITRE quite often during our PoC and implementation projects. And we would like to share our thoughts about these very MITRE matrices and their application in this article.
Recently, we hear more and more often that developers actively use MITRE methodology when developing various cyber security products. In MITRE terms, these databases are called matrices, and the number of projects where they are used is constantly growing.
At the same time, we have been wondering for quite a long time now: what does MITRE support give to vendors and end users in the end? Why do we need it all, if we already have, say, some kind of “smart” SIEM or a specialist who constantly works with it?
Our article is designed to get to the bottom of these questions. And to begin with, we suggest to remember what MITREs are.
MITRE is an American non-profit organization that manages systems engineering research and development centers at the U.S. federal government and local government levels.
And then there’s MITRE, a manufacturer of sports equipment.
What is MITRE famous for?
MITRE ATT&CK
First of all, it is the MITRE ATT&CK matrix, one of the most popular methodologies among information security specialists and simultaneously the public knowledge base, where the well-known data about attackers, tactics and techniques of targeted attacks used by various cyber-groups are gathered. This data is presented in the form of a matrix that can be used to see how attackers penetrate companies’ infrastructure, how they gain a foothold in it, what tricks they take to avoid detection, and so on.
This is what the MITRE ATT&CK matrix looks like: tactics followed by techniques, and then the clarification of exactly how attackers will achieve their goals.
The stages of attack development and tactics of their implementation are what the attacker’s goals are at the moment.
In turn, tactics are divided into techniques, i.e., specifying the ways how the attacker achieves those goals.
Here, for example, we can see the tactic of privilege escalation through scheduled tasks are at the input.
MITRE D3FEND
Let us now refresh our knowledge on MITRE D3FEND, another public knowledge base (matrix), which contains a structured set of techniques – countermeasures.
MITRE D3FEND consists of tactics, categories, and techniques.
The top level of the matrix, the tactics, contains the countermeasure domains, of which there are a total of five:
The domains are divided into categories that specify them. For example, if the goal is to isolate or contain an attacker, we need to either isolate the execution environment or isolate the network.
Techniques in D3FEND, as in ATT&CK, are the way to achieve the goal. But the detailing of the technique (subclasses), i.e. its refinement, plays a very important role here.
Suppose we want to implement the detect countermeasure, more specifically, the monitoring of the platform. We will do it by monitoring the operating system. What exactly are we monitoring? Local accounts.
MITRE ENGAGE
Let us move on to a freshly updated matrix – MITRE ENGAGE, the spiritual successor of MITRE SHIELD.
MITRE ENGAGE was created to help commercial companies, governments, vendors, communities, and others negotiate to achieve certain strategic goals.
MITRE ENGAGE consists of 5 big goals:
The big goals, in turn, are divided into 2 groups:
- Goals for managing cyber security within the organization – Prepare and Understand;
- Goals aimed at countering the attacker – Expose, Affect, and Elicit.
To achieve one of the strategic goals, the next level of the matrix comes to our aid – approaches.
Suppose that our goal is to elicit the attacker. Among the available approaches, as an example, we will focus on the option of reassurance. To do this, it is possible to lure the attacker with the help of decoys into a pre-deployed fake infrastructure. Using realistic traps, we will try to convince him that this infrastructure is real. And eventually, force the attacker to leave as many traces in it as possible. And then all that’s left is a good study of his behavior. Actually, in our opinion, that’s the description of any Deception platform and its implementation goal.
The approaches have been dealt with. They are followed by activities, that is, specific actions used to achieve the goal within the framework of the set approach or method.
To clarify, let us go back to our attacker again – having studied his behavior, we need to prevent him somehow. How? By isolating. To do this, we can, for example, use linking with D3FEND.
MITRE RAMPAGE
Now that we have remembered the basic matrices, let us have a MITRE RAMPAGE and look at how all the elements of this puzzle come together:
Let us start with ENGAGE.
Let us imagine that our goal of countering attackers is to expose, by collecting information about system activity. The collection is necessary to detect an attacker at the moment of his vulnerability. Many people know that cybercriminals are most vulnerable when they are making some actions because they leave artifacts. These are the ones that can be detected by monitoring activities: some changes in the system, the triggers pulled during these changes, and so on down the list.
Now with MITRE ATT&CK through the very same vulnerability, we track the attacker during the persistence.
How does persistence happen? By creating a task in the task scheduler, followed by a logical connection to MITRE D3FEND. Simply put, there is a digital artifact: the name of the created task and a task log. And then we can capture the attacker’s activity through detection processes. Accordingly, we analyze the scheduled tasks at the platform monitoring level and try to detect them.
Next, I will tell you how to use MITRE matrices.
An example of detection
Let us move briefly to the world of the pink ponies, where everyone has agreed with each other, vendors have added MITRE support to their products, the content of security systems is constantly monitored and a comparison of detection rules and ATT&CK techniques is supported.
Everything looks pretty cool in the picture. Here, all the detection information is passed to the response layer in the SOAR system. Then there is an enrichment of tactics so that at the next stage it is easier to find suitable countermeasures from D3FEND, a Mitigation section of the ATT&CK matrix, or from other sources of external expertise, such as ATC RE&CT. All seems to be fine, idyllic.
Now let us go back to the real world.
What do we actually have?
Not all detection tools know how to enrich themselves with techniques within the framework of actuation. Even at the SOAR stage, an incoming cyber security event needs to be further enriched at the aggregate object level, which already has many events and several techniques, but no source events. There is only a finite correlation rule. Yes, it is somewhat painful, sometimes unnatural, and should not be done that way. But we have what we have. And just like last time in the process: we apply countermeasures and send them out to respond.
Below we put on our vendor’s cap and give you an example from our practice, which also helps to answer the question that arises “why use MITRE when we have SIEM?”
We take off the vendor’s cap and let us now get back to the main question we asked at the beginning of this article: why do vendors support MITRE?
The answer is simple: to speak the same language with all participants of the cyber security market. Is this helpful? In our opinion, yes. Since it allows for relatively bloodlessly introduce global expertise into local SOC processes and speaking the same language with that global expertise.
And if we are already “speaking the same language” with the entire cybersecurity community, then, most likely, we will be able to formalize both our internal approaches to the creation and improvement of both detection and response techniques.
And what’s without a blot on the landscape?
As with any external expertise, the MITRE matrices are not a panacea but only a way to reach an agreement. And for that expertise to start benefiting you, you will also need a “rasp-file” and a decent amount of time to adapt to your processes and internal systems.
In summary, the conclusions are as follows:
- Vendor support for MITRE is great and allows SOC to incorporate a huge layer of expertise into their processes quite easily;
- MITRE allows formalizing approaches to creating/improving detection/response techniques;
- MITRE helps make SOC processes more mature;
- MITRE matrices, like any external expertise, require adaptation and are not a panacea.