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 the big jerk in the channel with a giant bucket of rocks. Also Moonlights is the president of C, 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 really, a couple of really famous examples of that on the software side, one of which was, I forget what the actual name of the package was, but this was like basically a pretty print or some sort of other utility function, 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 of it specifically to steal crypto wallets from one particular crypto exchange. And as it turns out, that software package, via a dependency of a dependency like four or six levels deep, ended up getting pulled into every single react app that was out on the Internet. It's definitely in some of the ecosystems, and I pick on JavaScript a lot because it's big there.
Jason Slagle:
In some of those ecosystems, there are dozens if not hundreds I think there's, like, 400 packages when you type react up that 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, like, my vendors, Phin, like, you're a third party risk to me, connectwise, other. 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 hat.
Jason Slagle:
Yeah, we saw that. And they're not always that bad. Right. So, from my perspective, it's like, 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 is. 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, fishing people's really fun. Let's just not go to jail for it. Yeah. And 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. I want to call it, like, the end client. And there's MSP's, and then there's the MSP's 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. Right. So, from an end user perspective, the MSP is a third party risk. Right? Like, and, yeah, they have their down chain, downstream chain of things. Right. But if you're hiring an MSP, you have to understand that you're only ever going to be as secure. So I'm on the end user side here. You're only ever going to be as secure as that MSP is. Right. Because that MSP, in most cases, carries all of the keys to every one of your boxes. But they have passwords. They may have vendor managements and vendor engagements. They have access to your email and all of the boxes inside of it. Right. And, you know, sometimes companies get a little uncomfortable about that. It's like, well, you can read your email.
Jason Slagle:
I'm like, yeah, and you think I got better things to do than maybe reading your email. Like, it's, it comes with an implicit level of trust. Right. But as an end user, you really need to consider that more importantly, that's not the only third party risk. Like a thing that we find very commonly, especially with certain software industries, is your line of business vendor may have their own remote software, 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, happen to have remote access to these systems to monitor and maintain just that one piece of software.
Jason Slagle:
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. Job to help you manage, to manage my own risk and then to help you manage that risk for other places, for MSP's. This is when you came, you guys came looking for topics for me to talk about. I brought this up because I feel like MSP's recently use this as a scapegoat. Right? The vendors are the boogeyman. Oh, you know, the vendors are going to get me hacked.
Jason Slagle:
Yeah, I mean, we can talk about that, but something like, I don't know, upwards more than 70% of breaches at MSP's. I haven't looked at the latest data, but as of like the end of 22, 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. Three CX. There we go. Perfect example, right? Like, we're seeing three CX is a third party supply chain risk that got, you know, potentially could have gotten a bunch of people compromised, but those were generally the risk to MSP's 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.
Jason Slagle:
Because those third party bugs and risks, they're worth millions of dollars and no one is burning that O'Day, right, to take over a handful of MSP's. Right. 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 text it. I'll have to figure that out. But no, you made a statement early on that was really fits right in here, is 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 is a lot of people are going to start pointing figures at other people and it's like, what's the. You point one finger at somebody else, you got three pointed back at you. Kind of. I know that's cheesy, but no, it's.
Jason Slagle:
It's one of those things that. It's really easy. Right? So I sit, and as were prepping for this episode, I kind of talked about this a little bit, but I sit on like the various advisory councils for security stuff in the MSP space. And one of the first things that when one of these spins up and there, I've seen several come and go that gets asked is like, hey, we need a questionnaire for our vendors that we can follow. Or, hey, we need, we know, what can we do to per. To ensure that our vendors aren't going to get us all hacked. And, yeah, you know, that's well and good, but like, start with your own basic cyber hygiene and then, And then once you have that under.
Jason Slagle:
Under wraps, then, you know, let's consider the third party risk there and then just evaluate that risk. Right. Like, you, I was. I've had a couple vendors, like, looking to get me to do things recently. Right. And I won't. You. You really have to provide a lot of value right now for me to install another agent on systems I managed. Right. Because every agent I run is attack surface. Right? And while you guys can inject email into people's boxes, and that's pretty terrifying and pretty terrible. It's a lot more terrible, terrifying to me when I have the several thousand systems I have under management with an agent on it that if that gets hacked, can just, boom, everyone is done. Right.
Jason Slagle:
So I really, you 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, right? Like, I'm, I won't names here, but there's a newer vendor in our space that they require an agent to do their work. And I pulled apart their software product and it was really terrible and I called them out on it and 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. And so this is like a new developer that's writing software that's running as like NC authority system on end user workstations. And there were issues with it.
Jason Slagle: And so while I think MSP shouldn't ignore the third party risk, they should consider it as part of a broader spectrum and they should inventory, you know, 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 MSP's can reduce this risk, this third party risk, or prevent it?
Jason Slagle:
You should be asking questions of your vendors, right? Like there are various certifications out there. I think you had mentioned earlier that you guys are going through soc two, right? That's one of them. ISO 27,001 is another one. Right. Like 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. And, you know, just understand that. So don't ignore it. Don't pretend third party risk doesn't exist. Right. And ask those questions of your providers. I guess.
Connor Swam:
Ask those questions. There was one thing you had mentioned earlier that I wanted 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, like, end users will only be as secure as the MSP is because the MSP has keys to the kingdom. Yeah, they got everything. What kind of questions is it fair for a client to ask you? What would you like to see? Pretend you're going, you're getting a new client on a board.
Jason Slagle:
Yeah.
Connor Swam:
What would you think is fair?
Jason Slagle:
Do you use role based access control for your users? Right. Like, do your end users have administrative accesses to your systems? Do you. How do you. How do you do credential management to ensure that. That somebody doesn't have access to the passwords to my systems? Things like that. They're. They're common sense y things, and I think you can start there and then. 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 started a framework and go from there. And they always land on cis controls. But 800 171 is another very common user, or NIST.
Jason Slagle: CSF is another common one. We all land on CIs because CIS is prescriptive. So they tell you what to do. Not just. They tell you specifically what to do. If you use their benchmarks, they don't just tell you what to do. Like, nist. NIST 171 will say, you should ensure blah, blah, blah. And it's like, 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? Right. 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 ig one, two and three, so that you can kind of take stock. Am I, you know, top class in terms of my own security posture, or am I just getting started or whatever? It depends on the educational, the 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:
Yeah. I mean, again, it's just a matter of threat model internally. Right? Like, what does it, like, consider what it looks like if each of your vendors gets hacked, right? And don't necessarily consider them the boogeyman, because 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, or it should really be no different than if you internally have a hack. Right? Like, so were on, 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 plugs coming out of the wall. It's getting disconnected until we can do forensics on it and look at it. Right. 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.
Jason Slagle:
Yep.
Connor Swam:
Hack would be great.
Jason Slagle:
I think that's good. Yeah.
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 MSP's, they just 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, right? Like in some P, some companies will make you sign an NDA to get them, which I think is total crap, by the way. Like 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:
Yep. 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. Well, 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. Right. 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, whose contact information will be in the show notes below. So feel free to reach out to him and ask any wonderful questions. Cool. Sweet. 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. Phin security at Phin sec IO. That's p h I n s e c IO. Or click all of the wonderful links in our show notes. Thanks for fishing with me today and we'll see you next time.