Thread by @malcomvetter

Thought of the Day: It's actually possible to cause HARM with a #redteam exercise. Read the thread before you jump to conclusions.

There are many different "goals" that stakeholders of a #redteam exercise may expect (and they probably only latch onto one of them, not even aware of the others):
- Program/Posture Assessment
- Controls Validation
- Adversary Simulation
- Adversary Emulation ^not the same^

In a healthy red team program, you'll have stakeholders from each "camp" expecting each of those items to be represented. A SOC will want controls validation, for instance, but may not care about a Posture Assessment (i.e. this business unit has a C+ security program).

Clarification: Simulation (to me) means looking like a random (fake) adversary, while Emulation means looking like a specific (real) adversary. Different goals, both can be valid.

So, you may have up to 4 different "masters" to appease at any point in time. Keep them in balance & carefully consider how satisfying one may affect the other.

For example: suppose you have a business unit that everyone expects has a weaker security posture. Likely the best reason for the exercise is to give them a wake-up call in a safe way.

(I liken this to The Game by Michael Douglas)
imdb.com/title/tt011917…

You're not going to play cat/mouse with that weaker program. They might have ZERO detection/response capabilities and the primary benefit is to show them WHY that is important.

Compared to a strong program, where cat/mouse games and even specific adversary emulation is valuable.

So, suppose that weaker business unit has SOME detection capabilities, but limited. There's some value to "shake up the TTPs" and do something random (adversary simulation).

However, if that random collection of TTPs means a lot of new variables that can lead to #blueteam being alerted to your presence and initiating the hunt, it could actually result in a premature closure of the exercise, which may damage the weaker program's Posture Assessment.

If the debrief ends up being: "We tried something new, it didn't work, blue caught us, the business was aware of our presence, so we ended the exercise,"

Then the business may think: "Our security is great, we don't need to change a thing. De-prioritize security projects."

This could be AMAZINGLY detrimental to that business. What is far more important would be to find balance in the amount of new TTPs in such an exercise, & #redteam to have redundancies for redundancies. We want #redteam to achieve objectives in this case...

...because if #redteam achieves objectives, it will overcome Confirmation Bias and Normalcy Bias within that business unit, and help shift incentives to comply with security policy goals.

In that scenario (not in all scenarios), if blue catches red, it helps blue a little, but hurts the business unit stakeholders a lot, because there wasn't enough time to properly perform some sort of a Security Posture Assessment.

Like pretty much everything, balance with #redteam goals, tactics, and strategies is the key to improving a security program.

(And yes, red teams are defenders first.)

Re: Confirmation/Normalcy Bias ...

I can tell an IT Exec in advance roughly how we will breach them. Won't matter. Human nature & these biases will result in "that won't happen to us" mentality.

If we actually DO IT first, then the biases are eliminated (mostly).