More on Purple Teaming

I wanted to add a bit more context/info/explanation on Purple Teaming after publishing the Ruxcon slides as well as Facebook and Twitter interactions on that topic.

What is Purple Teaming?

Currently, there are as many definitions for Purple Teaming as there are talks and blog posts on the subject but I'm going to throw mine in as well.

Purple Teaming is "conducting focused pentesting (up to Red Teaming) with clear training objectives for the Blue Team."

The clear training objectives (aka a plan to eventually get caught) for the Blue Team is what differentiates Purple Teaming from typical Red Teaming. By its very nature, Red Teaming is making a HUGE attempt not to get caught. You are pulling out all the tips & tricks and big boy tools NOT to get caught.  With Purple Teaming, you have a plan to create an alert or event in the event the Red Team is not detected by the Blue Team during the Red Team process so the Blue Team can test their signatures and alerting and execute their incident response policies and procedures.

It isn't a "can you get access to X" exercise it is a "train the Blue Team on X" exercise. The pentesting activities are a means to conduct realistic training.

A couple practical examples:

The Blue Team has created alerts to identify Sysinternals PsExec usage in the enterprise.  The Red Team would at some point use PsExec to see if alerts fire off and the Blue Team can determine which hosts were accessed or pivoted from using PsExec.  The Red Team could also make use of all the PsExec alternatives (winexe, msf psexec, impacket, etc) so the Blue Team could continue to refine and improve their monitoring and alerting.

Another scenario would be where the Blue Team manager feels like the team has a good handle on the Windows side of things but less so on the OSX/Linux side of the house.  The manager could dictate to the Red Team that they should stay off Windows Infrastructure to identify gaps in host instrumentation and network coverage for *nix types hosts and also to force incident response on OSX or Linux hosts.

Another example could be to require the Red Team not to utilize freely available Remote Access Trojans such as Metasploit or powershell Empire. Instead they could ask that the Red Team purchase (or identify a consultancy that already uses) something like Core Impact or Immunity's Innuendo or find a consultancy that has their own custom backdoor to spice things up.

Thoughts?


Other Purple Teaming resources (in no particular order):

http://www.slideshare.net/beltface/hybrid-talk
http://www.slideshare.net/HaydnJohnson/purple-view-56169114
http://www.slideshare.net/denimgroup/b-sides-san-antonio-albert-campa-denim-group
http://www.slideshare.net/alienvault/security-by-collaboration-rethinking-red-teams-vs-blue-teams-cuispa-final-22015
https://files.sans.org/summit/hackfest2014/PDFs/Hacking%20to%20Get%20Caught%20-%20Raphael%20Mudge.pdf

Purple Teaming - Lessons Learned & Ruxcon Slides

Note:
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.

1. 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.
2. 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.
   
3. 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.
   
4. 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.
   
5. 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:

Going Purple : From full time breaker to part time fixer: 1 year later from Chris Gates

link