Red and Purple Teaming serve distinct purposes, and we think NIST CSF backs us up on that. We outline why we believe in starting with Purple Teams to validate Protect and Detect before using Red Teams to validate Respond. I’ve heard the question, “Do Purple Teams help to test the incident response process?” over and over again.
My response? No. At an FS-ISAC Summit presentation this Spring (2019), an insightful attendee asked the articulate presenter (I was neither person), “Do Purple Teams help to test the incident response process?”
My answer: No.
Purpose of Purple and Red
Purple Teams seek to understand and fill gaps in Protect and Detect controls. Purple is the readiness test for technical configurations, controls and alerts. Purple’s approach is comprehensive and layered, just like the spirit of NIST CSF’s Protect and Detect which together comprise more than half of the Framework’s total controls. There is a clear message that there is more to cover in these two CSF Functions.
If Protect and Detect are appropriately evaluated, Respond does not need to be comprehensive, and that is why the Red Team function is the best way to test it. The Red Team is the stealthiest path possible to simulate compromise. It purposefully avoids the obvious walls and alarms and answers the real-world question “will the organization Respond?” Purple, however, wants to provoke as many alarms as possible, refine and make them more meaningful, more complete, and more ready to be surprise-tested by Red.
Still, why can’t Purple verify the Respond function? If during Purple Teams an attack operation triggers a low severity alert in SIEM, and the participating Incident Responders say “yeah, we’d react to that,” who’s to say? An alert fired at low severity (fact). The participating responders are speculating about what their response would be (not a fact). If Red is the test of the Respond, we live in the land of facts – the alert will be actioned or not in the course of continuous monitoring.
Sequence of Purple and Red
NIST CSF starts with Identify. It’s a big mixed bucket of governance, risk and asset management needed to plan and maintain the scope of the program. Got it. Then comes Protect, then Detect, then Respond. There is a logical sequence to NIST, with Purple playing an essential role in the verification of Protect and Detect, and Red is the vital real-time audit of the Respond function. There is less value in testing Respond before you’re reasonably ready. Many organizations are still doing this in the wrong order. Protect and Detect intentionally come first in NIST CSF, and should be verified first by Purple Teams (not a checklist audit). If Protect and Detect controls are low maturity, you are sure to follow with low maturity Respond.
Tim Wainwright
Tim is CEO at Security Risk Advisors (SRA), which he helped found in 2010. He oversees SRA's strategy, culture and growth.
Tim advises CISO offices on practical and cost-managed adoption of AI in cyber defense, achievable strategy wins and modern detection and response. He has been a repeat speaker at RSA Conference, Gartner, and more ISAC’s than he can remember.
Kevin Foster
Kevin leads defensive security strategy and implementation projects for clients in financial services, telecom, aerospace, manufacturing, and healthcare.
He also uses his technical expertise to assist clients with strategic maturity assessments, such as NIST CSF and CIS. Kevin advises clients in risk mitigation strategies through program development, controls implementation and engineering.
Kevin specializes in projects related to Threat Hunting and Incident Response (IR) activities, Active Directory hardening, and maturity framework assessments.
Kevin is a GIAC Certified Forensic Analyst (GCFA) and has also obtained GIAC Reverse Engineering Malware (GREM), GIAC Certified Detection Analyst (GCDA), and GIAC Defensible Security Architecture (GDSA) certifications.