I wrote a bunch of this while still at Facebook but have since changed jobs. Anything FB is now replaced with $previousjob since I cant speak for them anymore. This was supposed to go on their Protect The Graph post but never happened. The content was useful (I hope) so hopefully people will get something from it. Also slides release here and at the bottom.
---
Recently Chris Gates from the $previousjob Incident Response team presented at Ruxcon (https://
ruxcon.org.au) on “Purple Teaming: One Year After Going From Full Time Breaker To Part Time
Fixer”. The talk was used to highlight some of $previousjob’s experiences “Going Purple” over the last
18months.
What is Purple Teaming?
Purple Teaming is “Putting more Offense in your Defense” and “More Defense in your Of-
fense”. We do this to iteratively improve the quality of both our Red and Blue Teams by conducting focused Red Teams with clear training objectives for the Blue Team.
The talk highlighted observations and lessons learned during this process.
What is Purple Teaming?
Purple Teaming is “Putting more Offense in your Defense” and “More Defense in your Of-
fense”. We do this to iteratively improve the quality of both our Red and Blue Teams by conducting focused Red Teams with clear training objectives for the Blue Team.
The talk highlighted observations and lessons learned during this process.
- Acknowledging the need for the creation of an internal Red Team. The maturity of the security program coupled with the complexity of the organization made it necessary to have internal knowledge to craft more interesting attacks for Red Team exercises.
-
The creation of an internal Red Team and the location of the internal Red Team on the organizational chart. Many companies have both Red and Blue teams operating as separate entities. This frequently causes animosity between the two teams that can lead to growth stagnation because the two teams become focused on catching or defeating each other rather than
innovating together in order to better defend their company. $previousjob’s Red Team is a component of the Incident Response team giving both the Red an Blue teams the same reporting
structure. This placement was intentional as an attempt to avoid animosity and the “us vs.
them” mentality that can frequently plague internal Red and Blue teams.
-
Changing the typical definition of a “Red Team” to be less focused on vulnerability discovery and instead serve as a training event for the Blue Team. For $previousjob, a Red Team exercise tests our ability to respond to an incident and find broken tools and processes. The offensive part of the exercise is required to tell a good story, model the chosen attacker profile, and
craft real world attacks for the Blue Team’s training objectives. The Post Exploitation, Persistence, Lateral Movement portions of the attack are far more important than the initial method
of exploitation. With this is in mind, it is deemed “OK” for a trusted insider to be the initial
exploitation vector (phish, browser attack, etc) and for the Incident Response manager to suppress any initial alerts that may come about from the initial exploitation vector in order to let
the attack play out and allow the Red Team to move on to the post exploitation, persistence,
and lateral movement pieces of the attack.
-
Having a Red Team in-house allows $previousjob the ability to test vs. believing assumptions or
information provided from other teams. It allows us to more easily validate answers to really
important questions like “where can an attacker go if they had a certain set of credentials” or "what can an attacker REALLY do with a certain level of access" vs. what we THINK they can
do with that access. The in-house Red Team is also required to stay up to date with the latest
tools and techniques and can use that information to write detection signatures to catch these
tools.
- Our Red Team reports have both the Red and Blue narrative making the report more valuable as readers see both sides of the attack. Red Team reports are typically only offensive oriented with no mention of incident response, defense, or how well the organization fared against the attackers. By having both the Blue and Red teams tell their respective sides of the story, we tell a much more complete story in our reports. This has the added benefit of highlighting to leadership and the company as a whole the value of the Incident Response team and show wins with new initiatives, gear, training, etc.
The talked wrapped up with a walk-thru of one of the latest Red Team exercises. The slides are
available here:
link
link
2 comments:
Now i know how to be like purple ;-)
Very insightful article. This hits at a point that seems commonplace in the IT security arena. Too many pen-testing reports are full of "I broke your stuff" type text.
Real value means descriptive reports. To all the pen-testers out there...just telling me you broke my software means nothing. Tell me in detail how you broke it (specific tool used, how you ran the tool, etc), the consequences of the problem, and specific recommendations on fixing the problem (e.g. use HTTPOnly cookies in your web.config, sanitize field foobar by disallowing all non-alphanumerics, etc).
As a customer, if my staff can't reproduce what you found, then your findings are only theoretical.
Post a Comment