Identifying Third-Party Vendor Risks with Michael Magyar, Trava

Jara Rowe: Gather around as we spill the tea on cybersecurity. We are talking about the topic in a way that everyone can understand. I'm your host, Jara Rowe, giving you just what you need. This is The Tea on Cybersecurity, a podcast from Trava. Thanks for tuning in to another episode of The Tea on Cybersecurity. On this episode, we're diving into the critical topic of third party risks. How can you ensure your vendors aren't the weak link in your cybersecurity? We will cover identifying risks, evaluating security practices, and so much more. So let's get started. I would like to welcome my guest, Michael Magyar. Hi Michael.

Michael Magyar: Hey Jara. How are you doing today?

Jara Rowe: I'm great. How are you?

Michael Magyar: Doing good.

Jara Rowe: So I know you're not a newbie to The Tea on Cybersecurity, but just in case this is a listener's first time tuning in, can you please introduce yourself?

Michael Magyar: Yeah, thank you. So I've been in the cybersecurity industry focused for about 10 years now, and I'm a pen tester, so I do a lot of penetration testing. I spend a lot of time in cloud environments and building applications and building infrastructure. And right now I mostly focus on performing virtual chief information security officer activities. So helping organizations decide what the best direction is for their company and where to spend their money.

Jara Rowe: So let's go ahead and dive into the first question I have. What are vendors and third parties in the context of cybersecurity and why are they important for us to consider?

Michael Magyar: Yeah, it's a great question and we're seeing this becoming more and more of a focus and a topic in the industry. A lot of organizations will think of vendors or third parties to only mean like an external website or service that they use. So if you use Microsoft 365 for email or those types of services, or they might think about that as outsourced staff, vendors and third parties can mean a lot more. Every business today runs on technology. Every business is a technology business. Even a taco cart uses a little payment thing that you swipe your cart in to do that. So if we think about even just that card reader, there's the physical hardware and somebody created that. There's the operating system that runs it, there's the payment application, there's internet connectivity for that. And so all of those we think about as vendors too because they could potentially create risk.

Jara Rowe: So to sum it up, we all interact with someone's third party in our everyday lives.

Michael Magyar: Probably hundreds if not thousands of third parties.

Jara Rowe: How can beginners identify potential security risks associated with vendors and third parties?

Michael Magyar: In some ways this is impossible. I hate to say that because that sounds scary. If we think about what I mentioned earlier about all those technology stacks, we might think that that's a bad thing to leverage all this technology, but it's how our business works. Our business needs these things to operate. If we think about the security risks that are involved, there's really no way that we can look inside all of the different companies that we use. We can't really see what type of software development practices they have or management practices they have. We're not really going to know if they use secure code, maybe they put a back door in our technology. So I think extent of use can be a good indicator of whether or not we can trust how good the security is of a product. Extent of use is certainly not a absolute determining factor there, but it can be a piece. Other things I like to look at though, and I'll just say that's a good excuse if things go wrong. If everybody uses iPhones and there's an iPhone bug, we don't blame the person who has the iPhone. We blame the iPhone creator. So more practically I would say public statements of security, it's how to instill confidence in that product. Every security vendor or every vendor is going to have bugs and issues in their software. So if they're pushing out updates, that's another good way to identify how risky it is or is not.

Jara Rowe: Can you provide us any examples of a real world incident where poor vendor and third party security led to some sort of issue?

Michael Magyar: Yeah, we see these every day now. It is continuous. SolarWinds in 2020, threat actors used a breach in their software to push out malware to a lot of other companies. And so as these other companies were receiving updates, they were actually now being compromised. So that was a really big public one that a lot of people probably heard about. More recently and even more scary I think is about two months ago in March of 2024, a library called XZ Utils. And so this is leveraged by a lot of pieces of the operating system including OpenSSH. And so OpenSSH is a way to remotely access your computers and systems. And so this is very big in a lot of Linux operating systems. It's baked into it. And so a threat actor was actually able to convince the XZ Utils maintainer to trusting the threat actor, and as a result of that, they were able to slip the back door in there, and that back door almost got pushed out to all the different Linux distributions. It was in a lot of beta channels. And so this was actually accidentally caught by someone doing performance testing. But if this wasn't caught, we potentially could have had a back door in a library of OpenSSH leverages, but as a result of that SSH throughout everybody that updated. So these can be really, really pervasive and some really scary examples.

Jara Rowe: What are these red flags or warning signs for individuals or organizations that they should watch out for when evaluating working with a potential vendor?

Michael Magyar: Yeah. And it's really hard because again, we are not able to see internally into these organizations. Microsoft recently had a few breaches over the last year that were kind of scary in their cloud services, including one where a threat actor was able to get a sign in key and then create... Basically give themselves access to a lot of different tenants. And so they were able get in and read these emails and read files of a lot of really important organizations, including federal agencies. Recently in the last two months, the CISA Cyber Safety Review Board did a kind of review of what happened in that instance, but turned out that they really gave a scathing report against Microsoft and they really said a lot of things that were, this is negligence almost. One of the things that even came about of that is Microsoft had given a root cause, a reason why this had occurred. It turns out that might've not even been true. They don't actually know how this occurred, and they didn't even update the public about that. They just let that potentially false narrative ride. So I think that's kind of a scary thing because we look at that, that seems like a very big red flag. How do you trust Microsoft's products there? Microsoft recently came out and said that they're going to actually start tying executive compensation to security goals and really try to fix a lot of this.

Jara Rowe: Okay. Cool.

Michael Magyar: So that's a good turnaround. So I think it goes back to what kind of public information do we have? How can we identify companies that are trying to be better? I think that's a good juxtaposition from AWS. A vulnerability is discovered in their products, a lot of times they can even state out to the world because if we have a breach and we say that we don't have any evidence of a breach, that makes it seem like there's no evidence of a breach. But it maybe just means we don't have any evidence, that we don't have logs or we don't have a way to find out. And so we have to be very careful about how the lawyers word some of these statements. But like AWS for example, says they actually can go back through all of the logs from the service since it was first created because they do all these good security practices and they'll literally come out and state that they reviewed all logs and can say with certainty that this was not actually exploited from all the way back to the beginning of the service, that they've already mitigated it and it's already been taken care of. So kind of a juxtaposition about where you might see a red flag versus where you might see strong security posture.

Jara Rowe: As I'm learning more about pen test, is there a way that this works into third party security?

Michael Magyar: Most of the time you're not going to know what an organization's pen test look like. The reason for that is that's an internal function that the organization does. Some organizations will publish their pen tests, so that's nice to be able to access, but a lot of times we're not going to know otherwise. So I think there are two ways that we can get information about pen testing.

Jara Rowe: Okay.

Michael Magyar: And one of those is the certifications that organizations have. So some certifications require pen testing or would be listed in their certification that they had at pen test. So FedRAMP for example, requires a very extensive pen test. PCI, if you accept payment cards, that also has a pen test that requires some extra things. If you are also either SOC 2 or ISO, a lot of times your report at the end when you get your certification will actually state whether or not you do pen testing and to some extent what that looks like. So sometimes we can get insight into that, but it's not always. I think also some organizations have bug bounty programs, and so these are really cool because it allows anybody in the world to do pen testing on that organization as long as they are providing the results back to the organization rather than exploiting it themselves.

Jara Rowe: Okay. What are other ways that businesses can help evaluate the security practices of a vendor or third party?

Michael Magyar: A bug bounty program, which again is something that allows any organization to do penetration testing, leveraging the entire world so anybody in the world can test that company and provide, " I found this, please pay me for letting you know that I found this bug." If you've had a bug bounty program and the maturity of that can give some inclination into how that vendor is risky or not. If they receive disclosures and they remediate those quickly, that can be a good indication that they actually care about security. Whereas if they either fight researchers that provide bugs or try to silence them, that could be a red flag. We can also sometimes see how they responded to actual incidents. Do they provide transparency? Do they provide a detailed root cause analysis and say, " Here's what happened, here's what we're doing to mitigate it?" That can also look good. Also, what certifications do they have? And this is I think where we can actually get some practical understanding of what they have and use that in our third party risk management programs. Everything the organization says is marketing. We are all in business. We are all marketing and trying to look good. So it's really hard to rely on statements that are publicly stated. I mentioned those can help earlier, but truly, unless we have an independent third party auditor, we're not going to know what that actually looks like. And so what certifications and organization has can help provide some insight into how risky they are. So organizations that have gone through a FedRAMP certification on that service, there's 400 plus controls they have to go through depending on their level, and they have to have a third party auditor who's very, very detailed. So that can help provide some assurances. We've seen a lot of organizations pursue SOC 2 or ISO 27001 certifications. And so those require audits as well. They're a lot more accessible and common than something like FedRAMP, and those could be good indications that an organization has some security.

Jara Rowe: So what are these key cybersecurity measures that I really need to be looking for when it comes to working with a vendor?

Michael Magyar: If we are just working with a vendor and maybe it's a cloud service, we can see, can we enable MFA? If we're able to enable multifactor authentication, then that's a good indication that there's some security there and we can at least protect our side of the shared responsibility model. If we could enable multifactor, if we can enable single sign- on without paying a... And there are a lot of vendors, it's called the SSO tax where you have to pay 10 times more than your average monthly spend just to enable single sign- on.

Jara Rowe: Wow, I did not know that that was a thing you could make money from.

Michael Magyar: Yeah. Another one we can look at is can we export logs? So if we have somebody sign in, can we keep track of that? If that user is breached, can we go back and do forensics on it and see what they did inside of that product? If the product allows us to export logs to our own SIM or log management solution, then we can put detections around them and we can do those things. If we're able to enable SSO and single sign- on, a lot of times we can push those logs back to our identity provider, at least from a sign- in standpoint, but we still miss those internal logs of what happened in the system? What data did they access? Et cetera. So how extensive their logs are and how easy it is for us to get them is very important too. So back to your question, can we get logs? Can we enable good authentication on our users? Those are two very good capabilities.

Jara Rowe: Why is it essential for businesses to regularly check in on cybersecurity with their external partners?

Michael Magyar: There are life changes, companies change, leadership changes, technology changes. And so if we just do a single point in time audit, can we rely upon that for a month, a year, 10 years, 20 years? While some audits like FedRAMP require annual audits and they're very detailed, other audits just are a single point in time. I think it's important to reevaluate because the companies themselves have to reevaluate themselves. Our own internal certifications and regulatory requirements might require us to evaluate vendors on a yearly basis. So that's another reason we should do it too.

Jara Rowe: Say my company, we decided to sign on with the vendor to make our lives a little easier, but there was actually a security incident. What steps do I take to address the situation?

Michael Magyar: Yeah, these are not fun scenarios to be in. I think we have to think again about what information is in that vendor. If it's an internal product and we think that was breached, maybe we're hosting a VPN product or a firewall or our email server, what information could be affected by this breach? And that can change a lot of how we respond to it. I think another thing we should consider is what access that product or service has to the rest of our environment. In the example of Dropbox Sign, there were concerns about access keys that might've been part of that breach. And so not only do we need to think about the information that could be impacted, but which of our systems could be impacted. And we need to think about, " Okay, can we block access with those keys?" CircleCI, which is a common testing platform for software development, was breached several years ago, and there's access to our production environment to deploy our application code through CircleCI. So we need to see not only what information is affected, but how that could be used by a threat actor to pivot into another piece of our organization. Those are two really important things to start with your evaluation process and containment. Can we contain the threat actor's current access to our product or can we contain how that can be pivoted right away? Traditional incident response steps. But we also should start thinking about calling our lawyers, calling our incident response firms that hopefully we have on retainer, calling our insurance companies, although we should be a little careful with how we work with them. Sometimes it's better to talk to lawyers first. There's important information you want to be careful about sharing. And on top of that, we also have to think about breach notifications. So if we did have data that was sensitive or PII, we might have to notify parties that we were breached.

Jara Rowe: Yeah, for sure. Well, Michael, we have covered so much helpful information in this episode, but is there anything you want to make sure that you cover that we haven't already?

Michael Magyar: Absolutely. This is very concerning and it's scary, and yes, we should be concerned, but I think we need to realize we have to use these vendors to do business. If we try to not use these vendors, we would have to create the hardware and software. So we have to use these things and we should still be concerned, but not to the point of not doing business. We should ask what we can do to mitigate against a breach, how can we evaluate vendors, but also what can we put around those vendors to detect if there is a breach? So just keep that in mind. We should still do business, this is scary, but it's not the end of the world. We can still move along and still operate.

Jara Rowe: Fantastic. Michael, thanks so much for your time.

Michael Magyar: Thank you, Jar. Have a great rest of your day.

Jara Rowe: Now that we've spilled the tea on third party security, it's time to go over the receipts. I really enjoyed my conversation with Michael and all of the real life examples he was able to give me and you listeners as well. So let's dive straight into the receipts. The first one I have is what are vendors and third parties? Simply put, which is honestly probably oversimplifying it is that vendors are just viewed as outsourced staff. So credit card usage, if you were at a food truck like Michael was saying, or a third party cloud something and you save your photos or things like that in the cloud, or even a contractor if you need graphic design help or something like that. So anyone that could potentially gain access to your environment or your customer's information. So like I mentioned, just think of it super simply as outsourced staff. So I asked Michael about how we should identify potential risks when it comes to working with a vendor or third party. And he mentioned that it's almost impossible simply because we don't have access to the ins and outs of their own environments. But he did mention that we should look for public statements of security. Michael and I also talked about some key cybersecurity measures that we want these vendors to have in place. So this is more so for us as a potential customer. Can we deploy MFA or single sign on when it comes to our staff needing to access this vendor's environment? And I also thought it was very interesting. This is yet another episode that mentions MFA. So if you have not already flipped that switch to turn multifactor authentication on on the accounts that you have, please do so. The final receipt that I have would be if we were to work with a vendor and they experienced some sort of incident or breach. So these steps that we would take are simplified, but I think it'll help everyone just gain a better understanding of what to do. So first up, we need to decide what info could be affected from the breach and how can that info be used? Next, we also need to determine what access that third party has into our own environment and then also try to figure out how to contain the issues if it's something that actually needs to be contained. And then the final thing would be to deploy an incident response. So figuring out all the crucial people that need to be a part of next steps. So maybe you need to contact your lawyer. You may want to contact your cybersecurity expert like a inaudible for their help and assistance. And you also want to contact your cyber insurance company as well. And then to help figure out additional communications to your customers and anything else that would need to be covered, but your inaudible or your cybersecurity partner be able to help guide that conversation if something were to happen. Thank you for tuning in to another episode of The Tea on Cybersecurity. I hope you have a better understanding of third party security the way that I do. See you on the next episode. And that's The Tea on Cybersecurity. If you liked what you listen to, please leave a review. If you need anything else from me, head on over to Trava Security. Follow wherever you get your podcasts.