Scoping a Red Team: Objectives and Rules of Engagement

Two documents decide whether a red team is worth buying. The objective decides whether the result means anything; the rules of engagement decide whether the exercise is survivable for everyone involved.

Writing an objective that means something

An objective is specific, singular, and unambiguous in outcome. Someone should be able to say afterwards whether it was achieved without an argument.

Good: obtain a copy of the customer database. Execute a transaction in the payment system. Reach the cardholder environment from outside it. Gain domain administrator.

Not objectives: "assess our security posture", "test our defences", "see how far you get". These are requests for a penetration test with a more expensive name, and they produce reports nobody can act on because nothing was being proven.

The test of a good objective is whether its achievement would alarm a board. If reaching it would prompt a shrug, the exercise will too.

The rules of engagement

Everything the team may and may not do, written down before anyone starts.

What is in scope

Which entities, which countries, which subsidiaries. Groups with shared services get this wrong most often: a route through a subsidiary is realistic and may be outside the authorisation you actually hold.

Which techniques are permitted

Phishing, physical entry, telephone pretexting, exploitation of exposed services, supplier routes. Each is a decision. Anything affecting availability is normally excluded outright, and destructive actions always are — a team proving database access retrieves a row, not the table.

What is untouchable

Name the systems that must not be interfered with under any circumstances: safety systems, clinical systems, trading platforms during market hours, anything where a mistake is measured in something other than money.

Trusted agents

The two or three people who know. Their job is to hold the authorisation, answer the phone at any hour, and stop the exercise if it needs stopping. Choose people who will actually be reachable — a trusted agent on holiday is the same as no trusted agent.

Stop conditions

What ends the engagement early. The objective achieved. A real incident occurring in parallel — worth stating explicitly, because a genuine intrusion during a red team is confusing in exactly the wrong moment. Anything affecting customers. A team member detained.

Deconfliction

How the trusted agents establish, quickly, whether something odd is the red team or an actual attacker. Usually a phone number and a code word. Without it, your incident response spends a night on an exercise you paid for — or, worse, dismisses a real intrusion as the exercise.

The authorisation itself

A signed document naming the systems, the dates, the permitted techniques and the signatory, held by both sides before work starts. Where physical entry is in scope, each tester carries a copy along with a name and number that will be answered at three in the morning.

Where any system is not yours — a supplier, a shared building, a hosted platform — their permission is separate and also needs to exist in writing. Being their customer does not authorise testing them.

The scoping question worth asking yourself

Before writing any of it: what would we do differently depending on the result?

If the honest answer is "nothing, but we need the report", buy the cheaper exercise. If it is "we would rebuild our detection", buy a purple team first and the red team afterwards, in that order.