Hello and welcome to another
application of the minor attack
framework discussion today
we're looking at a trusted
relationship.
And so this is going to be a little
different than supply chain
compromise.
And we'll get into that shortly.
Now, let's go ahead and touch
on the objectives for today's
discussion.
So we're going to look at a trusted
relationship, which is the topic
of our discussion today versus
Supply-Chain compromise.
So those are going to be two totally
different things and we're going to
touch on those shortly.
Now, we're also going to review an
example of managed
service providers.
We're going to discuss that.
And a high level we're going to talk
about mitigation techniques and
detection techniques as well.
And you're probably starting to see
a trend in those last two there, but
definitely worthwhile.
So trusted
relationship versus supply chain
compromise.
A trusted relationship
leverages the access a third
party has to the potential victim
systems, where a supply chain
compromise involves the manipulation
of trusted tools or code
that is then delivered to the
victim's environment.
So to shorten that trusted
relationship is direct
access to systems or data
supply chain compromise is access
after the victim installs a
malicious update or uses infected
hardware.
So that
is the key difference.
If you get a piece
of hardware that is infected and
you install that piece of hardware,
that is a supply chain compromised.
If you have that vendor of
the hardware, they have remote
access to your systems to provide
support and things of that nature.
And that account that they use
is then used to
access data or to
damage your systems.
That is a trusted relationship.
OK, so those are the primary
differences there. One is kind of
direct access and then one
is kind of trusted
relationship where you install
malicious updates or use infected
hardware.
So a great example of this that
we've heard a lot about.
There were even some releases
from several agencies on
managed service providers needing to
shore up security practices and
things of that nature.
So hackers working for
China broke into networks of eight
major MSPs and technology
service providers based on a rooters
report.
So these attacks led
to damages in the given areas.
So banking, telecom, medical
packaging, manufacturing, consulting
and the way I like to think of
trusted attacks
or trusted relationship
as far as this factor is concerned,
if I have a medical
record, that medical record
has a certain value.
Well, I do have a medical record
now, but that medical record has a
certain value on
the black market.
Right? So that record
can be sold for a sum of X
dollars and that's
it.
But.
If a health care provider
were compromised instead of myself,
because imagine a threat, actor
would have to figure out my
email address, they'd have to know
how I received my medical records.
Maybe they compromised my
password manager.
Whatever the case may be, they
go through all that work.
They get into an account,
they're able to get my medical
information and that's
it. That's a one for one transaction
that takes a lot of effort and
energy.
But if they're able to compromise
my health care provider.
They now have access not just to my
medical records, but the medical
records of any individual that is
serviced by that health
care provider.
Likewise, if it's medical equipment
and they've got a relationship
with a number of hospitals, there's
account numbers, payment card
information, whatever the case may
be. And if they compromised
banks, then that bank has
numerous accounts that they service,
et cetera.
Now you want to keep that game
and it's like a pyramid,
essentially. So if I if I'm
getting into banks and things of
that nature and
they're here in the middle, OK,
and that bank represents a set of
data that then gives me access.
And I'm sorry this pyramid stinks.
It gives me access to all the client
information. Right.
So I could do a one for one
transaction here.
Right. Or I can do a one to
many here by compromising a bank.
Right.
But if
there is a managed service provider.
And I'm putting them at the top of
the pyramid because their level of
access is one
to many banks,
one to many health care providers,
one to many manufacturers, one
to many
banking, medical packaging,
whatever the case may be.
And so now if I focus
my effort and attention on this
trusted relationship,
the reward is so much
deeper than just
going after a bank individually
or a manufacturing firm or
individual persons.
So this is definitely something
that as we continue
into twenty twenty one.
Twenty two, twenty three, we
want to remember that.
The individuals that we give access
to our systems and that we allow
to manage our systems need to hold
themselves to the same or higher
standard ourselves,
because if they are compromised,
it's not just about our businesses
data, which is the most important,
of course, but the business
data of any entity
they serve the client information of
any entity they serve.
And so that's why I trusted
relationships are
definitely dangerous as
far as the ability of a threat actor
to take advantage of that
and get into those systems.
So let's talk about mitigation
techniques and we're going to use
the map.
Example is one of those
so we could look to implement proper
network segmentation.
And so what we mean by that is, is
that if an entity
or person needs remote access,
that remote access is limited
to a network segment.
Therefore, they won't be able to
easily, if they're compromised,
spread to other systems.
OK, but most
of the times with managed service
providers, they have agents on every
system so they can get to
any segment or any network or
any of those things.
And a lot of times server
infrastructure and things of that
nature
is able to reach any segment
of the network, like a domain
control or something of that nature,
because it has to service
all systems in the infrastructure.
But if we've got
a software vendor or something of
that nature who only needs
access to a single system that's on,
you know, a designated network
segment and they don't need
administrative privilege to do what
they need to do, then
we would definitely want to keep
those systems segmented
and to ensure that we do what we
can to in the event
that that relationship was
compromised and that the threat
actor got into a system, we could
minimize impact, hopefully,
and then it would definitely be
beneficial to keep the time frame
and permissions sets that third
parties use limited.
Now, that's tough a lot of times
with managed service providers
because they're updating systems,
they're implementing service
accounts, things of that nature.
But what I've seen is
the use of domain
administrative accounts as service
accounts when
in all reality they should be
using service accounts in
a fashion that limits permissions,
but allows them to achieve the goals
and then with domain administrative
accounts.
We should definitely be looking to
limit when the service
provider can access systems,
especially if you've got a software
vendor and that software vendor
only uses that account, let's say,
once a quarter to do updates,
that account can be disabled or
can be turned off
if they need administrative
privilege or any privilege until
they need access.
And that can be coordinated and
planned.
Same thing here. It's not
convenient, per say, for managed
service provider to
have a limited time frame in which
they can do work.
But if you
say, hey, I only want changes made
to my network between the hours of
4:00 p.m.
and 7:00 p.m.
Eastern Standard Time because
we're busy from
6:00 a.m.
to three fifty
nine p.m.
Eastern Standard Time.
So your account as far as being
able to get into our system should
only work then unless we.
Enable that account and allow
access,
then that could be understandable,
you could limit the timeframe in
which that account can function and
then it limits the ability of a
third actor to act outside of
those parameters.
And it runs nicely into
some of our detection techniques.
Now, as far as detection
techniques for these types of
activities, you can monitor activity
of designated third party accounts,
not using third party controls.
And this becomes important
for a number of things.
You want to have a system in
place that logs
or pulls when
the third party account is used
and it's designated to
a separate system that maybe even
the third party doesn't have access
to. And the reason for this is not
a lack of trust of the third party.
But then if something happens
and that account becomes suspect
for some reason, the threat
actor would not be able to access
those logs and that information and
therefore would not be able to
tamper with that information.
And you could then use that to
better understand what happened
and what's going on.
If you rely on third party controls
in the third party becomes
compromised.
How are you then able to
actually figure out what happened?
The answer is the likelihood is that
you wouldn't and then implement
network and endpoint monitoring
tools that can report on anomalous
activity. Again, this is kind of
a trend in what we're talking
about and detection techniques, but
it's going to reoccur because
these tools are becoming more and
more prominent in
how we combat trained actors, how we
become aware of anomalous activity.
And so if we designate
a range of time in which an account
should not be used
and someone attempts to access the
account and we get an alert
that allows us to act much quicker,
that makes us aware of the activity
much quicker and so we can jump up,
see what's going on, called a third
party, see if there was a new
person maybe that tried to get in
the system or no.
In fact, no one is
or should be using that account at
this time.
And now we need to investigate and
figure out what is going on.
So let's do a quick check on
learning.
True or false, a
trusted relationship and a supply
chain attack compromise are two
different initial access factors,
according to Minor.
All right, well, if you need
additional time, please, by all
means, pause the video and take a
moment.
So a trusted relationship
and a supply chain
compromise are, in fact,
two different initial
access factors, according
to Minder's. So this statement
is a true statement.
They are not one in the same.
Remember, supply chain compromise
has to do with hardware
or software being manipulated and
then installed by
the end user or the client.
Trusted relationship is when a third
party has direct access to data
or systems that could be
compromised, used to then
access their systems as though they
were the vendor.
Therefore, trusted relationship is
a separate vector in itself.
So let's go ahead and look
at our summary. So in summary, today
we reviewed the differences between
trust, trusted relationship versus
supply chain and we just talked
about that.
We reviewed the example of the
managed service provider.
Remember thinking about that pyramid
of access?
Managed service providers, managed
security providers, global software
providers probably have access
to numerous
environments, whereas if
a threat actor were to compromise a
single entity like a bank
or a health care provider or a
hospital, they will still have
a high payout.
But they will not have access to
all of the different types of
systems that those entities could
bring. And then targeting
individuals is much
less rewarding and far
more cumbersome than attacking these
bigger entities.
That doesn't mean that you're off
the hook.
It just means that
more sophisticated threat actors are
going after targets that will
provide them a higher payout.
We reviewed some mitigation
techniques, such as limiting
third party account access times,
as well as network segmentation.
And then we reviewed detection
techniques such as endpoint
detection, endpoint and
intrusion detection software and
services, using those to
alert on third party account
activity, as well as potentially
keeping separate log files
in a location that is not accessible
by the third party to ensure
that if something happens, we're
able to trace back steps
and see what actually occurred.
So with that in mind, I want to
thank you for your time today, and
I look forward to seeing you again
soon.