The “Purple Team” term has been flying around for a while now and it is an important development in our growth as an industry. If you haven’t heard the term before, it is a sharing and collaboration between the Red Team (offense) and the Blue Team (defense) with the goal of making both better (commonly a greater focus on Blue). The Red Team should be working with the Blue Team to make Blue better. If the Red Team fails to do so is a waste of time and money. Unfortunately, I’ve seen too many Red and Blue teams treat each other as adversaries; where sharing is limited, and collaboration opportunities are lost. Red and Blue aren’t opposing swords; they are a sword and a whetstone.
A small note: Above, I when I used the term “Red Team”, I meant it as the team doing anything offensive – from penetration testing all the way to full-scope red team. Yes, it is term overloading, but those are the terms. To help with clarity I’ll refer to the teams as a proper noun (Red Team) and the test more generally (red team engagement). I won’t get into the nuances of red team engagements and how it relates to penetration testing since that isn’t the focus of this post.
Many organizations have developed in-house Purple Teams (great!). However, many organizations don’t have an in-house Red Team, or they have a new Red Team and they need to develop the communication between Red and Blue. In either case, outside help is often needed. As an outside 3rd party, I’ve seen three major categories of purple team engagements:
- Contractor acts as White Cell with in-house Red and Blue – This method is used to teach organizations how to do an effective red/purple team engagement. The contractor acts as a facilitator to help design scenarios/tests and develop communication between the teams.
- Contractor is Red, with daily contact (or onsite with Blue) – This method is used when the organization does not have an in-house Red Team. It is also ideal for iterating on a protection or detection method where the Red Team takes an action over and over again and Blue tunes the defenses, protection and/or detection. It allows Red to take a shot and for Blue to immediately look at defense and detection capability and adjust it to reduce noise, increase fidelity, or stop the attack all together. A lot of communication is key!
- Contractor is Red, with deferred contact – The Red Team works through the entire assessment and then the teams spend time discussing successes and learning opportunities. This method is designed for more advanced defenders. The Blue Team then looks back at defenses and logs to see where they can tune detection capabilities. Unfortunately, I see this most often used as a purple team engagement when it should be a red team engagement, but the organization doesn’t want a red team engagement because previous engagements were adversarial, or the Red Team dropped off the report and left.
There are a few basic things we look at when measuring detection capabilities.These items can be summarized by the acronym ACE.
- Automation: How automated and timely is the detection and notification work flow?
- Coverage: Across how much of the environment will this detection work? Is it limited to specific systems or subnets?
- Effectiveness: How effective is the detection? Is there a high false positive rate? Does the detection only work in specific circumstances?
The testing should be documented to show advances in detection and response capabilities. Also, these metrics can be used to justify investments in tools and training.
As previously mentioned, purple team engagements are designed to test and train the Blue Team. They can be done with or without an in-house Red Team. The way the tests progress often depends on the availability of the Blue Team. Purple team is often best done as a red team style engagement, not a penetration test. The difference between the engagements is:
- Red team engagement: Using real world tactics, techniques and procedures (TTPs) to emulate a real-world attacker with the goal of testing and training the defenders (incident response, SOC, etc.) and defenses (technology and processes).
- Penetration Test: Focused on finding a broad range of vulnerabilities and technical flaws.
In short, a red team tests the defenders while a pen test tests the defenses.
There are a few basic questions to ask if you are going to do a purple team:
- Do you have an in-house red team and are they planning on participating? (Yes or No)
- Yes – Then the engagement is about helping them define tests and metrics. It is about helping them figure out how to do collaborative engagements.
- No – You’ll need a 3rd party red team that will help you work through the collaborative engagement. The 3rd party Red Team will define the metrics and the tests after getting input from Blue on what they want tested.
- How actively would you like to be engaged in the process?
- You would like to be very actively engaged – this means that the defenders will regularly be in contact with the Red Team, usually daily (or more frequently). If you like, there can be shot validation, meaning that as Red performs actions they will work with Blue to check on detections and protections. If there are improvements to be made, the Blue Team can implement and Red can test again.
- You would like to defer interaction until the end – The Red Team needs to document their actions so the blue team can go back and look for evidence and tweak defenses. Red will have a lengthy discussion with the blue team to help them improve. This is much more in-depth than just going through the report. It will include protections (e.g. patches) as well as ways the Red Team could have been detected.
- It will be necessary to understand your logging and monitoring maturity. The blue team isn’t going to get much benefit from the a purple team if log collection and alerting is minimal or non-existent. It is therefore important to ask a few questions related to logging and alerting, such as:
- Are logs collected in a central location and correlated in a SIEM?
- Are event logs collected from endpoint workstations?
- Are logs collected in real-time or as a batch process?
On the surface, Red and Blue may appear to be adversaries, but in reality we are making ourselves better to prepare against the real adversaries. To quote Red Green, “Remember, I’m pullin’ for ya! We’re all in this together! Keep your stick on the ice.”
Related Stories
View MoreObfuscating Shellcode Using Jargon
By Red Siege | July 31, 2023
by Mike Saunders, Principal Security Consultant In a recent blog , we discussed how encrypting shellcode leads to increased entropy, which may result in your shellcode loader being blocked and/or […]
Learn MoreBrowser Only Web Application Testing
By Red Siege | July 24, 2023
By: Ian Briley, Security Consultant Spoiler Alert: Burp is the number one tool most people use while testing web applications. If you want to be an open-source champion, ZAP from […]
Learn MoreIntroduction to Mythic C2
By Red Siege | June 28, 2023
By: Justin Palk, Senior Security Consultant Continuing along with my occasional series looking at how to set up and use various C2 frameworks, this is a guide to Mythic C2. Developed […]
Learn More