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, um, 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, 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 sea VE or some type of release by the vendor that indicated there was vulnerable components of the software
and it is for version 1.3 and below and we're running version 1.1,
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 AP eyes that we're not going to use if there are functions and features that we're not going to take advantage of it. There are compartments that we don't need to use in a particular suite of software.
Then we can reduce the attack Victor's or the capabilities of a threat actor. Potentially,
by not running every single piece of software, you know, 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 Teoh cut down on capabilities here.
if you have the capability, manual or automatic code review is something that you could do is 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 out right, 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 backhand or something of that nature,
that would definitely be something that you would want to try to do and then checked for anomalous network activity. And so we reviewed the CC cleaner case at a high level. And have we 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 CC 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, um,
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 has checking mechanisms are great
if the vendor publishes check sums
and if those air four
vendor approved and confirmed updates if
ah threat actor does intercept it
after the fact that they sonnet as a trusted entity
and it does in fact, alter the check some or the integrity of that file,
then you're good to go. But if the, um vendor publishes
the APP and it was manipulated prior to them doing a hasher an 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, you know, 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 to the Threat 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, how 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 a bulk older of keyboards or microphones or cameras or something of that, nature may be beneficial to again. Plug hardware in, look for suspicious activity, maybe open a piece up
and look for 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 unit is a risk for your organization,
then it would definitely be ah 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
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 a vest and I UCC cleaner,
if the compromise had not happened previously,
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.
I trust that vendor. And so if there is a relationship there where I have, I used 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 you know, track data and send information back to a foreign entity.
Well, you know, the the vendor is still trying to do right by me. And I trust that vendor. 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.
All right. What did we go over today? What we described What is a supply chain compromise? We reviewed some examples of 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,