What Are Third-Party Risks?

Transcript:

Connor Swam:

Welcome to Gone Fishing, a show diving into the cybersecurity threats that surround our highly connected lives. Every human is different. Every person has unique vulnerabilities that expose them to potentially successful social engineering. On this show, we'll discuss human vulnerability and how it relates to unique individuals.

I'm Conor Swam, CEO of Phin Security, and welcome to Gone Fishing. Hey everyone, welcome back to another episode of Gone Fishing. I'm your host Connor, the CEO at Phin, and I am joined once again by Jason Slagle. Jason, how you doing today?

Jason Slagle:

I'm good.

Connor Swam:

If you haven't watched the first episode, go do that, because that's where you'll understand the reference that I just made. And I don't know that I want Jason trying to explain that.

So today we're going to talk about third party risks. So what is a third party risk? What's the definition? Let's start there for the folks.

Jason Slagle:

Yeah, so I consider third party risk, supply chain risks, are basically risks that come from vendors that you happen to use, or even vendors of your vendors. Or if you develop software like Phin, the third party risk could be the downstream components that you end up bundling into your software package.

Connor Swam:

Oh yeah. So for those of you who maybe don't understand software, the software you write is often comprised of other pieces of software that other people have written. And if there is a vulnerability in any one of those little tiny pieces of software, I immediately go to node modules, node packages. If there's a vulnerability in one of those, well, like millions of people use those. So there's a big problem that would make our app vulnerable as well.

Jason Slagle:

Yep. And there's a couple of really famous examples of that on the software side. One of which was a node module that had been abandoned by the author. Somebody took over the GitHub channel, released a new version of it, and actually made this new version specifically to steal crypto wallets from one particular crypto exchange. As it turns out, that software package, via a dependency of a dependency several levels deep, ended up getting pulled into every single React app that was out on the Internet. In some of those ecosystems, there are dozens if not hundreds of packages you end up getting from node. So, yes, that's third party risk. They're not the only third party risk on our side of the house. Like, as an MSP, third party risk would be my vendors, Phin, ConnectWise, other vendors that I happen to use.

Connor Swam:

So if a vendor gets compromised, then you have the potential to get compromised. And we saw that with the Kaseya VSA hack.

Jason Slagle:

Yeah, we saw that. And they're not always that bad. From my perspective, you're a relatively low risk to me, although not a zero risk, because you have the unique ability to inject mail into Office 365 boxes. So the power you use for good could be used for a ridiculously large amount of evil, because you bypass everything. It just injects stuff straight into the mailbox. So that is a risk that I consider when I allowed that.

Connor Swam:

Well, that's also why we have separate privileges for the user sync and the mail injection. That was the feedback we got, probably from you, actually, now that I mention it.

Jason Slagle:

Probably, yeah.

Connor Swam:

Hey, there's a way to separate these. You should probably take it.

Jason Slagle:

It was probably from Kelvin, but, yes, I would have mentioned the same thing.

Connor Swam:

Yeah, no, it's really interesting. That's actually one of the reasons we started Phin was like, wow, phishing people is really fun. Let's just not go to jail for it. So it's like, okay, we can do this in the sake of preventing social engineering. That's why we started. So let's think about two different groups of people. There's the end client, and there's MSPs, and then there's the MSPs' clients. How does third party risk impact them differently? How should they be thinking about it?

Jason Slagle:

They impact both groups in different but related ways. From an end user perspective, the MSP is a third party risk. If you're hiring an MSP, you have to understand that you're only ever going to be as secure as that MSP is. Because that MSP, in most cases, carries all of the keys to every one of your boxes. They may have vendor managements and vendor engagements. They have access to your email and all of the boxes inside of it. Sometimes companies get a little uncomfortable about that. It comes with an implicit level of trust. But as an end user, you really need to consider that. More importantly, that's not the only third party risk. A thing that we find very commonly, especially with certain software industries, is your line of business vendor may have their own remote support software that they're using for their own management. You have the third party risk of whatever their security instances are. We definitely saw cases, especially with the Kaseya hack, where people weren't even using Kaseya and they had systems compromised because some line of business software vendor, like a cash register vendor or something, happened to have remote access to these systems to monitor and maintain just that one piece of software. But those agents, based on the permissions that they have to run, had essentially full access to the systems. I don't expect most end users to necessarily be able to understand that risk. So it's on us, I think, as providers, to try to educate them with the risk of like, hey, there is risk in hiring me, but there's also risk with all the other things too. And it's my job to help you manage my own risk and then to help you manage that risk for other places.

For MSPs, this is when you guys came looking for topics for me to talk about. I brought this up because I feel like MSPs recently use this as a scapegoat. The vendors are the boogeyman. Oh, you know, the vendors are going to get me hacked. Yeah, we can talk about that, but something like, I don't know, upwards more than 70% of breaches at MSPs—as of the end of 2022, still something like 83% of breaches, full MSP breaches—were traced back to credential reuse of some sort or weak passwords or some sort of identity authentication kind of thing. And we are seeing third party supply chain risks. ThreeCX is a perfect example. We're seeing third party supply chain risk that could have gotten a bunch of people compromised, but generally the risk to MSPs is much more their own internal weaknesses and policies than it's going to be some sort of third party that's going to get you popped. Because those third party bugs and risks, they're worth millions of dollars and no one is burning that O'Day to take over a handful of MSPs. These are nation state actors that are targeting very specific people. They're not targeting the mom and pop MSP that's got 50 customers and manages 500 endpoints.

Connor Swam:

Yeah, you might get. I always forget who says it. So if you know, I'd love to attribute this quote to them. You're not small enough to get hacked. You're too small to make the news.

Jason Slagle:

I think it may have been Wes.

Connor Swam:

Wes?

Jason Slagle:

Yeah.

Connor Swam:

I'll have to text him about it then and see if he stole it from somebody else.

Jason Slagle:

It's either Wes or Kyle Hanslov and it's one of the two.

Connor Swam:

I'll have to figure that out. But no, you made a statement early on that really fits right in here: you don't want to start throwing rocks before you've got your own house in order. And it sounds like that's what you're trying to address—a lot of people are going to start pointing fingers at other people and it's like, you point one finger at somebody else, you got three pointed back at you. I know that's cheesy, but...

Jason Slagle:

It's one of those things that's really easy. As we were prepping for this episode, I kind of talked about this a little bit, but I sit on various advisory councils for security stuff in the MSP space. One of the first things that gets asked is: "Hey, we need a questionnaire for our vendors that we can follow," or "What can we do to ensure that our vendors aren't going to get us all hacked?" And, yeah, that's well and good, but start with your own basic cyber hygiene. Once you have that under wraps, then consider the third party risk and then just evaluate that risk. I've had a couple vendors looking to get me to do things recently. You really have to provide a lot of value right now for me to install another agent on systems I manage. Every agent I run is attack surface. While you guys can inject email into people's boxes, and that's pretty terrifying, it's a lot more terrifying to me when I have several thousand systems under management with an agent on it that, if that gets hacked, can just, boom, everyone is done. So really just pay attention to your own risk and consider what would happen if the providers do it and consider the maturity of them too. There's a newer vendor in our space that requires an agent to do their work. I pulled apart their software product and it was really terrible and I called them out on it. It turns out the person that had written the agent running on the end user systems, this was their first project they'd ever written outside of college. So this is like a new developer that's writing software that's running as NT authority system on end user workstations. And there were issues with it.

So while I think MSPs shouldn't ignore the third party risk, they should consider it as part of a broader spectrum and they should inventory their service providers and what they have access to and then just address them as needed.

Connor Swam:

So other than taking stock of your own risk and inventorying and classifying it, what are some ways that MSPs can reduce this risk, this third party risk, or prevent it?

Jason Slagle:

You should be asking questions of your vendors. There are various certifications out there. I think you had mentioned earlier that you guys are going through SOC 2, right? That's one of them. ISO 27001 is another one. Ask your vendors what security frameworks they adhere to and what they use to ensure separation of duties and all the other things that come with being a good partner. Don't ignore it. Don't pretend third party risk doesn't exist. Ask those questions of your providers.

Connor Swam:

Ask those questions. There was one thing you had mentioned earlier that I wanted to touch on, which was when the most secure an end user will ever get is the least security the MSP has for themselves or can provide for themselves. You made some statement like that: end users will only be as secure as the MSP is because the MSP has keys to the kingdom. What kind of questions is it fair for a client to ask you? What would you like to see? Pretend you're getting a new client on board.

Jason Slagle:

Do you use role based access control for your users? Do your end users have administrative accesses to your systems? How do you do credential management to ensure that somebody doesn't have access to the passwords to my systems? They're common sense things, and I think you can start there and then go deeper if you need to.

Connor Swam:

One thing that a lot of other guests have recommended is if you have no idea where to start, pick a framework and go from there. They always land on CIS Controls, but 800-171 is another very common one, or NIST.

Jason Slagle:

CSF is another common one. We all land on CIS because CIS is prescriptive. They tell you what to do. If you use their benchmarks, they don't just tell you what to do. NIST 171 will say, you should ensure blah, blah, blah, but it doesn't tell you what you have to do to actually ensure that. So you're always stuck guessing, am I doing that or not? Whereas CIS will give you a, like, do these things and you're meeting this control.

Connor Swam:

Yep. No, I completely agree. And it's separated out nicely into IG1, 2, and 3, so that you can kind of take stock. Am I top class in terms of my own security posture, or am I just getting started or whatever? It depends on the educational ability of the people going through it.

Jason Slagle:

Yeah, 100%.

Connor Swam:

What's the last piece of advice you'd give to folks listening on third party risks or how to prevent it or understand it?

Jason Slagle:

Again, it's just a matter of threat model internally. Consider what it looks like if each of your vendors gets hacked. Don't necessarily consider them the boogeyman. Consider what it looks like when that vendor gets hacked. If the vendor has their own supply chain incident or a threat actor in their systems, it should really be no different than if you internally have a hack. So we're on site automate. I don't care if ConnectWise gets hacked, or I don't care if my automate gets hacked. My actions are the same: plug's coming out of the wall. It's getting disconnected until we can do forensics on it and look at it. So you need to have a plan. Your incident response plan should address each of those things.

Connor Swam:

So having some kind of incident response plan both and separate between internal versus third party hack would be great.

Jason Slagle:

I think that's good.

Connor Swam:

I'd give one piece of advice. Don't be afraid to ask questions.

Jason Slagle:

Yeah.

Connor Swam:

Some people, for whatever reason, some MSPs, they just don't want to ask questions of their vendors because maybe they think they'll react badly in a certain way. It is always fair game to ask about the security posture of any person you intend to get into business with. And if they're not open and transparent, I would consider that one of your acceptance criteria and it should probably be reason for you not to work with them.

Jason Slagle:

I would agree with that. It's fair game to ask for any audit reports. Some companies will make you sign an NDA to get them, which I think is total crap, by the way. I don't know why you're hiding those by an NDA, but I think it's fair game to ask for them for sure.

Connor Swam:

Awesome. Well, folks, thanks for listening. Jason, thanks for coming on today. This was a blast. I actually learned a lot about third party risks. I'm a third party myself. What I learned today: everyone is not only a third party mostly, but also everyone has their own third party. It's like everyone's in between. Nobody's the bottom link in the supply chain or the top.

Jason Slagle:

Yeah, no, there's that one guy that wrote that very first program, and every single program then is a descendant of that program. So he may not have any supply chain risk, but all the rest of us do.

Connor Swam:

Absolutely. Everyone, thanks for watching. Thanks for listening. Once again, I'm your host, Connor, CEO at Phin. You joined us for another episode of Gone Fishing, and we had the wonderful Jason Slagle. Thanks for joining us, Jason.

Jason Slagle:

Thank you.

Connor Swam:

Thanks so much for tuning in to Gone Fishing. If you want to find out more about high quality security awareness training campaigns, how to launch them in ways that actually engage employees to change their habits, then check us out at Phin Security at Phinsec IO. Thanks for fishing with me today and we'll see you next time.