“So, You’re Building a Purple Team?”

“Purple Team” is a relatively new term gaining prevalence in cybersecurity. I am seeing more roles advertised for purple-specific teams yet in my experience, many organizations are still unclear about the role of the Purple Team and its benefits to security. In fact, I’ve found many people who ask for Purple Team functions are not quite sure what to expect from the program.

Having built and scaled multiple Purple Team programs at every organization level, from start-up to small to medium-sized business (SMB) to FAANG-sized, I can tell you that no two have been identical. The operators, challenges, methods, team organization, stakeholders, and objectives have been different every time. So how do you become an expert at building a team who delivers a not-one-size-fits-all product?

Discuss the Desired Results

Purple teaming is about meeting the security needs unique to the organization: therefore, the first step should be to understand what the desired results are from each stakeholder and whether or not this product can meet them. One of the initial things I always do is ask the main stakeholders, “Why do you want a Purple Team?” and see what they say. (Oftentimes, they really want a pentest, which is different.)

If the organization has an offensive operations program established already, I ask what it is they’re not seeing that they’d like to or think a Purple Team can address. If they don’t, I like to offer what role I believe a Purple Team can play in their maturity roadmap for testing ops and see if the requesters and stakeholders like what they hear. Having that understanding of the role your Purple Team plays in the testing process and security program as a whole, and how to market it effectively, is crucial.

Establish Goals

If your goal is to understand and demonstrate resilience, provide an extra step in the feedback loop of offensive testing operations, or give the vulnerability management lifecycle a break from yet-another-Red-Team-pwn: then Purple can do that. If the goal is that the organization can’t get a pentest for 6+ months because that team is inundated, this may or may not be what they need. If they have a compliance requirement, this may or may not be what they need. It’s important as purveyors of these programs for us to know our limitations and capabilities. Don’t tell the stakeholders your program can do something it can’t.

Map Out Your Team’s Composition

Next, I need to know how to form my team to meet the organization’s structure. Who are the players? The stakeholders? Reporting tools? Current Digital Forensics and Incident Response (DFIR) processes? If the organization is large and has separate dedicated CTI, Detection Engineering, SOC, and Incident Response teams then my purple “team” composition will be totally different than an SMB with one internal cyber security manager outsourcing most of their investigations to a Managed Security Service Provider (MSSP) with maybe one pentester or none at all. No two teams look or operate the same.

Define What Success Looks Like to Your Organization

One of the hardest pieces of managing a Purple Team program is how to quantify and demonstrate success to the rest of the organization. They all think on one hand that I’m a pentester doing more pentesting or worse, that I’m not doing anything at all. One of the keys to getting buy-in and budget for this type of program to be able to scale it is proving its value very quickly.

I like to do this by noting the differences in metrics and milestones I am concerned with versus a DFIR or Red Team. (For example, mean-time-to-detect and mean-dwell-time are not metrics I use to track purple activities.) To do this, I begin with my definitions of what a Purple Team is: Collaboratively bringing red and blue teams together to actionably and measurably improve defenses or mitigate findings. I believe Purple should play a part in between the sophisticated Red Team operations and pentesting steps, and well before adversarial emulation.

In a webinar with Scythe CTO Jorge Orchilles and Plextrac CEO Dan DeCloss, we introduced a new approach to offensive operations to illustrate this:

If a vulnerability scan theorizes, “This COULD be abused,” (identify) and a pentest affirms, “This IS how this can be abused,” (exploit and post-exploit) then a Purple Team exercise would say, “This is how this abuse activity can be reasonably mitigated. Let’s increase the likelihood of a value-added investigation on a SOC analyst’s part and the likelihood it will be blocked and/or logged from a Security Incident and Event Monitor (SIEM) or Endpoint Detection and Response (EDR) perspective.”

When I was previously a Red Teamer we delivered findings in reports; but then when asked by stakeholders how many findings persist across operations or have been remediated since the last exercise, we couldn’t offer any feedback because we had no insight into the remediation lifecycle. Oftentimes, offensive teams don’t even know who the risk owner is and if the risk was accepted or flagged to be mitigated. Purple Teams bring that finding and resolution full circle and don’t place the responsibility on a backlog of swamped engineers to remediate.

Purple Team exercises let us build and confirm the fix is working as intended in real-time and educate defenders on the signs of a particular Tactic, Technique, and Procedure (TTP). From the TTP, we can log its data sources, visibility, and detection methods. Using that information, we can demonstrate a platform’s baseline defenses, and how well it would realistically stand up to Advanced Persistent Threat (APT) group’s known playbooks. I’m now demonstrating: resiliency. That is the main metric of a Purple Team.

Recognize the Highly Customized Nature of Purple Teaming

There is no one singular, correct approach to purple teaming. There is no gold standard. It’s highly customized and unique to not just every organization, but every product. Typically, Red Team’s scope targets an organization’s people, processes, and technology. A Purple Team can follow up by replicating Red Team methods or scoping down to smaller organizational units. For the first time, I am leading a platform-specific Purple Team from the ground up, rather than emulating a Red Team approach. My approach, while the one I believe in the most, is not always the correct fit for every security program. I have to adjust and redefine it as I go. While I know the structure and approach well enough to enjoy the challenge, it’s important for Purple Team program managers to thoroughly comprehend how to customize the strategy, the team, and the deliverables to the unique objectives.

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.