TIBER stands for Threat Intelligence-Based Ethical Red Teaming.
In a nutshell, what differentiates a TIBER-DK test from a typical Red Team (RT) test is that the RT has to make it seem as if attacks are performed by one or more specific threat actors.
HUH?
Imagine you as a chef are used to cooking Italian food, and suddenly are tasked with cooking French food, to make it seem as if there is a French chef in the kitchen.
It's still cooking. Many aspects of both are the same, but yet different.
WHY?
The fundamental idea is that *if* the tested institution (the target of the TIBER-DK test), has to be resilient against attacks from specific threat actors, then the tested institution must be exposed to those kinds of attacks to check if they actually are resilient or not.
HOW?
In order for the RT to mimic a specific threat actor, the RT must have a deep understanding of how the specific threat actor works, for the imitation to appear real.
Knowledge about how specific threat actors work is part of what is known as Threat Intelligence (TI).
THREAT INTELLIGENCE COLLECTION
In a TIBER-DK test, TI is collected by a TI provider who will help the RT provider understand the specific threat actor. This job is crucial for the TIBER-DK test to provide value beyond a regular RT test.
SOURCES OF TI
Data on threat actors is compiled from intrusions where it has been possible to attribute the intrusion to the specific threat actor.
This means that all publicly available information is, in presumably most cases, the result of operations where the threat actors were detected. And since remaining undetected is usually a top priority of attackers, this means that all data we have is from when they messed up, in some sense.
To put it bluntly, this means that a TIBER-DK test is the reenactment of Tools, Tactics and Procedures (TTPs) of an adversary who failed in some form, and therefore not an enactment of the adversary's true potential, assuming they also, at least sometimes, succeed in remaining hidden and are not detected. We simply cannot reenact what we do not know.
Of course, remaining completely undetected is not a top priority of all threat actors, as the nature of certain kinds of attacks are not stealthy, e.g. ransomware. That being said, threat actors should take care to sustain their Operational Security (OPSEC) to heighten their chances of success in future operations, and ultimately not get caught.
For TI providers to heighten their understanding of threat actors beyond public information would presumably be possible by cooperating with governmental intelligence communities, since such organizations are among the few with resources and legal possibilities to perform the targeted surveillance required to understand relevant threat actors on a deeper level.
TIBER-EU, which TIBER-DK builds upon, provides hints of collaboration between governmental intelligence communities and commercial TI providers:
"The idea of TIBER-EU is to bring together the best available governmental and/or commercial threat intelligence, tailored to the business model and operations of a particular entity, to set up credible scenarios mimicking the key potential attackers and the attack types they would deploy"
TIBER-EU does mention that TI providers employing multi-disciplinary intelligence-gathering are better able to gather certain types of intelligence:
"The threat intelligence market contains TI providers which employ a variety of intelligence-gathering disciplines. TI providers that use both OSINT (open source intelligence derived overtly from publicly available sources) and HUMINT (intelligence derived overtly or covertly from human sources/social engineering) are better able to gather intelligence relating to covert groups such as organised criminals compared with those that use OSINT only."
THREAT SCENARIOS
In addition to providing information on specific threat actors that are most likely to target the tested institution, TI providers must also provide the RT provider with so-called threat scenarios, that describe likely avenues of attack that the specific threat actors are likely to take, if they do target the tested institution.
The TIBER-EU framework specifies that:
"Creating accurate and realistic threat intelligence is a complex activity. This means that the TI provider must have adequate knowledge of the threat actors, their motives and their skills and TTPs, as well an understanding of how the core elements of the financial system interact and operate. In addition, the TI provider must have a good insight into the targeted entity. It needs to know for example: what the target's critical functions are; how the target operates; who the crucial employees are and whether they are "usable" for the attack; and what the target's vulnerabilities are."
For the TI provider to gather this kind of understanding requires significant reconnaissance of the tested institution, as well as a deep understanding of its internal workings. The TIBER-EU framework requires just that:
"to make intelligence gathering as efficient as possible given the time and resource constraints, and to ensure the intelligence is relevant to the scope and the entity's business, the TI provider should seek from the entity and be provided with:
- a business and technical overview of each CF-supporting system in scope;
- the current threat assessment and/or threat register;
- examples of recent attacks."
In traditional RT tests, this work of mapping out the internal workings, as well as vulnerabilities of the tested institute is performed by the RT itself.
This not only requires close collaboration between the TI provider and the tested institution, but also between the TI provider and the RT provider, as the RT provider must gain a deep understanding of the collected intelligence, in order to provide value of sufficient quality.
RT COMPETENCES
Hacking is in the vast majority of cases non-trivial, and cyber security professionals typically specialize in select areas, in favor of others.
As it is the responsibility of the RT provider to reenact specific threat actors, the RT provider should ensure that the team members of the RT are sufficiently competent to do so.
Meeting such requirements may pose problematic, as the chosen threat actor to mimic is not known by the time the RT provider is offered to take part in the TIBER-DK test.
There may be TTPs that are unfamiliar to the RT and therefore require more time in order to deliver reenactment of such TTPs at a satisfactory level of quality.
Therefore, the RT provider may to some extent be at a disadvantage when taking part in a TIBER-DK test when comparing with a traditional RT test, as they may not themselves pick and choose the TTPs to use.
CONCLUSION
The fundamental idea behind TIBER-DK is, in my view, really great, as it can potentially provide great additional value as compared to a traditional RT test.
As of the time of this writing we have only seen targeted TI based on OSINT in TIBER-DK. To increase the value of TIBER-DK engagements, I would additionally like to see the use of intelligence gathering disciplines beyond OSINT, as well as involvement from governmental intelligence communities and a tighter collaboration between the tested institution and the TI provider.
Whenever evaluating whether or not to perform a TIBER-DK test, I would recommend to first evaluate if the potential threat actors to mimic actually are significantly different in regard to their TTPs than from what would be expected from the RT provider, if tasked to conduct a typical RT test.
If that is not the case, I fear the overhead of the TIBER-DK framework as opposed to a typical RT test is of lesser value, in terms of execution of the test.