How to Fail at “Know Your Enemy”?!

As a security professional, you’ve heard the slogan “Know Your Enemy” more than a few times in your career. Armchair security strategists love to mindlessly quote Sun Tzu such as by uttering things like “If you know the enemy and know yourself, you need not fear the result of a hundred battles” (and then they get owned by unpatched struts or something). There was even a whole book called “Know Your Enemy”, years ago.

But you know what? Much of our security today does not rely on you knowing your enemy all that much! Admittedly, some tools rely on you hoping that your vendor knows the enemy. Other tools rely on some generic knowledge of what a generic enemy may do to a generic target, the proverbial spherical horse in a vacuum. And of course there are parts of the security stack that in theory should not rely on anybody knowing the enemy (like, say, application whitelisting and other security hygiene measures).

Thus, in my opinion, there is not a lot of “knowing your enemy” going on in our beloved realm of “cyber.”

Furthermore, the capacity to know something about the enemy has outstripped our ability to distill such knowledge down to meaningful detections and decisions. Much of the existing tech doesn’t allow us to leverage “knowledge of our enemy” (such as TTPs) in a way that actually translates or maps to realistic threat scenarios. Or, at least such “translation” is not easy and/or not accurate and/or “lossy.”

Let’s ponder it — and I promise there would be a practical point in the end.

So, two questions (or, three, depending how you count):

1. Is this really the case that we don’t focus enough on “knowing the enemy”?
2. Is such shortage of focus actually a problem, and so is this something we need to change? [A skeptic will of course add “…. and, in fact, can realistically change”]

A few years ago, there was a decent uptick in “intelligence-driven” this and that. And there has been, of course, an uptick in threat intel (TI) usage, at least tactical / technical threat intel i.e. indicators (bad IPs, hashes, domains, etc). However, as I alluded many times, checking a list of bad IP addresses is not really “knowing” your enemy. Because: “here is all I know about the enemy, they come from 127.0.0.1 every night” won’t get you very far. In fact, many observations of past badness — the indicators — may in fact be essentially random and present no useful knowledge about the future badness or about the nature of the enemy, their intents and capabilities. This is especially true for highly fragile indicators like IPs and domains.

At the same time, a surge in technologies ostensibly designed to learn more about the enemy came into vogue: honeypots and deception technology in general for example. Furthermore, in the same time frame there were a lot of threat reports published that focus on some particular juicy enemies like some goddamned fat panda, APT1337, or whatever GOSSIPGIRL.

Still, somehow I don’t feel that we live in a golden age of “know your enemy.” Exciting threat reports don’t make you secure unless …

a/ the report has enough details for anybody to actually do something operationally, and

b/ you are targeted by the particular actor described, and

c/ you are willing and able to take action upon reading the report (otherwise, you just collect data, not being intelligent about it)

Deception remains a niche and is often used operationally as a glorified IDS, not to increase your knowledge of the enemy. Similarly, strategic threat intel never spread from the 1%-ers down, if not the 0.1%-ers. Attribution largely remains in the realm of comedy, or perhaps occasionally drama :-). Back in the day, I did talk about the process of threat assessment, and guess what? Many talk about it, some ignore it completely — and only very few actually seem to practice it.

In fact, it is clear to see that many security problems, whether in legacy environments or in the cloud, stem from the proverbial not doing “the basics” and not from a lack of understanding of our adversaries. Security hygiene controls will defeat many of the commodity threats and they will do so with barely any knowledge of the enemy. One can argue that only a very general knowledge of the enemy is needed to defeat commodity threats and that it should be the starting point of every security program. Finally, once you excel at the basics, you don’t actually need to spend as much time responding to simple incidents, and you have time to actually invest in knowing your enemy for real and translating that to practical detections.

So, how much knowledge about the attackers do you actually need for [cyber] defense?

Put differently, how should you mix the investments in defenses that rely on knowing the enemy with those that do not? [BTW, we can also have a side mini-debate about whether defenses such as whitelisting truly do not need any knowledge of what the enemy can do and who they are]

Finally, my useful meta-point is:

• You can (and should) prevent threats (where you can) and it is perfectly fine to do so without knowing your enemy. If you have zero trust access, nobody can abuse your VPN (because, hey, you ain’t got one). To borrow a fantasy metaphor, high walls and deep moats repel all kinds (except those that fly, I guess), however …
• … my view is that to reliably detect, you absolutely must know your enemy. Detecting an unknown threat is exciting to discuss, but my experience suggests that it probably won’t work for most people (and, yes, deception tools may help here more than other types, but it does not mean that it will happen for you in real life)

So, thoughts?

• Do we need MORE BASICS (and “enemy-agnostic” controls)?
• Do we need MORE KNOW YOUR ENEMY?
• Do we need MORE USE WHAT WE LEARNED ABOUT ENEMY?