Hello and welcome to
part two of our supply chain
compromise discussion.
Let's go ahead and pick up where we
left off
through on that. So let's talk about
some mitigation techniques here for
for us, for businesses,
for vendors, whatever the case may
be.
Now, for us as practitioners,
we want to look for unused
dependencies.
So if something isn't serving a
purpose or if it's not providing a
benefit or if it just
seems to be out of place in software
or whatever the case may be,
we'd want to remove that or not use
it. And then we want to look
at previously vulnerable
dependencies. That's important.
So if there was a TV
or some type of release
by the vendor that indicated there
was vulnerable components of the
software and
it is for version one point three
and below and we're
running version one point one,
then we need to look to maybe do
some updates and get it current
removing unnecessary components.
So versus dependencies.
If there are components of the
software, like if there are
APIs that we're not going to use,
if there are functions
and features that we're not going to
take advantage of, if there are
compartments that we don't need to
use in a particular suite of
software, then we can
reduce the attack vectors or the
capabilities of a threat actor
potentially by not running
every single piece of software.
If we can go through and
do advanced installations
and install only the components that
we're going to need to function and
to be productive, then that would
be the best way to cut
down on capabilities here.
Now, if you have the
capability manual or automatic
code review is something that
you could do as well.
There are some tools out there for
reading, like things like Python
and other types of code
in an automated fashion where it
just looks at the code outright and
it tells you where there may be some
areas of risk.
But if you have the capability to do
manual code review and look
for things like redirects
or links that would pull
maybe malicious files on the back
end or something of that nature,
that would definitely be something
that you would want to try to do and
then check for anomalous network
activity. And so we reviewed the
code clearer case at a high level.
And had they not had the
threat analytics in place to find
this activity, to correlate
it, to maybe go back and do some
checks and see if the threat actor
was there for a long period of time,
if those things weren't in place,
then they would have never seen the
activity and we would have had a
repeat of the cleaner
compromise. So it's
good to have controls in place
that go outside of just the software
itself. But overall, looking at
network activity, account activity,
things of that nature, you're going
to see as being
kind of a repeat in this and really
that that should more so be
in the
detection techniques.
But these detection techniques are
more directly involved in checking
for supply chain issues,
not so much just detecting
anomalous activity.
So when talking about supply
chains, verification methods such
as integrity or checking mechanisms
are great if
the vendor publishes checksums
and if those are for
vendor approved and confirmed
updates, if a threat
actor does intercept it
after the fact and they sign it as a
trusted entity and
it does in fact alter the checksum
or the integrity of that file,
then you're good to go.
But if the
vendor publishes
the app and it was
manipulated prior to them doing
a hasher and integrity check in
publishing that, then
that would make it much more
difficult to detect.
Now, the other side of this is
when we talk about network activity
and malicious activity,
you could always install the
software or the
application that you plan on using
in a sandbox environment
and then give it like maybe an
Internet connection so it can call
out to maybe command and control
center if it's got something like
that going on or to the right actor
and just monitor that applications
activity for a period of time
just to see if something comes up to
see if it does anything suspicious
or sneaky before fully
implementing the software across
the environment, because you could
have other issues in
the environment that would be
from a threat, actors activities
that may not be tied to the
software. So if you've got a
controlled system in place
that you can do this type of testing
on, that would be beneficial,
especially if you're in a high
security environment now.
Much harder of the three
recommendations, but supply chain
attacks can happen with manipulation
of hardware.
And things of that nature, so if
you're working in a secure facility
or something of that nature, you're
probably already inspecting
hardware.
But if you're
a midsize business or enterprise
and you get bulk of keyboards
or microphones or cameras
or something of that nature, it may
be beneficial to,
again, plug hardware in,
look for suspicious
activity, maybe open
a piece up and look
for a keystroke loggers
or pieces that just don't belong.
That's going to be tedious and it's
probably going above and beyond.
But if that is what truly
concerns you and it is a risk for
your organization, then
it would definitely be a detection
technique that you would want to
implement or use.
So now let's do a quick check on
learning. True or false,
Supply-Chain compromise takes
advantage of trust between the
vendor and the consumer.
All right, so if you need additional
time, please take a moment to pause
the video. So this statement,
supply chain compromise takes
advantage of trust between the
vendor and the consumer
is a true statement.
And the reason this is a true
statement is because if
I do business long term with
Avast and I use
cleaner, if the
compromise had not happened
previously in twenty, seventeen
or eighteen, then
you know, I would not be suspicious
of that tool.
That tool has been around for a
while. It's tried and true.
People use it day in and day out.
So I would not think anything of
downloading and using that tool,
but I
trust that vendor.
And so if there is a relationship
there where I have I
use dental equipment all
the time or I use HP
equipment all the time or I use
whatever,
and for some reason,
let's just say a delivery is
intercepted or they've got a
dirty
worker in the factory, something of
that nature, and they're putting
chips in systems for
money that track data and
send information back to a foreign
entity.
Well, you know, the vendor
is still trying to do right by me,
and I trust that vendor.
And I'm going to use their hardware,
not think much about it until, you
know, the articles come out that the
chips are infected or whatever the
case may be.
So definitely taking advantage of
trust here.
So in summary.
All right. What did we go over
today? Well, we described
what is a supply chain
compromise.
We reviewed some examples,
some mitigation techniques
and what are some detection
techniques as well.
So with that in mind, I want to
thank you for your time today.
And I look forward to seeing you
again soon.