Red Team + Blue Team = Purple Team

At Code42, we are transitioning security operations (SecOps) away from the traditional Red and Blue Team structure. By leveraging our defensive and offensive skillsets, we are opting for a “Purple Team” approach to encourage collaboration and improve our security posture.

The Traditional Roles

Generally, security analysts are the “firefighters” within a security operations center (SOC). Analysts inspect network traffic, manage logs, and respond to alerts to ensure that data remains safe and secure. As the first to respond during a security incident, analysts use investigative processes and tools when mitigating threats. Through these processes, they identify visibility gaps within an environment, and are responsible for relaying this information to engineers to brainstorm potential new data sources and logging solutions.

In the SOC framework, security engineers are responsible for maintaining and operationalizing security tools to ensure that analysts have access to relevant data. This involves provisioning, patching, and de-provisioning both physical and virtual hardware used by the security team to investigate and respond to incidents. Those in engineering roles work with analysts to implement data sources, dashboards, and technologies to enhance visibility. Scripts and automation developed by engineers are used by analysts to speed investigations and response time.

For many organizations  —  especially those with large attack surfaces spanning numerous networks  —  the separation of analyst and engineering roles creates a natural escalation path for incidents entering the SOC. As analysts further understand their environment, they can provide recommendations to engineers for enhancing response procedures. These feedback loops can vary greatly in scope. 

One analyst may say, “It would be really nice if we could automatically send these file hashes to VirusTotal”, while another may approach an idea more broadly: “I think we need a better way to categorize log-ins from unexpected locations.” Traditionally, it is up to engineers to determine the feasibility of requests coming from analysts. As the subject-matter experts for security infrastructure, engineers have the knowledge to make informed decisions about what is possible given current configurations.

Indeed, analysts analyze and engineers engineer. But what happens when these traditionally siloed roles make up a collaborative Purple Team?

Purple Team at Code42

Both analyst and engineering roles fit into the Blue Team structure of a SOC. Blue Teams are primarily focused on creating security alerts and detection methods to prevent organizational cyberattacks. Contrarily, Red Teams facilitate offensive tests and emulations to verify the work of the Blue Team. We have both engineering and analyst roles at Code42; however, we are trailblazing a different approach to SecOps responsibilities.

As a naturally agile team, we decided to standardize our collaborative efforts to encourage information sharing and improve our security posture among our Blue and Red Teams. Aptly called a “Purple Team” approach, this push was organic, supported by our analysts, engineers, and management. According to SANS, Red Teams and Blue Teams should be encouraged to “share insights beyond just reporting, to create a strong feedback loop, and to look for detection and prevention controls that can realistically be implemented for immediate improvement.”

This doesn’t mean that specialization and go-to responsibilities disappear. Instead, a Purple Team approach leverages the knowledge and expertise of each contributor through collaborative exercises. Rather than offensive security engineers running exploits and waiting to see if defensive analysts detect and respond to them, we utilize working sessions to run the emulations in real time. We have already seen this approach increase our speed-to-response and detection capabilities.

Purple Team Analysts and Engineers

Our analysts have varying levels of experience from previous roles. Specifically, our analysts are interested in scripting and automation building in our security orchestration, automation, and response (SOAR) tool. These responsibilities are traditionally reserved for engineers in a SOC; however, we recognized the benefits of empowering analysts to make these changes. As the primary responders to notifications and alerts, our analysts are “in the trenches” and can use this knowledge to determine what context or information may be missing. Already, our analysts have developed new playbooks and automations in direct response to visibility gaps discovered during investigations.

Our engineers held previous roles as system administrators and identity engineers, providing invaluable knowledge of hosting and maintaining security infrastructure. Just as our analysts have taken on scripting and automation work traditionally reserved for their engineering counterparts, our engineers have absorbed analyst responsibilities within our Purple Team. This includes responding to alerts in queue, researching new exploits, and developing response procedures for security incidents.

Through this blurring of responsibilities, our goal is to create a team that is well-versed across numerous security disciplines. By minimizing knowledge gaps between our analysts and engineers, we hope to minimize knowledge gaps across the security landscape.

Rotation Program

One unique aspect of our Purple Team organization involves a rotation with our offensive security engineers. Every two to four weeks, an analyst will help develop an exercise that tests the defensive and alerting capabilities of the Purple Team. While traditional responsibilities are maintained during the rotation, this opportunity helps our analysts gain experience from an offensive perspective. Each rotation ends with a debrief, where we share insights about the exercise and develop action items to improve and adjust security controls.

Similarly, our offensive security engineers will periodically rotate into defensive roles. By reviewing alert and response procedures first-hand, our offensive engineers will develop more targeted and specific engagements within our environment.

These rotations are time-boxed to encourage clear goals for each engagement. Our hope is to improve our security posture thanks to varied perspectives from each of our analysts and engineers.

Sharing expertise and specialties with the entire team mitigates knowledge discrepancies; however, this only goes so far. For this rotation program to be successful, analysts and engineers must approach problems with a growth mindset, asking questions and clarifying ideas to prevent knowledge from being “stuck” within a subset of the Purple Team.

Logistical Considerations

With so much collaboration and sharing of responsibilities within projects, documentation is integral to our success as a team. We use a variety of Agile-inspired ceremonies to ensure projects remain on-track. Besides our weekly standups and debriefs, we begin each month with a Purple Team planning meeting. These meetings are designed to address the following:

• Determine who will be working defensive and offensive rotations
• Identify projects for the month and assign tasks
• Create tracking tickets for projects and document key results

We are building more structure into our work, but we also recognize the dynamic nature of these projects. While one offensive exercise may last one week, another may be more involved and require two or three weeks of planning and execution. Knowledge sharing between analysts and engineers naturally identifies documentation gaps, allowing our team to bolster internal knowledge bases and identify process inefficiencies.

Addressing Limitations

Of course, graying of responsibilities may be seen as a constraint of this approach. Especially in large organizations, SOCs are segmented with well-defined roles to standardize response tactics and encourage escalation. As a smaller and agile team, we use the Purple Team framework to eliminate points of failure across our SOC. When an analyst is out-of-office or a prominent 0-day vulnerability is released, we can leverage the expertise of everyone to move quickly without compromising process effectiveness.

Consistently moving between projects is not easy, so it remains important to manage expectations and key results to prevent burnout within our team. The work of an analyst during one week may be completely different during the next depending on the needs of the team.

In our hybrid remote environment, we use hangout meetings to dedicate time for non-work discussions. This substitutes the casual conversations that would naturally occur with our team in one office, encouraging consistent dialogue between team members. More importantly, our team is comprised of individuals who have real passions for learning and sharing their knowledge about cybersecurity. With such a variety of backgrounds and interests among our team, we are excited to utilize our experiences to benefit the team as a whole.

One unanticipated limitation to this approach occurs during the hiring process. When hiring for an open engineering role, we quickly learned that not all engineers want to participate in the alert queue. This creates a new layer of difficulty for hiring. In job descriptions across our SOC, we highlight the importance of responding to incidents when necessary and contributing to the overall maturity of our alerting footprint. For potential candidates coming from larger organizations with well-defined responsibilities, this approach can be off-putting. This phenomenon occurs in many lines of business, as those with specialized skillsets are sometimes against more generalist roles. As a team, we must remain cognizant of this sentiment and transparent about our approach when recruiting.

Looking Ahead

Ultimately, we hope that our Purple Team approach helps us bridge gaps to find success. With a dynamic approach to responsibilities, our team is embracing new ideas and challenging existing procedures in the constant pursuit of better. As we continue this transition, our processes will undoubtedly change based on our learning. We are fully committed to trailblazing this approach, and look forward to sharing our thoughts and insights in the future!

To read more great posts from our Code42 security team, check out the RedBlue42 blog at redblue42.com.