Lately, I’ve been doing a lot of reading on some less technical topics and I ran across “Red Team: How to Succeed By Thinking Like the Enemy” by Micah Zenko. If you are like me, you’ve probably thought of the red team as being a penetration test group or some kind of adversary simulation. You know, red teams are the pretend bad guys and blue teams are the good guys defending against them. Reading Micah’s book altered my view of what red teaming is. I learned about a world of non-technical red teaming and how that can be applied to our organizations.
At its core, red teaming is the idea that we are going to look at things critically and with an eye towards an alternative point of view. Conventional thought may lead you to believe that if you do X, then Y will be the result(s). Because everyone believes this to be true, organizations make plans based on it and really don’t challenge it much. A generic example may be “if we buy advertising, we will make more sales.” Red teaming this would question that point of view and may come up with alternative results based on following questions through the process. Questions like this may be asked:
- What if buying advertising doesn’t result in enough sales to justify the expense?
- What if buying ads in this particular format or delivery mechanism turns potential customers off?
- What if the desired revenue level is never reached? What impact will that have on our future plans?
In the world of cybersecurity and penetration testing, this could look something similar to the following:
- This server (or service) isn’t really important so we don’t need to worry about patching it yet.
- We’ve got a SIEM and it will let us know if anything important is happening.
- Our firewall rules are effective at preventing an attacker from moving through the network.
The red team asks…
- What if that unimportant server has an important account logging into it? What access could that give us?
- What if that unimportant server has different network restrictions in place and being on this system would give us access to more important systems that I can’t get to right now?
- When would the SIEM alert you and would it be in enough time? Would anyone even read the alerts and how would they respond?
The list of What Ifs can go on and on. In penetration testing, we would then start testing these scenarios to see what would happen. We want to determine what the impact to the organization could be if an attacker ran a string of these What Ifs together and would they be able to get access to the victim’s secret sauce. And we want to verify that controls are effective and perform as we expect.
I believe that there is value in taking in some of the perspectives and techniques that red teaming employs. We don’t have to do a full penetration test or red team exercise (though these are useful) to start getting some benefit from this discipline. Simply sitting down with a few other people and questioning the assumptions or understandings that are being used in projects can be very helpful. The possible results at the end of these scenarios may not actually occur, but a number of the questions and answers that will be encountered during the process can spot risks that we may not have ever noticed. We can then take steps to minimize the impact of these risks or the likelihood of them ever occurring. We can be better prepared to respond if the unlikely suddenly becomes reality because we have at least thought through it before hand and kicked around how we could respond.
I’d recommend reading or listening to Micah’s book. I enjoyed listening to it quite a bit and I learned a lot. I’d also recommend looking at other resources for red teaming. I ran into the Red Team Journal as a result of Micah’s book and found some of the things there to be very thought provoking.
Jason Wood is a Principal Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at email@example.com, on Twitter @Jason_Wood, or visit the Secure Ideas – ProfessionallyEvil site for services provided.