Hi, I'm anti Clark, and this is Lesson 2.7. Supplier Risk
and Lesson 1.3. We discuss the various vendors and third parties that oh, EMS can use to develop and manufacture their coyote products,
and we've mentioned supplier risk and other lessons as well. This lesson is going to go a little deeper into this topic
in this lesson. Well, look, a vendor and third party risk will identify a simple supplier management process and discuss supply chain vulnerabilities, and we'll finish with the case study. So let's get started.
Just a quick moment for definitions.
Let's talk about the different street vendor and a third party. Ah, vendor is an entity that provides goods and services to the O. E. M.
And the third party is an entity tasked with providing products and services to consumers on behalf of a knowing M.
So during this discussion, I'm probably going to use both terms interchangeably, so apologies ahead of time. But in case you're wondering, there is a difference.
For most organizations, their supply chain can be very large and needs to be carefully managed. It could include silicon vendors, vendors to provide PCB Central's
lenders that provide fabrication services, as well as other various vendors that may provide storage, memory or other physical components. For I O T devices,
the sip so needs to evaluate vendor risk in relation to the overall i o T ecosystem, and not just for a single product.
In terms of the supplier security, the sip so will need to review each vendor's security posture. And typically this is Mawr important if the vendor's providing a service than if they're actually providing a product, unless that product they're providing is a core component as part of the security.
For example, if you're purchasing a processor with identity pre injected
by the chip manufacturer, then you're gonna want to know about all their security processes
to review the security of a product you're looking at, how it is designed, how it will be used,
what are the recommended ways to secure it,
as well as discovering what you need to do on the OM side on your side to properly use the product. Maybe there are some recommended security measures that you should take
to review the security of a service that you're purchasing. Look at the data. What elements are being transferred, stored or processed by the third party.
Where does this occur? Who has access to it?
How long is the data cap after termination of the agreement, so to speak,
Onda also what security controls are in place
has in another good one to always think about it. Has an independent entity verified that the third party is actually doing what they say, that they're doing the compliance portion
And this could be done through demonstrating either a sock at a station or like an ISO certification.
Basically, looking at the vulnerability report or high level penetration test will help because the third party took a look at those. Unless, of course, that was done internally by the third party themselves. So you're looking from some for something from someone else.
One thing that is not very helpful is receiving the soccer port of AWS or Azure, for example.
It's not very helpful because that doesn't show the security of the application or service that was built on top of their infrastructure,
and the system may need to recommend some appropriate action to the business, and maybe that could be to ensure that the user entity controls are implemented from the soccer board. Or it could be to ensure that proper security controls are implemented on the OM side, which are not implemented by the supplier
Andi. It could be to recommend stronger contractual terms toe legal during the contract negotiation phase.
Um, and generally, when you do that is toe make up for a lack of at a station during that security review process.
So third party security is an ongoing process. It doesn't end.
It's just going to continue and and it's probably going to continue to come. More burdens in overtime.
For example, in the US, the 2020 National Defense Authorization Act, or the N. D. A. Includes a variety provisions related to splotch ING security.
It prohibits federal agencies and their contractors from purchasing are using telecommunications and video surveillance equipment or services from very specific Chinese companies.
So if you provide services to the U. S. Federal government, you have to be aware of that,
you know, and not to have those cameras are the components within your Ivuti ecosystem.
This drawing shows a really simplified supplier security process. It doesn't include all the intricate legal and compliance and procurement sub processes that may be involved.
But this basic process it starts with identifying the need, of course,
signing a non disclosure agreement. It's very, very important that you have these India's in place,
conducting a security assessment of the product, going through the contract negotiation process and again not shown in this would be things like running proof of concepts with multiple vendors or product implementation or product tuning or training. We're just assuming that those activities were taking place.
When your product is in service, you still have to test to monitor the product and remediate. Of course, any security issues that air found handle any security breaches from the third party that they may have or in implementing the security patches that they release,
and eventually you have to discontinue the service and ensure a secure process is followed to turn it down.
Bo Woods gave a talk in RSA 2020 entitled Supply Chain Security in the software error.
In his talking outlined four types of supply chain vulnerabilities that he encouraged participants to uses a framework when considering supply chain risk. He gets all the credit for the four items on this list.
I've included. A link to his talk in the resource Is and I encourage you to listen toe him yourself.
Supplier Facilitated risk is the first one. We've more than establish that the cybersecurity of third party partners can influence the security posture of the O. E. M.
This includes third parties that have a persistent connection to your operational environment, as well as other vendors who have either physical or network access. A great example to think about is the target breach, which occurred because of the H back suppliers access to their environment.
Counterfeits is the second one,
and this includes non authentic components, either sold by a vendor to an O. E. M or are sourced and used by a third party in the production of the OEM's I ot device. Or it could be used within the I O T ecosystem itself.
These components air generally inexpensive knockoffs or non genuine parts or actual counterfeits of the original component.
It could include fakes, chips or illegitimate software in a product that you buy or replacement parts for systems that air so old that there's just no longer available.
I remember dealing with a computer in Brazil that had a fake version of Windows XP on it. It didn't get updates was such a horrible, horrible, terrible fake. I think it was just Lennox with a really bad windows. Gooey,
malicious taint is the third one, and this includes components that often come through unauthorized channel in our authentic and pass the quality testing procedures.
However, they have some type of unintended functionality built into it
software or hardware that could be that is implanted into the device by someone with a privileged position of supply chain that could be the root cause of it.
Um, example of this could be the have X malware, which was distributed as legitimate updates through compromised I. C s manufacturer. Websites will actually get into that, um,
case study in module six
um, CC cleaners. Another great case. Study Thio. Take a look at where they're update process was hijacked itself, and we'll get into that as a case study later on as well.
An unintended taint is the fourth one on this list that includes components to come through authorized channels which are authentic and pass the rigorous validation.
However, they contain quality defects or it could be software flaws or vulnerabilities, which may not be known at the time by the supplier on. There are a lot of examples of products out there that require security updates because of this reason or that.
And so I see we see a lot of unintended taint out there.
Well, that's it for this lesson.
In this lesson, we discussed supplier risk. We identified the role of the sip so has in handling this risk. We reviewed a simple process to manage supplier risk.
We reviewed supply change vulnerabilities and make sure you listen. Toe Bo Woods, 2020 arce talk on that
and another module. We're going to take a look at a few case studies that we that we mentioned help understand why these principles were so important, But I'll see you next time.