Ben Goerz Enterprise Purple Teaming Professional Interview

6/25/21

• When you leave those groups in silos, they can produce valuable results. But the collaboration and the efficiency is just not as good as if they were testing together. Also, if done correctly, I think you can do it in more digestible chunks.
• We never brought in consultants for the purpose of purple teaming, but we did have several consultants who we worked with routinely, like our firewall guys, professional services, people who would occasionally be invited.
• Usually they were additional tactical resources to support the blue team side of the engagement. So, for instance, if we were doing if we were testing command and control traffic techniques around that specifically, that might be a week where we invited one of our Palo Alto resident engineers who was a consultant to come in and observe. And then when our blue team folks are going through the data and say, you know, why did we miss this or what else could we do to improve these detections, then we immediately had the expert on those appliances sitting right there.
• Accessibility is what drove the one-hour session strategy.
• Blue Team had to answer three different questions: (1) Were the protections effective? (2) Was there visibility in the logs or anything else? (3) Was there an appropriate security response? We track that for every test, but we intentionally did not try and score it because we did not want to create any incentives for one team to feel like they were winning or losing. The purpose of the exercise was to get accurate data, not to embarrass one team.
• We intentionally kept it really simple. Our roadmap of TTPs that we were testing was in Excel, saved on SharePoint, and we saved all of our reports on SharePoint, whatever is convenient. But we definitely didn't want to add more managerial complexity to the process.
• But we intentionally tried to invite other people very frequently. We had people from SOC or other blue teamers all sit in. And I think those are the guys who probably learn the most because they weren't so focused on delivering the report that they actually got to kind of step back and learn more from the process.
• It was more about what's humanly possible rather than does the value justify it.
• The blue team walked in knowing only what TTP we were going to test that day. They knew nothing else prior to walking in. We did that intentionally because we did not want the blue team to prepare new SIEM content or something the night before. We felt that would be unfair to the red team.
• Essentially the run back was occurring while we did the exercise because everybody who is relevant was invited and we told them to go immediately implement the stuff. We didn't want to have any more meetings about it.
• There's this developing industry around purple teaming and there are different people coming in with different ideas. You've got SCYTHE coming in with their processes and kind of their approach. And I'm coming in preaching a whole different one-hour approach and like everybody's selling their own snake oil. And at the end of the day, I think there's commonality and value in all of those, and different ones will fit different organizations.
• It's important that we remain flexible and we learn from one another because what's good for one organization may not be good for another and vice versa. So same thing holds true about organizations with different threat profiles. It may make a lot more sense to run big, long engagements and just do more purple teaming if you're working for a defense contractor than a diaper maker. So regardless of where you're using it, I think there is value, but it's going to look different every place you go.