Inside the PEIR purple teaming model

The Prepare, Execute, Identify, and Remediate approach

Everyone should be familiar with the Plan-Do-Check-Act (PDCA) process, also called the Deming wheel, which is a generic management tool used to verify and continuously improve processes and products over time. This seems to perfectly fit what purple teaming is trying to achieve, and that is why we have based the purple teaming process on this method, resulting in a more tailored Prepare, Execute, Identify, and Remediate (PEIR) model.

This high-level process is represented in the following figure:

This scheme represents a high-level purple teaming approach where both blue and red team managers are involved. In such a situation, blue team members may or may not be informed about the exercises. Without crossing the boundaries of red teaming, whose goal is to be stealthy and assess response capabilities, a purple teaming exercise can still be performed in a blind way where most of the blue team members are not informed in order to also assess detection and response capabilities. Indeed, it is possible to simulate red team activities such as injecting logs or deploying unweaponized techniques to evaluate the blue team's overall capabilities and controls, especially investigation, escalation, and response.

Let's now see in a bit more detail each step of the process:

1. Prepare: The purple process is initiated by a plan to run security tests (offensive actions, attacks, and scans) on a predefined scope and security controls. This plan can be manually defined (at least for the first iteration) or automated using advanced implementation or solutions (Breach Attack Simulation (BAS), custom developments, adversary emulation, and so on).
   
   The following is a workflow example of this process step:

1. 1. All members sit at the same table for this phase.
   2. The CTI team starts by selecting a threat actor and the TTPs of the attack that are relevant to the organization, depending on its context and environment.
   3. The CTI team presents the TTPs that the red team will prepare to perform the selected scenario.
   4. The CTI and the red team present the detailed TTPs to the blue team, which documents and identifies expected security controls (prevention, detection, and hunts) for each presented TTP. This step can be skipped if the blind approach is selected.

2. Execute: Attacks are executed in person by a red team or emulated with a tool (continuously or temporarily). The current active defense systems are expected to detect TTPs partially or totally to provide security-related information.
   
   The following is a workflow example of this process step:
   1. The red team starts executing the selected attack scenario.
   2. The blue team will detect and respond to these TTPs.
   3. The blue team manager will report the findings to the purple team manager.
      
      
3. Identify: Gap detection and prioritization are performed. All related information will be reported to the purple teaming process owner (the project manager or SOC manager) or to a technical solution that will identify detection gaps and new unseen security risks.
   
   The following is a workflow example of this process step:

1. 1. All members sit at the same table for this phase.
   2. All teams go through each step of the attack and describe all issues, successes, and failures to document the efficiency of all security controls identified at the beginning of the exercise.
   3. The purple team manager documents all findings.
   4. All members assess and prioritize improvements according to the risk reduction and the implementation effort.

4. Remediate: Implement and validate improvements. Prevention and detection gaps will be identified and then transmitted to the blue team manager to prioritize the implementation of a corresponding remediation. The blue team will perform detection engineering in accordance with the identified risks and then implement new detection rules or change existing configurations. As a continuous improvement process, detection will be checked afterward to ensure it is implemented and working properly.
   
   The following is a workflow example of this process step:

1. 1. The blue team implements the quick wins.
   2. The red team replays TTPs related to the newly implemented quick wins to ensure immediate efficiency.
   3. The blue team together with the purple team manager document and plan the rest of the identified improvements on a roadmap.

This workflow is vendor-independent and can cover any type of purple teaming activities. It can be used as a generic purple teaming workflow approach.

For the veterans among you, in 1993, a document called Improving the security of your site by breaking into it published by D. Farmer suggests various attack methods to defend by thinking like an attacker. It could be the first public resource describing an approach for purple teaming, even if the team, in that case, was composed of one person only.

Purple teaming exercises can be considered as a continuous security improvement process by mixing offensive and defensive skills. This exercise is not purely focused on technology but can also be shaped in different forms to improve the overall security posture (that is, people and processes too).

The foundation of cybersecurity is often described with three pillars, which are the people, the processes, and the technology (or products). Let's now see how purple teaming can address each of them.

Improving the people

Improving the people with purple teaming is a must. Regardless of the types and goals of the purple teaming exercise, people will always benefit from it because it gives them the opportunity to see the other side of security. The red team will learn and understand what kind of security controls are in place within their organization, how they can bypass it, and therefore think about ways to strengthen it to increase the overall security posture of the organization. On the other hand, the blue team will learn and understand how the red team, and therefore adversaries, approaches and operates during an attack scenario, as well as better understanding the strengths and weaknesses of their controls, again to improve the defense strategy.

Nevertheless, it can be useful to assess how people react and handle security alerts and incidents within an organization.

Even if it is not pure purple teaming, some professionals may also implement a blind approach where the blue team is not initially informed. It can be interesting for the blue team manager to determine whether all the members of its team can investigate and handle alerts and incidents in a consistent manner and not depend on people's interests, skills, and experience.

The following criteria should be taken into account:

• Mean Time to Detect (MTTD), which starts from the beginning of the attack until the first event or alert being handled by the blue team.
• Mean Time to Respond (MTTR), which starts from the beginning of the attack until the full containment of the attack by the blue team. This one can be tricky, as it might lead the team to select alerts and incidents that they are most comfortable with. Other key points can be monitored, such as the fact that blue team analysts have effectively followed the steps described in Standard Operating Procedures (SOP) and/or incident response playbooks.

Then, the purple team manager can use those Key Performance Indicators (KPIs) to create charts in order to identify improvements and benchmark against other purple teaming exercises over time. This approach is fully described in Chapter 14, Exercise Wrap-Up and KPIs.

When considering assessing people, other parameters must be considered, such as the following:

• Analyst skills
• Adequate resources to incident response

Thus, to evaluate those points, a purple approach would be to open critical cases and measure whether the blue team (especially level 1) is able to manage and respond to cases in a timely and effective manner (using a service-level agreement or an average handling time).

The capacity to adapt to TTP variations is also important; perhaps your blue team is highly trained to handle specific incidents, but what if slightly different TTPs are applied or, even worse, a different threat actor with radically different TTPs starts considering your business a potential target? This is exactly why simulation is also a key concept that need to be applied and developed. Testing your organizations controls against non-related threat actors may add value in case threat actors decided to shift targets or motivations.

Improving the processes

In addition to people, processes are the second key pillar of any organization's cybersecurity practice; for this reason, it is important to assess several aspects, such as the following:

• Creating defense from newly tested attackers' tools using a shared methodological approach: This is maybe one of the best examples of a powerful collaboration between the red and blue teams thanks to purple teaming. The concept is quite simple -- new tools and TTPs are published every day and evaluated by the red team to improve their internal knowledge, but the same TTPs are also reviewed by the blue team to implement security controls.
• As the purple team is focused on collaboration, both team members should work together to evaluate TTPs to create not only new attack methods but also new security controls (or validate existing ones) to detect and mitigate these methods.
• Reducing the amount of work with automated controls.
• Assessing incident response processes: Performing purple teaming exercises can help measure the efficiency of your whole Incident Response (IR) process; you can review reports generated from these exercises and assess the quality of your IR at each point (analysis, containment, remediation, recovery, and lessons learned)

All these aspects should be taken into consideration when improving the processes around cybersecurity within an organization.

Improving the technology

Technical solutions are implemented at different layers; therefore, being able to assess them is an absolute requirement to ensure the safety of your data. Purple teaming can help us with the following:

• Improving perimeters and endpoint security.
• Continuously testing Security Information and Event Management (SIEM) detection rules to ensure system's health.
• Diffing security tools that generate reports at different periods in time to monitor and alert on evolutions and changes. This topic will be discussed in Part 4: Assessing and improving of the book.
  
  Generating automated reports from security tools such as vulnerability scanners, Active Directory security audits, and network port scanners frequently, and making the diffing automatically between the previous and current report to generate alarms and insights from this intelligence. These technical implementations will be covered in Chapter 12, Purple Teaming eXtended, to provide practical usage examples.
• Being able to answer the C-level question, "Are we prepared for a New_Strange_Name attack?"

So, clearly, the old approach of red versus blue, even if still applicable, can be greatly improved. This book was created for that purpose -- giving us new concepts, tools, opportunities, and ideas to leverage purple teaming in order to improve our overall security posture.

Each of us co-authors has had experience in different environments with multiple positions, providing various visions and tried-and-tested methods of purple teaming for multiple layers of security.

Now that we understand the standard purple teaming process, the next obvious question to ask ourselves is, where do we start? That's why we believe that a maturity model is key to enabling all organizations, whether Fortune 100 or small-to-medium businesses, to start applying purple teaming within.