Red Team Testing: Debunking Myths and Setting Expectations

The term "cyber" seems to be overused in every corner of the information security industry. Now there is a new buzz phrase in computer security, "red team engagements.” Supposedly (to get "cyber" on you), you can have a red team test, and it will help move your organization in the correct “cyber direction.” But what is red team testing really? And what is it not? In this post I’ll try to make some sense of this potent term.

The red team concept has been around for ages. It started as a military term for a team dedicated to simulating all of an enemy’s activities, including everything from methodology to doctrine, strategy, techniques, equipment, and behaviors. The red team was tasked with mastering how the adversary thinks and operates, and then executing the enemy’s strategies and tactics in the field. This allows your own forces to experience what it would be like to combat this enemy in real life − without the risk of getting injured or killed. 

 

Fast forward 10-12 years and red teams are being used in civilian industry as well as in the military. In private industry, red teams simulate adversaries (not necessarily foreign armies) that could impact the organization. The adversary could be criminals vying to get your money, competitors trying to get their hands on your latest designs, or random attackers who want to exploit, destroy, or simply harm your organization. Their motivations can range from social activism, political strategy, financial gain, and so on.

 

When IOActive is asked to conduct a red team test, our main goal is to accurately and realistically simulate these types of adversaries. So the first, and probably most important, element of a red team test is to define the threat model:
 

·      Who is your adversary?

·      What are their motivations?

·      Which adversaries are you most afraid of? (This is usually any party that wants to put you out of business.)

 

Defining the threat model is crucial to the success of a red team engagement, because it determines the value your organization will get from the project.

 

After we articulate the threat model, the fun part of the engagement begins.

 

Fun? Yes, because in the real world most tests, such as penetration tests do not really depict a persistent adversary. Instead, engagements such as pen tests simulates specific strategies that a persistent adversary will use as part of an overall attack.

 

The red team engagement, on the other hand, includes all possible elements that an adversary might use in such an attack (which is why it is often referred to as "no scope” or "full scope” testing).

 

In this context, everything including your employees, your infrastructure, the physical office locations, your supply chain − that's every third party you use as part of your ongoing operations  − and more. When developing attack scenarios for red team engagements, every element has to fit in perfectly. 

 

Think of it as an "Ocean's Eleven" type of attack that can include:
 

·      Social engineering

·      Electronic and digital attacks

·      Bypassing physical controls

·      Equipment tampering

·      Getting into the supply chain to access your assets

·      And more

 

This is full scope testing. Unlike in other types of engagement, all or almost all assets are “in scope".
 

Note: Red team engagements do commonly use "reverse scoping" techniques to identify assets that are critical to operations and the types of tampering, access, or removal that are off limits for these assets. These sensitive assets are still in scope. But reverse scoping defines and restricts actions that may substantially disrupt operations.)

 

So far this sounds like a fun game. But hold on, it isn’t just about the attack. What I like the most is seeing how an organization’s ongoing security operations handle red team attacks.

 

In a red team test, very few people in the organization know about the test, and even fewer actually know when the test will happen. This means that from an operational security view, all red team activities are treated as if they involve a real adversary.

 

We gain a lot of insights from the actions and reactions of the organization’s security team to a red team attack. These are the types of insights that matter the most to us:
 

·      Observing how your monitoring capabilities function during the intelligence gathering phase. The results can be eye opening and provide tremendous value when assessing your security posture.

·      Measuring how your first (and second) responders in information security, HR, and physical security work together. Teamwork and coordination among teams is crucial and the assessment allows you to build processes that actually work.

·      Understanding what happens when an attacker gains access to your assets and starts to exfiltrate information or actually steals equipment. The red team experience can do wonders for your disaster recovery processes.

 

These are some of the rewards and benefits of a red team test. As you can see, they go well above and beyond what you would get from other types of focused tests.

 

I hope this explanation eliminates some of the confusion about red team testing that I have seen lately in Internet discussions. I am not saying that there is no value in pen tests, social engineering engagements, physical assessments, or anti-phishing campaign. However, to see how all of these different types of security considerations work in the real world, they also need to be considered as part of a larger (and relevant) context so that you can see how well your organization is prepared for any type of attack.

 

Last but not least, if you'd like to get hands-on training in how red team engagements are conducted, considering attending our two-day Red Team Training (https://www.blackhat.com/us-13/training/red-team-training.html) at BlackHat 2013 in Las Vegas.