Why communication and management is crucial in red teaming exercises

Many great blogs and articles have been published around the technical aspects of offensive security services. Underrepresented and maybe underappreciated are the managerial and communication aspects of these highly technical professional services. As a result, clients often neglect or are unknown with the level of engagement management that a proper offensive security exercise (red teaming, adversarial simulation, TIBER) brings along. Worst case, the client regards red teaming as a black-box exercise, praying that the red team will not accomplish anything or disrupt anything along the way.

In our opinion, this is not the way it should be and does not provide the best possible value for the client. Value is derived from the lessons the client can learn from these exercises, and as such, every client should have good visibility and control of every professional red team they hire. Together with the red team the client can manage the risks of such an engagement, is able to steer if needed, update the stakeholders, and grasp all lessons learned.

Let’s start at the beginning. When an organization considers a red teaming engagement, one of the following reasons is the most likely instigator:

  • you want to know the current status of security controls (how are we doing?);
  • your stakeholders need a wake-up call to realize the importance of improving the security controls (why do we need to do something?);
  • the organization wants to improve but struggles where to start or get the priorities in place (are we doing the right things?);
  • a regulatory requirement (e.g. CBEST, TIBER-EU) dictates a periodical exercise (are we compliant?).

For all of the above-mentioned reasons, a red teaming exercise is not the goal, but a means to an end. Red teaming can show extremely well where the gaps are in the current security controls (protect, detect and respond), but also the impact of an attack to business operations (e.g. the entire manufacturing plant could be disrupted for days). Ultimately, we want to help the client become better at defending against adversaries.

Due to the inherent risks that are connected with simulating an adversary in a production environment, we need to consider how we can manage those risks. Making an avoidable mistake might not only take valuable resources of the client (managing stakeholders and restoring whatever was impacted by the mistake), but also directly exposes the red team taking away the opportunity of learning valuable lessons on other aspects such as detection or incident response.

Crucial optics for managing red teaming exercises

So, how do we ensure the best learning experience for a client and what do we need to take into consideration when managing a red teaming exercise? These three topics are crucial:

  • Stakeholders;
  • Communication;
  • Risk management.


When asked to perform a red teaming exercise, there are often more stakeholders besides the person procuring the engagement. Rule of thumb is to have the least amount of people involved and aware as possible when the exercise is being performed to keep the exercise realistic (an attacker does not announce his presence either).

The people within an organization who are aware of the exercise, we simply call the “white team”. The white team can consist of internal stakeholders and external stakeholders. Internal stakeholders are often the CISO, representative of the board, head of SOC and internal audit. Having them on board is extremely important for risk management and de-escalation if needed. External stakeholders are less common but could e.g. be a supervisory authority like a Central Bank in the TIBER-EU program.


The trick is to communicate with the white team in a way that everyone is informed so they can take the right actions and decisions.

To start, define milestones and end-goals. Simple “flags” to determine the progress of the red teaming exercise. Starting from the first entry point in the network, to the final step of performing a money transfer, to give an appealing example. Additionally, define learning goals. What does the client want to learn with this exercise? An example could be to have an incident triggered and test the incident management process.

Throughout the exercise, schedule update meetings. At least once a week, often twice a week and when it gets really intense, a daily meeting is required. During these meetings, the actions performed since last update meeting and next steps are discussed, and try to identify risks introduced by taking next steps. Together determine whether mitigative actions are needed or that a specific next step should not be performed at all. Between the update meetings, real-time communication with the white team can be provided using an encrypted group chat channel. If necessary, ad-hoc update meetings can be schedule and it keeps the white team more involved in the process.

The more mature a client becomes when it comes to cyber resilience, the more important these update meetings become. Because there is often a larger chance that malicious activity will be picked up, the political landscape is harder to navigate, and escalations will happen more often.

It’s also important to identify escalation paths in advance. Knowing how incidents travel through the organization is vital to understand where they can be stopped from escalating too far (or outside the organization). The white team should also be able to quickly call upon the red team’s help when an incident is triggered or when triage is necessary. Whether that incident was the result of the red teaming exercise or not. This could be done by providing detailed information about the activities of the red team, such as IP addresses, MAC addresses, compromised accounts, etc.

Risk management

Being allowed to hack into a client’s production environment is exciting, but it comes with responsibilities. Disrupting daily business by accident will cost the client extra (in terms of lost revenue, recovering, delays, missed deadlines, etc.). Therefore, it is important that red team operators and managers alike are experienced in manoeuvring such an environment and able to signal any risky outcomes of their actions. They should be able to identify if a public exploit on a core system could crash the system and identify alternative routes that lead to the same point. Discussing these risks and alternatives with the white team will provide the necessary control over what is happening and help them being able to stand by if it is agreed to perform a risky action.

Defining the end-goals clearly up front and reinforcing their definition during the engagement makes a huge difference (e.g. “transfer money” vs. “demonstrate the possibility to transfer money” vs. “gain access to an approver and a lower privileged account in application X”). We therefore always ask the client to more closely supervise the red team when we are getting close to the end-goal. Having a wrongly placed “;” inside a core payment system could have a huge impact. Having the supervision of an ‘insider’ will reduce the risk of something going wrong.

Putting in place restriction and communicating openly about risks is key. For example, certain windows might be imposed where no activity can take place when the financial system is performing the monthly payroll batch as the client cannot afford to disrupt this process. Certain individuals with a protected position (e.g. legal counsel or government representatives) could also be taken off the target list. Clearly defining these restrictions and implementing them in the red team’s modus operandi will give the client control over what is happening.

When a real high-priority incident occurs during a red teaming exercise, the red team should also be prepared to put their “keyboards down”. Getting back to business-as-usual is more important than the red team’s planning.

To conclude

We started this article with the mention that the managerial and communication aspect of red teaming exercises is underrepresented in articles. With this article, we aimed to provide the community pointers on successful red teaming exercises, containing the right mix of stakeholder management, risk management, and communication between client and red team.

Managing a red teaming exercise is by all means no easy effort. With the high turnover in technologies and the fast pace of an exercise in large and unknown environments, proper management of the exercise can make the difference between a true learning experience and a cash burner.

This article has been co-written with Ivo Noppen.

Knowledge center

Other articles

FalconHound, attack path management for blue teams

FalconHound, attack path management for blue teams

[dsm_breadcrumbs show_home_icon="off" separator_icon="K||divi||400" admin_label="Supreme Breadcrumbs" _builder_version="4.18.0" _module_preset="default" items_font="||||||||" items_text_color="rgba(255,255,255,0.6)" custom_css_main_element="color:...

Leg ups: helping hand or red team failure?

Leg ups: helping hand or red team failure?

[dsm_breadcrumbs show_home_icon="off" separator_icon="K||divi||400" admin_label="Supreme Breadcrumbs" _builder_version="4.18.0" _module_preset="default" items_font="||||||||" items_text_color="rgba(255,255,255,0.6)" custom_css_main_element="color:...

Together. Secure. Today.

Stay in the loop and sign up to our newsletter

FalconForce realizes ambitions by working closely with its customers in a methodical manner, improving their security in the digital domain.

Energieweg 3
3542 DZ Utrecht
The Netherlands

FalconForce B.V.
[email protected]
(+31) 85 044 93 34

KVK 76682307
BTW NL860745314B01