Training and Exercises.
We're going to talk about tabletop exercises,
penetration testing,
and red, blue, and white exercises in this lesson.
Now, when we talk about tabletop exercises,
these are exercises that use an incident scenario
against a framework of controls or a red team.
So what we're going to do here
is we are going to carry a discussion
of simulated emergency situations and security events.
These are great because they're really simple to set up,
but they tend to be more theoretical in nature
and they don't provide practical evidence
of what could go wrong during a real event.
For example, how long will a particular task take
to complete?
You really can't gather that from a tabletop,
but if you actually go through the actions in motions,
in something like a penetration test,
you'll be able to see that instead.
Now, I've seen a lot of times
when we're doing tabletop exercises
that people start using their magic wands.
Now this is a bad thing to do
because you can start getting the effect
that something that might take a real team 12 hours to do
can really be solved in 30 minutes.
And so when something really happens,
the managers start going,
"Well, in the tabletop, it only took us 30 minutes to solve.
Why is it taking you 12 hours?
I need this system up right now."
And so you start getting this negative training, I call it,
where you start training your senior leaders
to expect things to happen faster in the real world
than they really can.
So just be careful about that
if you're dealing with a tabletop exercise.
Now, when you're dealing with a penetration test,
this is a test that uses active tools
and security utilities to evaluate security
by simulating an attack on a system
to verify that a threat really does exist,
they actively test that threat and vulnerability,
they bypass security controls,
and then finally, exploit those vulnerabilities
on a given system.
When you're doing a penetration test,
you are going to test the system to discover vulnerabilities
or prove security controls are actually working
as they're supposed to.
You're also going to examine the system
to identify any logical weaknesses
that may be there inside the system architecture.
And you're going to interview personnel
to gather information
and see how prone they are to social engineering attacks.
All of these are things you can do
as part of a penetration test.
Now, when you're dealing with a penetration test,
you have to make sure it is properly scoped
and resourced before you can begin it.
Now, what I mean by this is
you have to figure out exactly what is going to be tested
as part of the penetration test.
If you get a penetration tester to come in
and test your organization,
you say, "Just go at the entire organization."
That's not going to be very effective.
Instead, you should tell them,
"Hey, I'm really concerned
about my Windows domain controller.
I want you to see if you can get root access on that."
And that would allow them to be able to identify exactly
what your concerns are
and verify your systems are working properly.
Now, when you're dealing with a penetration test,
you can use either an internal team or an external team.
I personally like to use third parties
who are external to the organization
or a separate internal red team.
I don't like to use my system administrators
to conduct penetration tests.
It's not that they're not smart enough to do it.
It's that they're biased in their approach.
When you have a system administrator trying
to pen test their own system,
what ends up happening is they start trying
to prove the system is secure
instead of trying to prove the system can be attacked.
As a penetration tester,
our job is to go in and find all the holes.
We want to find all the weaknesses.
And the system administrators tend to try to not do that
because they're trying to prove that their work
that they did securing the system is adequate.
And so it's a different perspective,
and that's why I much prefer a third party
or an internal red team be used
instead of system administrators.
Now, if you want to learn more about pen testing,
you should check out the CompTIA PenTest+ curriculum.
In that course, there is a ton of information
on how you can become a member
of the penetration testing team
and learning how to attack these systems
from that outsider perspective.
Now, the last thing we want to talk about in this lesson
is our red teams, our blue teams, and our white teams.
When we talk about red teams,
these are the hostile or attacking teams
in a penetration test or an incident response exercise.
If you hire that third-party team, that is a red team.
They're trying to attack your systems.
When we're talking about blue teams,
this is our defensive teams
in a penetration test
or an incident response exercise.
This is our system administrators.
This is our network defenders.
This is our cybersecurity analyst, like you.
You're going to be part of the blue team.
And then we have the white team.
This is a staff who administers, evaluates,
and supervises a penetration test
or incident response exercise.
They're also going to be responsible
for building the network
if you're going to be using a third-party network
as part of your test.
Sometimes, organizations don't want to do active testing
on their real live networks,
so they'll build a training ground
and they'll put their red teams
and their blue teams,
if they have internal red teams
and internal blue teams,
against each other in this simulated environment.
Well, somebody has to build
and support this entire ecosystem,
and that's what the white team will do.
I like to think about the white team as the referees.
They're also going to be the ones
who are going to report after the event and say,
"This is what the red team did well.
This is what the blue team did well.
And here's what they both did not so well."
That's the role of the white team.