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.

Stakeholders

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.

Communication

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.