Defining Scope, Rules of Engagement, and Approving Authorities
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Time
8 hours 5 minutes
Difficulty
Intermediate
CEU/CPE
9
Video Transcription
00:00
>> Hello and welcome to Lesson 3.2,
00:00
defining scope, rules of
00:00
engagement and approving authorities.
00:00
In our last lesson,
00:00
we introduced the adversary
00:00
emulation key planning components.
00:00
These included such components as objectives,
00:00
scope, rules of engagement, and so on.
00:00
In this lesson, we're going to explore
00:00
the key planning components in detail,
00:00
so you understand exactly what they are
00:00
and how to discuss them with network owners.
00:00
By this point, we know
00:00
our engagement objectives and
00:00
also the adversary TTPs we want to emulate.
00:00
But how do we take that information and shape it into
00:00
a workable adversary emulation project?
00:00
Essentially, we need to have
00:00
one or more planning meetings with the network owners.
00:00
These meetings will allow us to discuss and define all of
00:00
the pertinent project details as they
00:00
relate to these key planning components.
00:00
For example, what devices will we assess?
00:00
When will the adversary emulation activities
00:00
occur? and so on.
00:00
As we go forward,
00:00
we're going to explore each of
00:00
these planning components in greater detail.
00:00
What do we mean when we are
00:00
talking about engagement scope?
00:00
In this context, scope identifies organizations, users,
00:00
and devices upon which
00:00
adversary emulation activities are permitted.
00:00
In practice, this is often a list of IP addresses,
00:00
subnets, or host names.
00:00
But it can and should often
00:00
include lists of user accounts,
00:00
different organizations or
00:00
business units particularly for attacks
00:00
that might involve some level of
00:00
social engineering or other user-driven attacks.
00:00
Now when discussing engagement scope,
00:00
I often ask the network owners to
00:00
include any engineers local to the network.
00:00
These can be system administrators
00:00
or any other individual that has
00:00
detailed technical knowledge about
00:00
the target network environment.
00:00
You want these people at the table,
00:00
because often they could tell you exactly
00:00
which devices should be in scope for an engagement.
00:00
You might also try asking these individuals
00:00
for network diagrams,
00:00
which can be very helpful assuming they're accurate.
00:00
You can also discuss which systems are
00:00
particularly high value to the organization.
00:00
Meaning these might be at greater risk
00:00
of adversary compromise.
00:00
Finally, you also want to identify any devices
00:00
that should be explicitly out of scope.
00:00
For example, systems that might be in
00:00
the network but are actually owned by a third party.
00:00
You're also going to want to discuss
00:00
schedule with the network owners.
00:00
Now the schedule should define
00:00
the dates and times in which
00:00
adversary emulation activities occur
00:00
and also when final deliverables are expected,
00:00
for example, any presentations or reports.
00:00
Discussing the schedule early on helps keep
00:00
everybody involved in the project on the same page.
00:00
He'll also add that it helps
00:00
D conflict adversary emulation activities
00:00
against legitimate business operations.
00:00
I once had an engagement for the space community,
00:00
and throughout that engagement they had
00:00
periods when scheduled contacts
00:00
would take place between
00:00
the ground station and the space vehicle.
00:00
During those scheduled contexts,
00:00
we were not authorized to perform
00:00
any adversary emulation activity
00:00
in order to mitigate potential risks.
00:00
To that point, you want to work with
00:00
the network owners to identify periods in
00:00
which adversary emulation activities
00:00
should absolutely not occur.
00:00
Next, you want to work with the network owners
00:00
to define the rules of engagement.
00:00
Essentially your rules of engagement,
00:00
sometimes abbreviated ROE,
00:00
defines acceptable adversary emulation behavior.
00:00
For example, what TTPs are permitted during
00:00
the engagement and if you're running
00:00
any high-risk TTPs like encryption for impact,
00:00
what mitigations can be applied to drive down the risk.
00:00
You also want to take the time to
00:00
talk through sensitive situations.
00:00
For example, what do you do if you
00:00
identify an intrusion in progress?
00:00
This is sometimes known as cohabitation of malware.
00:00
As another example, who do you notify
00:00
if you accidentally deviate from the approved scope?
00:00
For example, maybe you're sending out
00:00
phishing emails to authorize targets,
00:00
and one of the users
00:00
forwarded those emails across the company.
00:00
Then there are other sensitive situations like
00:00
disclosing privileged or sensitive information,
00:00
or possibly observing a legal activity or
00:00
unauthorized activity in progress.
00:00
One of the things I like to do on my engagements is use
00:00
the attack matrix to list
00:00
the TTPs we plan to execute during the engagement.
00:00
I find that this is a great opportunity
00:00
to build confidence with
00:00
the network owners as you can show them
00:00
what TTPs you want to execute,
00:00
and very clearly show how those TTPs are based on
00:00
real-world events that may
00:00
be relevant to the network owner.
00:00
I'll also add that later
00:00
after you execute the engagement,
00:00
you can use these matrices to build scorecards or
00:00
heatmaps that basically visualizes those TTPs,
00:00
the network defenders were able to detect and prevent.
00:00
There's a lot of information that can
00:00
go into the rules of engagement.
00:00
On this slide, I tried to offer you some key points that
00:00
I find help ensure
00:00
a reasonable and safe rules of engagement.
00:00
Always stay in scope.
00:00
Leave the network, the you found it.
00:00
Protect customer data both at rest and in transit.
00:00
Coordinate high-risk activities and
00:00
line up resources to mitigate risks.
00:00
Notify the network owners should you
00:00
encounter any sensitive situations.
00:00
Now, we've already talked about the importance
00:00
of getting explicit written permission
00:00
to conduct adversary emulation activities
00:00
because this is what helps keep you out of trouble.
00:00
Some other things to be aware of.
00:00
Make sure whoever is giving you permission has
00:00
sufficient authority to authorize the engagement,
00:00
and never assume you have the authority to practice
00:00
adversary emulation in a network
00:00
that you do not personally own.
00:00
Otherwise, you could risk
00:00
serious legal and or criminal action.
00:00
On this slide, we provide you another course resource.
00:00
This is an example permission memo.
00:00
Now this document is commonly used for getting
00:00
written permission to conduct
00:00
adversary emulation engagements.
00:00
Just like our planning template,
00:00
this document is available for your use on GitHub.
00:00
Do get it blessed by
00:00
your legal counsel before using it operationally.
00:00
Our last key planning component
00:00
is the communications plan.
00:00
Very simply, the communications plan describes how
00:00
the adversary emulation team
00:00
will communicate with the network owners.
00:00
This should include details such as when will
00:00
routine communications occur and also describe how,
00:00
for example, will it be a phone call,
00:00
video call, or an in-person meeting?
00:00
This is also a good opportunity to
00:00
discuss how transparent communication
00:00
should be between the adversary emulation team
00:00
and the network defenders.
00:00
For example, should communications
00:00
be open and collaborative,
00:00
similar to a purple team or should they be opaque,
00:00
also known as black-box,
00:00
which is more indicative of a real-world adversary?
00:00
As part of the communication's plan,
00:00
I always like to create
00:00
a call roster with everyone's pertinent information.
00:00
They should be given to all project stakeholders.
00:00
If at any point there are problems,
00:00
everyone on the project knows who
00:00
the different contexts are and how to get a hold of them.
00:00
That brings us to the end of Lesson 3.2.
00:00
During this lesson, we described
00:00
the purpose of each of the key planning components,
00:00
and we understand that these components are necessary for
00:00
conducting professional adversary emulation projects.
00:00
Finally, I'll leave you with some sound guidance that
00:00
has served me well in my adversary emulation career.
00:00
Always stay in scope,
00:00
always follow the rules of engagement,
00:00
and always get explicit written permission to execute.
00:00
This concludes Module 3, adversary emulation planning.
00:00
If you would like to prove your mastery of this material,
00:00
please feel encouraged to visit
00:00
us at the MITRE ATTACK Defender
00:00
skills hub and earn your Module 3 badge.
Up Next
Planning TTP Implementations (Lab 4.1 Overview)
10m
Planning TTP Implementations (Lab 4.1 Walkthrough)
30m
Implementing Adversary TTPs (Lab 4.2 Overview)
10m
