Hello and welcome
to another application of the modern
attack framework discussion
today, we're going to briefly look
at where is the minor
attack framework being used.
So this is just a very short
discussion.
So let's dove right in.
So first and foremost, Miner
is being used with red teams.
And the way that they're using this
is that it can be used or that
they can use the framework as a
common grounds for communication and
research. And so it's a standard
that's been put together by a very
smart group of people.
And instead of reinventing the wheel
and trying to figure out how
to explain different
attack vectors or how to lay out
the different threat groups
or how to discuss
deterrence or detection or
mitigation factors,
the framework does that.
Now, the great thing about this for
red teams is that it gives us
a methodology of essentially
step one to step one hundred so we
can start off in the initial axis
and go all the way through
to impact at the end of of
the framework. And within that,
we've got potential vectors within
each of those where we can test
a system or set of controls.
And so the great thing about that
is, again,
we don't have to think up all
of the different areas.
Now, there is some element of
creativity that comes into things
like penetration testing and what
have you. But it definitely
is beneficial for a red team member
to be able to sit down, look
at a particular software that's
maybe been implemented for either
detection or prevention measures
and then going, OK,
what areas is this really protecting
against?
What can I do?
What mitigating factors do we have
in place and are they working?
And can I circumvent this?
Now that kind of falls into using
the framework is a common grounds
for training. So if I have a new
penetration tester that's a part
of my team, I can use that
framework is kind of a boot camp
to show them, OK, here are the
different ways that we could
potentially gain initial access.
And here are the tools associated
with these vectors and the things
that we can do.
And I can build a
framework for training around
the attack framework if that makes
sense.
And then they can use the framework
as a guide for system testing.
So we already talked about that
briefly.
But essentially, if I have
an internal system, if I
have an external system like a
firewall that we want to test
or if we've got email protections
that we want to test, I can line
up different areas of the framework
with those particular systems and
then say, OK, I'm going to start at
initial access here with the
email server and we're going to try
spearfishing links and we're going
to see if the email server mitigates
that. We want to see if the users
catch that. And if we get on the
system, then
that's success and we're good to go.
And we weren't able to to detect
that. Maybe we need to make some
modifications. But if it
is detected, how did we respond?
What did we do, et cetera.
So the framework definitely lends
itself to help. And red teams
now, we can't make a mention of red
teams without talking about blue
teams as well.
And so with blue teams, again,
the framework is used to identify
common attack vectors, not
reinventing the wheel.
Blue teams can use this framework
to start to understand where their
organizations have gaps in their
controls or in
the security systems that they're
using. Again, solutions
are not the answer as
far as like software solutions or
intrusion prevention or detection
systems. It's not a one stop shop
with respect to protecting
infrastructure, protecting a
business, protecting data, whatever
it is that you're trying to
accomplish.
There's always going to be some kind
of gap or some type of risk that
you will ultimately have to accept.
And so being able to
use this framework to identify the
areas that would be most likely
an entry point into your network
and an attack vector
versus the things that are least
likely, and then you can
do minimal or
barely any controls around that.
This definitely would aid itself
in doing that.
And then you could use the framework
to potentially backtrack and find
a point of entry.
So, again,
things happen.
Maybe we get an alert or some
solution provides us with some kind
of feedback, or maybe we
get a hit off the firewall that
something has happened.
We can then look at the
signs or symptoms and
say, oh, this is indicative of
this particular tool or this
particular threat group or this
particular person.
It looks like they just got access
to the system.
What would be some ways that they
would literally move through?
Where do we need to start focusing
and what do we need to do next?
Framework definitely can provide
some insights and capability there.
So if you get to, unfortunately,
the point where a system becomes
encrypted.
That's kind of the end, that's
impact, so
how can we work that to find
if, if any way
the initial point of entry and what
the threat actor did up
to that point?
Unfortunately, three actors
are pretty good about clearing logs
and making sure that they try to
cover their tracks if they're being
sneaky.
So it may be difficult or impossible
to find those things unless you had
solutions in place that stored
log information.
And then from that point, you could
do some review of that
information and then potentially
track it all the way back to the
initial email or whatever the case
may be.
And then they can use the framework
to assist in the implementation of
compensating or mitigating controls.
And so that's kind of been the
mantra that we've discussed between
both red teams and
blue teams, is that
you can use this framework.
These are common attack vectors,
common attack areas in ways
that each of these phases,
that threat actors are getting into
systems, damaging systems and
laterally moving through systems.
So, again, you could start mapping
controls and mitigating factors
into your overall security
posture by using the framework.
Again, you could
implement every control
across the board in every
one of these categories.
And every one of these attack
vectors doesn't mean that you
eliminate all risk threat.
Actors are constantly changing their
tune and capability and they're
always evolving. So, you know,
it's about finding the most high
risk assets and the most high impact
areas for the organization
and then looking at the potential
ways that a threat actor could gain
access to that system and then
applying those mitigating,
compensating controls as well as the
detection pieces
so that you could, if those things
fail, see one of three actors
on a system.
Now we have to mention vendors
and all of this, and it's definitely
something that we've started to see
vendors using to kind of square
up their solutions or softwares
against here the areas within the
modern tech framework that we
provide these protections.
And here's what we defend against.
And so it allows a vendor to clearly
define where their solution provides
prevention or detection measures,
which is great, because I've
seen vendors that have provided a
solution that say we protect against
network intrusion,
OK, of what type of what kind
and what ways from what vectors,
what measures.
So it allows consumers
to know if a product is overlapping
with another. I've seen endpoint
detection softwares
that also provide antivirus
capability and an
organization will run a
standalone antivirus
and this end point detection
product that does some type of
monitoring above and beyond what
normal antivirus would do.
Well, that's an overlapping
capability.
If the particular
antivirus protection is signature
based and it's dollars four dollars,
it may not make sense to have both
of those solutions.
And if the endpoint detection
solution provides both
additional containment
and eradication capability on top
of the antivirus
components, that may be a cost
savings and it may provide better
protection. So it's
a great way to see where things are
overlapping.
It can again be beneficial and
improving overall control coverage
throughout the environment, as well
as eliminating unnecessary costs.
And then red teams can do proof of
concept attacks against the
solutions, knowing what it should
defend against.
Right. So I've seen instances
where I've gone into an environment
working with a particular
intrusion detection and prevention
system, and
the entity says, you know, will
alert in fifteen
minutes. When there's this level
of activity, we alert, you
know, if you're doing these types of
things and these types of attacks.
So we got permission from the client
and we ran a proof of concept
against the environment with the
solution in place, and we threw the
kitchen sink in it.
What did we find that the reporting
timeframe was not met?
The solution provided little to no
contextual information on the actual
activities that were performed
against the environment.
And we were able to use that to go
back to the vendor and then ask
for either modification,
improvement, cost savings, whatever
the case may be.
But we were able to test against
those specific
vectors in specific areas.
And so if your vendor
can't break down for you
what it is that they're actually
protecting against, if they say
everything,
if you've got an everything
solution, please let me know.
Reach out to me through cybering
and I'll be happy to look at that
with you and validate that
that is the case and we'll work
together. But I'm saying that
because I've never heard of a
solution that takes care of
everything within the security
spectrum, it's just not
out there.
So those are the three main
areas that we're looking at with
respect to the minor attack
framework being applied.
It can be applied in other areas
and other facets, whether it be
through. Research institutions
for folks that do attack type
research or threat group research,
whatever the case may be, these are
just the core areas that we're
mentioning in this particular
discussion today.
So with that in mind, I want to
thank you for your time today, and I
look forward to seeing you again
soon.