This is module for less than
three, researching organizational
capabilities and constraints
and determining tradeoffs.
This lesson, we have three
objectives for you to learn
how to identify your organizational
capabilities and constraints,
identify how to tailor trade offs
for your enterprise, and
understand how to make customized
defensive recommendations.
So this is step three of our
process, research,
organizational capabilities and
constraints,
every organization is
going to have
different aspects that are easy
or harder for them, depending
on some of the things that
they already have in place,
things about their workforce and the
organization itself.
So these are going to be things like
what data sources, defense is
mitigations are already collected
in place.
So if you're already doing
something, already doing something
that's most able to take
care of how an adversary is using a
technique, it may be really
inexpensive or simple.
So maybe something like
if you're already collecting the
data sources, possibly some new
analytics on your existing sources.
So just adding something to your
SIM.
So you can also take a look at
Tool's what products are
already deployed that might have
additional capabilities.
So do you have products
in your enterprise that are already
able to take some of these defensive
measures or match things that we've
said are going to work for a
particular technique, but maybe a
feature isn't turned on or it just
needs to be tuned to match
the particular thing.
So this could be something like
it's able to gather new data sources
or implement new medications
if we add on the right
feature or if we turn on the right
capability for it.
Are there things about the
organization that may preclude
responses, are there things
that are just not on the table for
us? Because the organization
maybe rules we have on data we
are not allowed to collect
maybe something about our users
where their patterns may make
something impossible or easy,
and this could be stuff like user
constraints and usage patterns.
So we've gone through with this
user execution example,
so I'm going to give some notional
capabilities and constraints
for our fake organization
so that we can work through
this process.
So notional capabilities,
let's say that our organization
already has Windows events.
So when this event logs
already collected to Assim but
not process info.
So we've got sort of the right types
of data sources, but not necessarily
what we actually need.
The organization is currently
looking at application control
tools.
It's a highly technical workforce.
So ones that already understand
maybe some of the threats,
there's already an email file
detonation appliance in place.
So this has already been bought,
already been installed,
like most organizations
going to assume that we already have
antivirus and all endpoints.
OK, so these are the things that we
have in hand that
are going to enable
certain responses and
make certain responses more easier
than others.
So some notional constraints for our
fake organization.
Let's say that our SIM
is close to our license limit
that in order to get a
lot more events coming in to add
new windows, event log
types might be prohibitively
expensive to get up to the next
level of license.
A large portion of our
organization, let's say, are
developers.
So people who run arbitrary binaries
and that are files and transmit
are usually encrypted
at the point that they go past
a new network intrusion prevention
system.
These are all notional.
These are just getting so that we
can actually take a look at
how some of these would fit into
specific trade offs.
Your organization is going to be
different.
So how do we take those, so
how do each of the options
we identified in earlier steps
now fit into our organization
so we can look at example
positives and negatives for
how each of these options
will work with our organization?
So things like maybe
the options we came up with
are able to leverage existing
strengths, tools and data sources.
So some of that information that we
were just thinking about, about our
organization, it
also could very well fit with a
specific threat.
If we've got an option
that exactly matches up
with one and adversaries trying to
do to us, well, maybe that wants to
rise to the top of our
priorities.
There are also some negatives that
can come up as we're going
through each of these options, so
maybe it's something that's going to
be really expensive for us but
doesn't really mitigate much
risk. You know, it's not actually
helping us all that much.
It could also be a poor cultural fit
with our organization.
It could be something that is
going to make it so that our users
can't get their job done or is
extra bad in our
particular industry.
Each option is going to be
highly dependent on your specific
organization.
So continuing to work through
the example we have
and the defensive options we've
gathered and some of the constraints
that we've put together for our
national organization,
so defensive option that we came
up with is increased
user training around clicking on
attachments.
OK, so this covers
the most common use case.
It covers spearfishing where
we're trying to keep people from
clicking on attachments.
We said that we have a technical
workforce, so they
may be very likely to understand
this and may make good sensors
for incoming malware.
As a con, though,
it's, you know, our workforce.
We're putting through more training.
People are sick of security
training. They don't want one more.
You know, we've already given them
some training on spearfishing
in the past.
And so, you know, may, may or may
not work as a trade off.
We said we can do enforcement of
application control now.
Sounds great on paper,
you know, we're already looking at a
solution for this.
We said in our notional
most of the binaries of concern that
are coming in from malicious actors
are not familiar binaries.
Their new hashes, they're
brand new things.
And so application control is likely
going to stop them.
Well, we mentioned that we
have a lot of developers,
developers are creating a lot of
their own binaries.
And so we might heavily impact
our population if
we prevent our population
from running arbitrary binaries
and we may have a high support cost
in order to add these developers
binaries into our application
control solution.
We gave us an option monitoring
command line arguments to create
an analytic looking at the
information coming in,
what we said, we are collecting
witness events already.
So we've got know where those
are going to fit into already
feeding into a SIM.
But we also said in our constraints
earlier that
we really couldn't add more
logs to our existing license.
It probably was going to be an
unacceptable cost
antivirus.
Well, we've already got it.
So, you know, there's no reason
to get rid of it.
But, you know, the downside is
we already have it in place and it
wasn't working out.
So, you know, limited, limited
coverage
we suggest as a possibility
installing endpoint detection
response product.
So could give us an excellent
endpoint visibility without greatly
increasing log volumes.
But we don't already have this is
going to be a big procurement
and it's possibly going to
be a really expensive one.
You know, if we want to go there,
we said we have a email detonation
appliance.
So as a pro, it's already
in place.
But as a con, we also
said that data is encrypted in
places where it's going past our
appliances.
So we might not have full visibility
into our inbound email.
So we've now built up
most of the information we need to
get to the finish line,
learned how to identify
organizationally unique capabilities
and constraints, the sorts of
information that are going to
impact how we can respond
and detect different techniques
and sub techniques.
You've talked a bit about how to
tailor trade offs for your
enterprise. What sorts of things to
look for that are
going to impact what's easy, what's
hard, what's doable and what's not
doable for your organization.
And gotten a bit into
how we can pull those together
into how they work with our
different defensive options and
looking at the pros and cons for
each one.