Don't Fixate on Controls

Here’s a quick chess question—one you don’t need to be an expert to answer, so please try it even if you’ve barely played the game: On the board below, is that a strong or a weak position for the piece to be in?

If you’re like me, your brain will spin hard for a second or so trying to see the answer, then realize that it’s a ridiculous question. ‘Strength’ in chess emerges at the level of the entire board, not individual pieces, so the question is meaningless. It’s like asking “Is the Ten of Hearts a strong poker card?” without mentioning the other cards in the hand you’re holding.

Further, chess (like poker) is an adversarial game, so even if you did know the disposition of the rest of your black pieces:

and could get some sense of its internal coherence, seeing only one side means you still don’t have any clue about ‘winning’ vs ‘losing’. Even with the ‘complete’ picture of the Black pieces in this diagram, Black could be in an invincible position, or a hopeless one, depending on the White pieces you haven’t been shown.[1]

Talking Information Security

The situation in Information Security is somewhat similar. Regulations, standards, and the like are essentially lists of controls, so compliance-centric thinking is just another way of saying ‘control-centric’. Further, many of those who want to be risk-centric do so by identifying and addressing control deficiencies. If you ask them how they made the transition from “Here’s a control deficiency” to “Here’s a risk”, there’s generally a pause, then a grudging admission that it’s really just a judgement call based on the expertise and experience of the person making the call.

The deeper truth, and one that’s never explicitly denied but too-often ignored in practice, is that controls are just one side of an adversarial game, and all your gap analyses, remediation plans, and so on are half-gibberish if you don’t look more formally and more thoroughly at the other player and their pieces. (The ‘other player’ being the whole ecosystem of threat actors out there, including impersonal threat actors like ‘flood’ and ‘power outage’...)

If the threat actor is playing the White chess pieces in this analogy, then their chess moves are the sequential moves they make to actually inflict damage on you, their opponent.

That is pretty obvious, but a key point here that gets ignored too often is that attacks, like chess games, are not ‘atomic’ in the sense of being a single indivisible thing. Attacks are in fact a sequence of moves (many of which are exploratory rather than definitive), and it’s only in that context that a control’s efficacy or strength can even be defined, let alone measured.

So, for example, saying “This server is unpatched!” might be true, but it doesn't answer the ‘So what?’ question. What you’re really saying is just: “Here’s a control deficiency that could credibly constitute one link in some chain of events that collectively form a successful attack.”

That’s a perfectly reasonable thing to say, but it says nothing about criticality or risk: it says nothing (in isolation) about whether or not something needs to be done about it. One organization might have to say, “In our situation, there are high-probability attack paths that exploit that control deficiency (and that’s why we’re hustling to respond)”, while their next-door neighbor might have the identical patching issue, but be able to say, “This control deficiency is minor for us, because the plausible attack paths that pass through this step are all thwarted elsewhere, using other controls. We don't need to do anything.” For example, attackers can’t exploit the patching deficiency if there is no way to interact with the device in question, and can’t steal any data via that patching deficiency if exfiltration is comprehensively risk-managed down.

Summary

What I’m really saying is: Don’t fixate on controls in isolation: they get their significance, and their ‘appropriate level of implementation’ from their context. Controls are measureless and meaningless without a threat model, just as threat models are measureless without a control posture profile, too. As an industry, we need to mature past the point of trying to discuss and manage either in isolation.

My recommendations on this topic are:

1.     Use standards and other control-centric thinking to make sure you aren’t forgetting anything: they’re a good tool to validate the scope of your thinking.

2.     Think of controls in the context of attack paths. You certainly need to break[2] these attack paths somewhere, and preferably in multiple places or ways (as part of defense in depth), but that doesn’t mean that you need to do everything everywhere. For a given proposed/recommended control, if you can’t think of a plausible attack path that would exploit the absence of that control, why are you doing it?

A final point is that this sort of attack-path-centric thinking is also an invaluable communications discipline. If your senior management are properly engaged, they’ll be asking the "So what?" question, and thinking in this way not only ensures you’ve got a good answer, it’ll be an answer that comes pre-packaged in an easily-consumed and constructive way.

 --------------------

 [1] There’s another layer to the above analogy. The chess question is actually doubly idiotic, because the game is won or lost based on the status of the king, and there’s no Black king shown. The Information Security version of that is to do risk management without proper asset tracking and evaluation.

[2] ‘break’ as shorthand for ‘risk-manage down to the point of acceptability, either by reducing the probability or the consequences of the attack path playing out’.