Purple teaming is the result of collaboration, communication and sharing of information between a red team and a blue team in an effort to improve the overall security posture of an organization. How organizations comprise these components may vary, but for context, a Red team is the offensive security team. They are trained in the tools, Tactics, Techniques and Procedures (TTP) of criminals and attackers. They approach their organization from an attack perspective to find security holes. The Blue team is the defensive security team. Blue teams monitor the environment using defensive tools, analyze anomalies, and maintain defensive measures to prevent, mitigate, and/or respond to attacks. A purple team is not a different team, or at least, it should NOT be. A purple team (red + blue = purple) is the result of the efficient communication and continuous improvement between the Red and Blue teams.
As the red team finds issues, they need to clearly articulate the who/what/where/when/why/how to the blue team. This red->blue interaction gives the blue team an understanding of what was missed, how to detect it, how to mitigate it, and how to prevent it. The same thing applies on a blue->red interaction. When the blue team ensures the red team understand the defenses they are approaching, red has an unfair advantage. This unfair advantage is over real attackers, not the defensive team. Red and Blue are on the same team; the Purple team. This symbiotic integration between the two components enables a fast feedback loop on both sides. The objective is for the organization to win, not one team over the other.
Here is a common scenario: The red team destroys the blue team by subverting controls, finding holes, leveraging low level vulnerabilities and misconfigurations to get to crown jewel data. Done. The red team doesn’t want to share their “methods”, so very little information is shared with the blue team and they are left to figure out the missing controls, detections, and tunings on their own. Another scenario is the blue team knows the game and creates specific controls to stop the red team from performing anything. The red team is unable to perform actions that an attacker would be able to perform and stops. Nothing is gained. This type of infighting stifles the whole purpose of having red and blue capabilities in an organization.
There is also a missing the bridge between security and operations. Many organizations have clear separations between security and operations, citing the principal of separation of duties. However, this leads to more conflict. IT Ops plays a vital role across the full spectrum of security. . Blue teams are on the front lines fighting through a sea of alerts and noise, waiting for “../../../../../passwd” to show up in a log file. At the same time the red team is logging in with an administrative credential they found in a password.xls in an open share. The IT Ops teams are there to ensure things are running as designed and to eliminate problems that affect their users. They have a key role to play in communicating anomalies, implementing more secure configurations and deployments, as well as maintaining the tooling and telemetry infrastructure. Deliberately integrating operations into the purple team will reduce friction and improve communication and collaboration between entities.
The idea is to have a set of people, processes and tools that enable a constant loop of attack, defend, communicate. Having the components for a purple team is the easy part. Creating, nurturing, and leading the culture to be purple is the harder part. In fact, we’ll have a whole different article on that. I don’t particularly like the “Purple” label, or having the need for specific “purple team exercises”. It makes the statement that the different components don’t have to talk to each other unless they on the “purple team”.
“I don’t have the budget for a red team”, “I don’t even have a blue team.” “We have an MSSP, so we are good”. Some organizations rely on the IT Ops team to do it all or outsource it entirely. This is scary, but not uncommon. In a recent operation, we were instructed to be loud and overt. We found several paths to domain admin. The trusted agent at the organization stopped the operation because the MSSP was oblivious to the attacks. While outsourcing is a common practice for CXOs, I would argue you are outsourcing the work, not the risk. If you are leveraging an MSSP for your blue team, take a look at your service level agreement. How is it structured? How do you test it? Do you have the ability to ensure they are catching the right bad things?
At Horizon3.ai, our goal is to provide organizations of every shape and size the ability to safely attack and assess the security of their environments. NodeZero is the safest and simplest way to get an attacker’s perspective. It was built with purple blood. It safely attacks your environment, explains how it found weaknesses, provides an understand of the weaknesses as well as mitigation steps. If you don’t have a red team, NodeZero can fill that gap. If you have a red team, NodeZero can be an extra set of steady hands, giving you more time to dig into more complex problems. We’re a team of former U.S. nation state attackers, IT Operators, and Intelligence analysts, mixed with incredible product engineers. We believe that the only way to know if your defenses will hold up to an attacker is to continuously send an attacker through your defenses. Our service works same way an attacker works. Questions lead to answers lead to questions. These questions and answers are the heart and soul of the purple team. Everyone learns, everyone improves, and security of the entire organization improves.
