How Is a Red Team Operation Planned? Scope, Objectives and Rules of Engagement

The success of a Red Team operation depends on correct planning long before it depends on the attack tools used or the vulnerabilities found.

Because Red Teaming is not a standard vulnerability scan.

It is a comprehensive cyber attack simulation in which genuine attacker behaviour is reproduced under control and the organisation's cyber security defence is tested both technically and operationally.

For that reason there are critical questions that must be answered before the operation starts:

What is the Red Team's objective?

Which systems will be tested?

Which attack techniques will be permitted?

Will social engineering be allowed?

Are Active Directory attack scenarios in scope?

Will the SOC team be aware of the operation?

Where does the operation stop once critical systems are reached?

If the answers to these questions are not clear, a Red Team engagement that looks technically successful can create unnecessary operational risk for the organisation.

Three elements therefore sit at the foundation of a professional Red Team operation:

The Objective

The Scope

The Rules of Engagement (RoE)

When these three are defined correctly, a Red Team operation can simulate real attacker behaviour while protecting the organisation's business continuity and operational security.

What Is a Red Team Operation?

A Red Team operation is a security engagement that aims to measure an organisation's resilience against attacks by simulating, in a controlled way, the tactics, techniques and procedures (TTPs) that real-world threat actors could use.

In a classic penetration test, the vulnerabilities of a particular system are investigated.

For example;

• a web application,
• an API,
• a mobile application,
• the internal network,
• the external network,
• Active Directory

may be tested within a defined scope.

In a Red Team operation the approach is usually objective-driven.

For example:

Is access to critical finance systems possible through a controlled attack scenario starting from the internet?

or:

Can highly privileged Active Directory accounts be reached from a standard user account?

or indeed:

At which stage can the organisation's SOC and security technologies detect real attacker behaviour?

The first step in planning a Red Team operation is therefore not to list IP addresses, but to define the business objective.

1. The Objective of the Red Team Operation Must Be Defined

Before a Red Team engagement begins, the reason the organisation is carrying it out must be clearly defined.

“Attack us like a hacker and see what you find.”

is not a professional Red Team objective.

Measurable and meaningful objectives should be set instead.

For example:

Can access to the critical payment system be achieved?

Can Domain Admin level be reached from a standard user account?

Can sensitive data be reached through an attack that starts outside the organisation?

Can the SOC team detect the attack?

Can the EDR/XDR and SIEM infrastructure detect the selected MITRE ATT&CK techniques?

Does network segmentation prevent the attacker from performing lateral movement?

These objectives produce measurable results at the end of the operation.

The Red Team can report not only “how many vulnerabilities were found”, but whether the defined objectives were reached.

2. Crown Jewels: What Are the Organisation's Most Critical Assets?

One of the important concepts in Red Team planning is the crown jewels approach.

Crown jewels are the digital assets of highest value to the organisation.

In a financial institution these might be;

payment systems,

SWIFT infrastructure,

customer data,

critical databases.

In a manufacturing company;

ERP systems,

production infrastructure,

OT/ICS systems,

intellectual property data

may be the important ones.

In a technology company;

source code,

CI/CD infrastructure,

Git repositories,

cloud management accounts,

customer data

may be among the critical assets.

The purpose of a Red Team operation is not always to take over these systems.

But whether the attacker can build an attack route that reaches the crown jewels can be tested.

This approach lifts Red Teaming out of pure technical security assessment and connects it directly to business risk.

3. Red Team Scope – How Is the Operation Scope Defined?

The Red Team scope determines which systems and attack surfaces may be assessed during the operation.

If the scope is kept too narrow, building a realistic attack scenario becomes difficult.

If it is left uncontrolled and broad, operational risk increases.

The scope must therefore be clearly documented.

The scope may include, for example;

The internet attack surface

The organisation's domains, subdomains and internet-facing systems.

Web applications and APIs

Applications reachable from the internet or from inside the organisation.

Active Directory

Users, groups, computers, service accounts and permission relationships.

Endpoint systems

Employee computers or designated test devices.

Email infrastructure

Microsoft 365 or other corporate email systems.

Cloud infrastructure

Azure, AWS or other cloud environments.

Network infrastructure

Internal network segments and security controls.

The human factor

Social engineering scenarios, where authorised.

Any of these may be in scope.

The important point here is this:

A Red Team being realistic does not mean it is unlimited.

4. What Are In-Scope and Out-of-Scope?

In professional Red Team engagements, systems are generally split into two main categories:

In-Scope

Systems that may be assessed within the operation.

Out-of-Scope

Systems that must not be tested or interfered with during the operation.

A particular critical database in the production environment may be out of scope, for instance.

The Red Team reaching that system may demonstrate that the operation's objective has been achieved.

But actual data access or modification on the system may not be permitted.

In that case the Red Team proves the access capability and stops the operation at that point.

This can be called the proof of access approach.

The aim is not to cause real damage, but to prove in a controlled way that the damage could be caused.

5. What Are the Rules of Engagement (RoE)?

The Rules of Engagement is the core document defining the rules under which the Red Team operation will be carried out.

It is far more than a technical scope document.

It defines what the Red Team;

may do,

may not do,

which systems it may access,

which attack techniques it may use,

at what point it must stop,

and who it must contact in an emergency.

All of this is set out in advance.

Put another way:

The scope tells us where we may work; the Rules of Engagement tell us how we may work.

6. What Should the Rules of Engagement Contain?

A professional Red Team RoE document may define many topics depending on the nature of the operation.

The operation dates come first among them.

Operation Timing

Between which dates will the Red Team be active?

Will attack simulations be carried out only during working hours?

Are night or weekend operations permitted?

This information is particularly important for evaluating SOC and incident response processes.

Authorised Systems

The;

domains,

IP ranges,

applications,

network segments,

cloud tenants

within scope must be clearly identified.

Prohibited Systems

Critical production systems,

OT/ICS infrastructure,

business-critical applications,

third-party systems

may be explicitly excluded from scope.

Permitted Techniques

Will phishing be allowed?

May credential attacks be used?

May Active Directory attack techniques be applied?

Will Command & Control simulation be permitted?

Will physical security be assessed?

All of these must be determined before the operation.

7. Should Social Engineering Be in the Red Team Scope?

In a significant proportion of real attacks the human factor is part of the attack chain.

Social engineering can therefore be one of the strongest components of a Red Team operation.

But the boundaries of social engineering scenarios must be defined with particular care.

The operation may, for example, consider;

phishing emails,

controlled credential scenarios,

telephone-based social engineering,

physical access scenarios.

Any of these may be assessed.

But which employee groups are in scope must be stated clearly.

Some organisations exclude;

interns,

human resources personnel,

certain executive groups,

outsourced staff.

These exclusions are a deliberate choice.

The aim is not to punish or embarrass employees.

The aim is to measure the resilience of the human security layer against real attacks.

8. Should the SOC Be Aware of a Red Team Operation?

This is an important planning decision.

In some Red Team operations the SOC team knows about the engagement.

In others the operation is known only to a limited number of executives.

The second model is often called the blind Red Team approach.

The aim there is to measure how the SOC team responds to a scenario it believes to be a genuine attack.

For example, how the SOC;

how long it took to notice the attack,

how it classified the alert,

whether it started the incident response process,

whether it disabled accounts,

whether it isolated endpoints

can all be measured.

But leaving the operation entirely uncontrolled is not right.

Even if the SOC is unaware, there must be authorised people able to stop the operation in an emergency.

These people are sometimes called the White Team.

9. What Is a White Team?

The White Team is the management or coordination side that ensures the Red Team operation is conducted safely and under control.

The White Team;

knows the operation's scope,

is aware of the Red Team's activities,

can stop the operation if necessary,

provides coordination during critical incidents.

The White Team is extremely important in blind Red Team operations in particular.

Because the Blue Team may believe it is facing a genuine attack.

In that case the security team may take very serious response steps.

For example;

closing accounts,

isolating network segments,

taking servers offline,

reporting the incident to senior management

are all possible actions.

The White Team provides the coordination mechanism that can, when needed, distinguish a controlled operation from a real security incident.

10. What Are Stop Conditions in a Red Team Operation?

Stop conditions must be defined in every professional Red Team operation.

They describe the situations in which the operation must be halted immediately.

For example, the operation may be stopped in the event of;

unexpected downtime in a production system,

a performance problem in a critical service,

a risk of real data loss,

accidental access to an out-of-scope system,

detection of a genuine cyber attack,

the emergence of a critical security incident.

Any of these should trigger a halt.

One particularly important point is the emergence of a real attack.

While the Red Team operation is under way, evidence may be found that a genuine threat actor is active within the organisation.

In that case the controlled attack simulation must take second place and the organisation's incident response / DFIR process must take over.

11. Red Team and MITRE ATT&CK

The MITRE ATT&CK framework is an important reference point in planning Red Team operations.

MITRE ATT&CK classifies real attacker behaviour under tactics and techniques.

When planning the operation, it can be decided which attack stages will be assessed, such as;

Reconnaissance

Initial Access

Execution

Persistence

Privilege Escalation

Defense Evasion

Credential Access

Discovery

Lateral Movement

Collection

Command and Control

Selecting among these gives the engagement a clear technical frame.

This approach allows a far more systematic assessment at the end of the operation of where the organisation is strong or weak against attacker behaviour.

12. What Is Threat-Informed Red Teaming?

One of the most advanced approaches to Red Team operations is the threat-informed Red Teaming model.

The aim here is not to use random attack techniques.

It is to take the organisation's real threat profile into account.

For an organisation in the finance sector, for example, these questions can be asked first:

Which threat actors target the finance sector?

Which initial access methods do those actors use?

Which MITRE ATT&CK techniques are they associated with?

Which credential attacks are being observed?

Which persistence methods do they prefer?

Which Command & Control behaviours are observed?

This information can be obtained from cyber threat intelligence sources and fed into the Red Team operation.

The engagement then moves beyond;

“Could an attacker attack us?”

to a far more valuable question:

“How prepared are we against the behaviour of threat actors that could genuinely target us?”

What Are the Stages of a Red Team Operation?

Although it varies by organisation and objective, a professional Red Team operation generally follows the lifecycle below:

1. Objective Setting

Business objectives and crown jewels are identified.

↓

2. Scope Definition

In-scope and out-of-scope systems are determined.

↓

3. Rules of Engagement

Operation rules and boundaries are established.

↓

4. Threat Intelligence

The organisation's threat profile is assessed.

↓

5. Reconnaissance

The attack surface is researched from open sources.

↓

6. Initial Access

Authorised initial access scenarios are evaluated.

↓

7. Post-Exploitation

Attack routes after the initial foothold are examined.

↓

8. Privilege Escalation

Opportunities for privilege escalation are assessed.

↓

9. Lateral Movement

Routes for movement inside the network are analysed.

↓

10. Objective

The reachability of the defined operation objective is tested.

↓

11. Detection & Response Analysis

Whether the SOC and security controls saw the attack is evaluated.

↓

12. Reporting and Purple Team

Findings are turned into improvements in defensive capability.

This lifecycle lifts Red Team work out of being merely a technical attack exercise and turns it into a measurable adversary simulation.

How Long Does a Red Team Operation Take?

The duration of a Red Team operation depends on the size of the organisation, the scope and the objectives.

A narrowly scoped engagement may be completed within a few weeks, while in large corporate structures the operation can take considerably longer.

Duration can increase in particular where the operation includes components such as;

many locations,

a large Active Directory structure,

a hybrid cloud environment,

Microsoft 365,

a large number of internet assets,

SOC assessment,

social engineering,

physical security.

Each of these adds time.

The core criterion here is not speed.

It is to carry out a realistic and safe attack simulation.

What Should a Red Team Report Contain?

A Red Team report should be handled differently from a classic pentest report.

Technical findings are of course important.

But from management's perspective, being able to see the entire attack chain is more valuable.

A professional Red Team report may include;

Executive Summary

The overall result of the operation for senior management.

Attack Narrative

The operation story describing how the attack progressed.

Attack Path

The attack route formed from initial access to the critical objective.

MITRE ATT&CK Mapping

The ATT&CK equivalents of the techniques used.

Detection Analysis

Activities detected or missed by EDR, XDR, SIEM and the SOC.

Business Impact

The business impact a successful real attack could create.

Technical Findings

The technical security findings.

Remediation Roadmap

Short, medium and long-term improvement recommendations.

Together these make up the report.

This structure makes the results of the Red Team operation usable both for technical teams and for senior management.

Red Teaming Makes Cyber Security Investments Measurable

Corporate cyber security investment keeps growing.

But the important question is this:

Do those investments really work against genuine attacker behaviour?

A Red Team operation can assess how effective different security layers are when working together, including;

firewall,

EDR,

XDR,

SIEM,

SOAR,

PAM,

MFA,

NAC,

WAF,

email security,

Active Directory security.

All of these are evaluated as a whole.

Red Teaming is therefore not only an offensive security exercise.

It is at the same time a security validation method that measures the effectiveness of the organisation's existing security investments.

Conclusion: A Good Red Team Operation Begins with Planning, Not with the Attack

The purpose of Red Teaming is not to attack the organisation as aggressively as possible.

The purpose is to simulate the behaviour of real threat actors safely, under control and measurably.

To that end, before the operation begins;

the objectives,

the crown jewels,

the scope,

the Rules of Engagement,

in-scope and out-of-scope systems,

the permitted attack techniques,

the stop conditions,

White Team coordination

must all be clearly defined.

A well-planned Red Team operation does not merely show the organisation's vulnerabilities.

It answers a more important question:

If a real threat actor targeted our organisation today, which route would they take and at which stage would we notice them?

To find the answer to that question, we have to look at the attack's first step.

Most of the time that first step is not an exploit.

Before touching a single system, the attacker has already begun researching the organisation's employees, technologies, domain names and digital footprints.

The name of that stage is:

OSINT – Open Source Intelligence.