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 has been a speaker at RSA, Gartner, FS-ISAC, H-ISAC and (ISC)2 National Congress. Tim helped found Security Risk Advisors in 2010. Tim advises CISO Offices on modernizing cybersecurity strategy to improve governance, communication, team culture and growth, detection and response capabilities. Tim is a thought leader in the area of purple teams and attack simulation and metrics to describe quantified threat resilience. Tim has a background in penetration testing, security assessment, and frameworks.
Kevin Foster
Kevin leads defensive security strategy and implementation projects for clients in financial services, telecom, aerospace, manufacturing, and healthcare.
He advises his clients on technical risk mitigation strategies through program development and controls implementation and engineering.
Kevin specializes in projects related to Threat Hunting, Endpoint Detection and Response (EDR), analytics and Security Information and Event Management (SIEM), and Incident Response (IR) activities.
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.
You must be logged in to post a comment.