Some Teams Are Red, Others Are Blue, But Purple Ones Are the Best Value
No ratings
Presented at shellcon 2017 by
How does one build an enterprise red team from scratch? That was the question I faced a year ago when I accepted the lead red team engineer role at Palo Alto Networks. The most apparent lesson for me has been that red teaming as an internal enterprise function draws an interpretation that is quite different from the one generally accepted by the industry. Over the last year, I have had to set aside everything I thought I knew about red teaming and build an approach that offered the value proposition an enterprise is looking for from such a function. In the first part of this session, I want to touch upon the lessons I have learned during my journey to build a red team program. I want to share my thoughts on the philosophy and approach that is most likely to benefit an enterprise program like this. While this might seem very academic, this has governed every single tactical piece the team has had to implement to make the program a success. Not only has the team composition and interactions been heavily governed by the approach, we have also built custom tools and frameworks to operationalize it. The success we have seen so far is what has prompted me to share highlights of the program with a wider audience. Hopefully, I can help someone else struggling with the same question I faced above. The story, however, doesn’t end there, because building a red team program was only half the battle. I’m sure at least some of the attendees have read (with or without scoffing) about the purple teaming movement. While, in theory, it absolutely should resonate with any enterprise security engineer, putting it in practice is a different matter. The second part of the session will focus on approaches and mechanisms to adopt purple teaming. By the end of this session, the audience should expect to walk away with concrete ideas on approaches to implementing enterprise red team and purple team programs.