Director of Cyber Defense at Hudson's Bay Company

Several organizations looking to mature their security posture have incorporated the use of a “Red Team.”  For those who may be unfamiliar with this topic, Red Teams started coming into vogue for security programs some time ago and many corporate security teams have hired a team of security professionals to put their security to the test. A Red Team is essentially a team of “White Hat Hackers” whose role is to model a threat actor and attempt to exploit and penetrate defenses.  This is done to simulate an intrusion into your network while holding a “Get out of Jail Free” card.  These folks are using their powers of hacking for good and are intended to help the security team find holes and fix them before the bad guys do.  This is all designed to lower the risk for the company and their efforts are meant to enhance the overall security program’s mission; but are they going about it in the best way for the company? 

I have spoken to cyber and privacy attorneys on this topic and the consensus is that sometimes these Red Teams can do more harm than good.  The idea of threat modeling is a good one.  We need to do that in security organizations to stay ahead of the threats we are hearing about through intelligence.  We certainly need to understand our vulnerabilities and develop speedy ways to fix them, but I think we often miss a great opportunity to enhance the detection capabilities and experience of our SOC teams by not making these exercises into true Red Team/ Blue Team events.  Rather, many Red Teams are doing what amounts to a secret “capture the flag” project and then doing a write-up highlighting their prowess and successful exploitation and intrusion of the network without regard to the unintended aspects of their efforts.  

"​Partnering with the SOC team to enhance detection capabilities is the key to a successful Red Team exercise and a mature security program"

These unintended aspects include creating a new discoverable document that in a worst-case scenario can come back to haunt the company.  Should the Red Team find a vulnerability that is unfortunately difficult, extremely costly, or time and resource intensive to fix, the company may have to put in some mitigation (if they can) and may have to postpone the remediation.  Should a breach occur in the meantime the ensuing litigation that generally follows such an event will include a discovery motion by the plaintiffs and could very well result in handing over this document that identified the risk the company did not or could not fix.  You might imagine how this plays out in deposition.  While it is not guaranteed protection it is best if the Red Teaming exercise is done under the legal department’s oversight and the output becomes attorney work product protected from discovery motions. 

Another unintended result that can happen from a successful Red Team event is that despite all the efforts and progress made through investments in security products, architecture, and personnel resources; the simulated attack was successful.  In the eyes of the CEO and CFO, this could signal a less-than-hoped-for response.  There tends to be this notion that by spending all these funds on enhancing security the company’s network then becomes less vulnerable.  Expectations must be set. Providing information to the contrary without the proper context can sometimes result in shedding a light that is less than favorable when it comes to the ROI on security investments.  We all know what happens then.  Funding for additional projects can get heavily scrutinized for the next budget cycle and may become more about “keeping the lights on” than making improvements. 

Lastly, without the “Blue Teaming” aspect of a Red Team exercise the SOC team does not mature in its detection efforts.  If this exercise is handled in a way that excludes the SOC Analysts who are supposed to identify anomalies along the way, you run the risk of creating animosity among the team and no one wins when that happens.  Instead, the Red Team protocol for the exercise should be staged with indicators where they can educate the SOC team on what they did and determine why it wasn’t identified before they move on in the exercise.  Once they feel this partnership is in play, the security program benefits with increasing experience for the SOC team and by identifying weaknesses in the detection framework that can be worked on immediately instead of waiting for the exercise to conclude with now “egg on their faces.”  The Red Team should not be about revealing the “magicians’ trick” but should be about reducing risk through transparency and cooperative discovery.  It should not be about a surprise “gotcha” that often results when the Red Team operates in secret mode.   

Red teams typically don’t like to operate in this way because it reduces their success, but isn’t that the point in the first place?  The goal for every firm using a Red Team should be for the defensive detections to respond and stop the attack as it is happening as well as to exercise the teams responding to ensure that the process you’ve designed works!  That isn’t going to happen if the SOC team never fully understands what the attack looked like and why they weren’t seeing it.  Finding those areas within the network where detection is missing helps to develop and drive improvements. 

As a side note, Red Teams should not be targeting issues that are in remediation or are already accepted vulnerabilities on the network.  This also applies to company applications or vulnerabilities within the physical security of the building unless the security program truly wants to ascertain whether their acceptance of the risk was in error.  When a company is aware of an issue and has the plan to remediate or has already decided to accept the risk, it makes no sense for a Red Team to exploit that avenue and then claim victory.  They should be instead waiting on the remediation of the issue before attempting exploitation as well as helping the Blue Team identify and exploit attempts on the exposure.  This alternate method “checks the homework” and is a great way to show the ROI on the cost of remediation.   

If the company has no plans to remediate a particular known issue due to cost, pointing it out for documented review via a Red Team exercise only serves to further disclose a weakness and to paint the company practice in a bad light should litigation over the issue arise.  There is no doubt plenty of other avenues of attack that could be tested instead of going for the “exposed jugular.”  Identifying a need for a particular security control because the SOC team could not identify the intrusion in any other way is a much better sell to the CIO/CFO for the additional funding needed for that security improvement.   

In the end, partnering with the SOC team to truly enhance and hone the detection of anomalies is one of the best use cases for a Red Team and sets up real opportunities for the maturity of the security program’s detection capabilities.  To be sure, the use of a Red Team can be a great way to surface unknown issues that could give rise to a security breach.  We all know that threat actors with enough time and enough resources can eventually find a way in.  What makes for a better night’s sleep for a CISO is to know that learning experiences are happening with detection teams and that with every Red Teaming exercise their SOC team is getting better at detection.  There will always be weaknesses in every network environment.  In addition to uncovering previously unrealized exploits, CISOs want to hear stories about the Red Team’s attempt that failed or was detected and (while being careful not to create a false sense of security) shows that detection efforts are working and that is also a great story to tell.