1. Size mattersIn our talk, Chris Gates and I emphasized that Purple Teaming does not require large teams; it does, however, require a mature team. So this is our tip. Think small. Yes, the word “team” is in it, but a Purple Team can be run by two individuals. It can be as simple as taking an attacker mindset to your business. The definition of Purple Teaming from our talk at SecTor is:
"Conducting focused pentesting (up to Red Teaming) with clear training objectives for the blue team."Also, for a talk that follows on from that, you should watch Chris Nickerson and Chris Gates Brucon's talk. Carlos Perez (a big advocate for Purple Teaming) description of Purple Teaming is:
"Purple is the symbiotic relation Red and Blue team in a way that improves the security of the organization, constantly improving the skills and processes of both teams."Simply put, Purple Teaming exercises are executed deliberately to test the blue team’s process, people and technologies to confirm or deny defense capability. It is more about testing assumptions and gaps than having big teams. To emphasize this point even more, and if this is the first time you have thought about a Purple Team exercise, think about something small two people could work on together. It does not even have to be a pentester and a defender. It could be two defenders wanting to test an attack tool. In order to be effective, having a detailed plan is needed, and not just a static plan, but an agile one.
2. PlanGaining the most of the exercise requires understanding why you are conducting the exercise. Like everything, planning allows you to get the most benefit. In business terms, this translates to more bang for your buck, but with less hit on the budget for more value. Things to take into consideration when planning a Purple Team exercise are:
- Is there anything critical from a previous pentest, security assessment, audit, or vulnerability assessment that we want to ensure has been remediated?
- What are the goals for the exercise?
- Is it to improve an IR teams response?
- Is it to improve network alerts?
- Is it to confirm an assumption or to test a gap in controls?
- Are you testing people, process, or technology, or all of it at once?
- What do we want to achieve?
- Reason/instigator for this exercise
- Is this the result of a report?
- Is this the result of a newly identified gap?
- Estimated/allowed timeline for exercise
- High level key activities
- Key activities in detail with specific outcomes.
- For example, if testing Antivirus, you might want something like the example shown below. Antivirus is easy to bypass and everyone can test it, which makes it a good example to get thoughts and ideas flowing.
|Test||Outcome (Detected) Y/N||If detected at what stage||Action Items to improve|
|Standard Meterpreter||Y||Upon execution / staging||Follow up with common ports|
|Meterpreter with Paranoid options||N|
|Meterpreter with Veil Evasion||N||Follow up with detecting outbound traffic on uncommon ports|
- Ensure Antivirus is catching common C2 servers.
- If it does, how easily can it be bypassed.
- Application Whitelisting (MD5) is enforcing correctly.
- Names, Level, Skills
- Key Contacts
- Who needs to know, etc.
- How will this exercise be documented and recorded?
- Who is accountable?
- How will this be followed up to ensure implementation is completed?
3. Go With What You KnowAs per the above example on Antivirus, do not attempt to bite off more than you can chew. Start with what you know and test from there – go from easy to hard. Testing assumptions is easier to do. Another example is data exfiltration:
"Do you have any detection of high amounts of data transferred out your network? (USB extraction, Gmail, etc.)"From there, you identify gaps in assumptions. From gaps, you can test mitigating controls. For example, if X technology does not catch Y, are there other things catching/detecting that, or reducing the potential for impact? You might want to look into DNS logging. There is a great talk from BSidesLV 2016 by Jim Nitterauer (@JNitterauer) on DNS traffic.
4. Lessons LearnedBuilding on what we have now learned about thinking small, planning correctly and starting with the easy ones, the next tip would logically be: following up on lessons learned. I often do an exercise, learn a new tool or syntax, and forget to write it down. Sometimes the very next day, I Google the same command to use, so now I have started collating this information in one place. This saves time and effort and furthers my learning. I strongly suggest you aim to do this from your Purple Team exercises. Potential improvements can be:
- Identified in people, processes, and/or technology
- The gaps identified – can these be used for further testing
- Were the right people involved?
- Was communication effective?
- Should more time or less time be used?
- Implementing/making changes of the identified ‘lessons’
- Create a roadmap, estimated timeline and effort required of things that can be implemented