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.
The hacker Barnaby Jack has died in San Francisco, a week before he
was due to show off his hacking techniques on attacking implanted heart
devices that could kill a man from 30 feet away.
