May 7, 2019 | Posted in Red Teams, Purple Teams, and GRC by Tim Wainwright and Kevin Foster

 

This article begins with the difference between Designing vs. Describing the cybersecurity program with NIST CSF. I then explain how in a mature program, NIST CSF helps us describe the separate purpose and sequence of Red and Purple Teams.

tl;dr: 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.

In our conversations with CISOs across industries, most are either designing their programs with NIST Cybersecurity Framework (CSF) or describing their program in terms of CSF.  We do think designing and describing are different. Designing means CISOs are assessing their program against CSF and still finding gaps against its fairly foundational controls. Their program is primarily organized by CSF’s Functions (Identify, Detect, Protect, Respond, Recover). Describing means that the program is mature and resources are specifically aligned to well-thought out and executed capabilities. For example, a mature Hunt capability loses its well-deserved swagger when crammed as one bullet under the Detect function. Instead, it may be part of a strategic Cyber Threat Intel team, which is more descriptive and inspiring to the team in the trenches. We think few CISO direct-reports have their responsibilities sharply drawn around one of CSF’s five Functions (“my job is Protect..?”). In a mature program, NIST CSF becomes only one of many lenses to communicate the scope and completion of the cybersecurity program – a view better reserved for Audit, Board and Execs but otherwise not practical for day-to-day guidance or division of responsibilities.

For organizations ready to describe their program in terms of NIST CSF, justifying significant investments in controls, processes and tools is not always obvious. NIST CSF itself is sometimes confused – is “vulnerability management” an Identify, Protect or Detect control? We could argue for any placement but CSF is indecisive and instead triplicates the topic (ID.RA-1, PR.IP-12, DE.CM-8). We wish they could have just picked a spot, but let’s instead talk about two other very important controls: Red Teams and Purple Teams. We think CSF helps to justify them both and describe their distinct purpose.

My last article makes the case that most organizations do Red and Purple Teams in the wrong order.  Kevin and I firmly believe that Purple should come first, and I’ll explain why I think NIST CSF agrees. At an FS-ISAC Summit presentation last week, 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.