In this post I explain the concept of Iterative Defense and The Intruder’s Dilemma (IDTID).
You’ve probably heard the Defender’s Dilemma, which is:
“An attacker only needs to find one weakness while the defender needs to find every one.”
This is pessimistic thinking for the defender and makes it seem like a battle that’s impossible for the defender to win.
Richard Bejtlich introduced the Intruder’s Dilemma where he described it as:
“The defender only needs to detect one of the indicators of the intruder’s presence in order to initiate incident response within the enterprise.”
What IDTID does is expand on this, to show that the defender actually becomes stronger over time as the attacker fails at more of his attempted attacks. The attacks become more expensive because the attacker keeps burning more TTPs (Tactics, Tools, and Techniques).
This concept has become more relevant today where tools are now available to enable a defender to collect data from systems, apply his own Threat Intelligence to that data, and generate his own Threat Intelligence from old data to apply to new data. This is the Iterative Defense part of the name.
To explain, let’s look at the common attacker procedure of bypassing anti-virus (AV) software shown in Figure 1.
An attacker tests his malware against AV and modifies it until it’s no longer detected. Then he sends it to the victim. An attacker can do this because AV products are readily accessible and for the same product, everyone get’s the same signatures.
But what if the attacker can’t test this locally? What if the only way he can test his attack, is to actually perform the attack?
If the defender detects and blocks the attack, he will then have a copy of that attack artifact. The defender can then analyze this attack and generate more signatures for it. The attacker then needs to modify even more things about his attack to avoid being caught. Every time the attacker attacks, the defender obtains more ways of detecting him.
Example scenario
Let’s walk through a simple example, where we have a defender with only two signatures (ie. Threat Intelligence, IOCs, forensic artifacts, etc.) as shown in Figure 2. The defender is looking for attackers that use a process named evil.exe
and/or use the IP address 2.2.2.2
.
An attacker comes along and somehow ends up attempting to spawn a process named evil.exe
, which the defender detects and blocks as shown in Figure 3.
After the attack, the defender does a quick analysis on evil.exe
, and creates signatures for the IP of the callback server and MD5 hash of the file as shown in Figure 4.
Our attacker decides he was somehow caught (doesn’t know how), and decides to try again with a new filename (bad.exe
).
This time our defender doesn’t have a signature for the new filename, but does have one for the IP address and file hash.
After the second attack attempt, our defender looks more closely at the samples he acquired and notices both of them use the same mutex and user-agent string, so he adds that to his signature database along with the new filename.
The attacker is frustrated, and decides this target is going to take some work, so he creates a new malware and sets up a new callback server. He’s really trying to not get caught this time, so he attacks again with his whole new set-up. Except this time the advanced signatures of the defender caught him!
Our defender adds the new signatures to his database. The attacker will now need to do everything he did before, plus more!
From the defender’s perspective, this is the iterative process he can take to get better at blocking this attacker and make it more difficult and more expensive for the attacker.
From the attacker’s perspective, he doesn’t know how he is being caught, so he has to completely change all his attack TTPs, but even those might be caught by one or more signatures.
Conclusion
This is obviously a simple example where more advanced signatures would be involved. This also requires capabilities that not many defender’s today have, but new open-source projects being released by tech companies are making is possible to create this iterative defense process. These tools include:
- GRR from Google
- osquery from Facebook
- Mozdef and MIG from Mozilla
- ElastAlert and osxcollector from Yelp
- FIDO from Netflix
An implentation of this concept using open-source projects is presented in a follow-up post titled Iterative Defense Architecture.
Although the news is populated by advanced threats and compromised businesses, there are ways to gain the upper-hand against attackers and this is becoming less expensive.