Someone Else’s Key: The Uncomfortable Truth About Third-Party Security
You lock your apartment door before leaving. You check it once. Maybe twice. Just to be sure. You might even have a camera at the entrance, a reinforced lock, maybe good insurance. You feel safe. You’ve done your part.
What you usually don’t think about is how many other people could still get in. The cleaning service might have a key. Your landlord definitely has one. Maybe the previous tenant never returned theirs.
And if one of those keys gets copied, lost, or misused, it doesn't matter how good your own lock is. And that is exactly how a lot of the big incidents nowadays start. Not by brute-forcing the main door, but by using the already opened side door.
Banks were affected because of a shared third-party vendor. A large company exposed millions of records after unauthorized access through an external connection. Even big organizations with good security setups suddenly found themselves compromised. Their systems worked, their security was good, but someone else's wasn't.
The idea is not new. Companies often have connections to other companies that take over specific services or tasks. In the past, though, it was often just a file share that they could access. Today, they can often connect to a network via VPN and access so much more. So much more that is valuable for attackers. Attacking a third-party company that serves many other companies is far more worthwhile than attacking a single company, since they can use that third party to compromise dozens or hundreds of potential targets.
We've seen it in software development as well. Why hack software that is hard to reach when you can compromise a single external component with your key-stealing malware?
With that, a single simple phishing attack against a third-party provider can eliminate all your security measures. No zero-day needed, just compromising a vendor with a phishing attack. Their security is out of your scope. You can try to control it when setting up the contract, but that's all.
And the scale of that simple but effective way of hacking becomes visible when you look at recent incidents.
Citizens Financial and Frost Bank were both compromised on the same day through one shared vendor. Millions of datasets were exposed without a direct attack on the banks. A simple attack outside of their scope. Similar to a cleaning company that has access to multiple properties losing its master key.
Something similar happened to Vimeo. Not a direct breach, but through a third-party monitoring service they were using and trusting. That service was compromised, and attackers moved on from there. They extracted customer data, metadata, and internal information without any unusual-looking connections inside Vimeo’s secure environment. The stakes are high for such attacks, as for any others. Loss of trust, legal processes, regulatory pressure, fines, recovery time, external professionals supporting incident response, and so on.
It can be a phishing email, VPN accounts sold on the darknet, or simply credentials being reused across systems.
What is dangerous is that you don't see it immediately. If your systems get attacked, you hopefully see alerts like failed logins, unusual traffic, or some other anomaly. But if the attack goes through a trusted vendor, you don’t see anything abnormal. Everything looks fine because it is technically trusted. Valid connections, correct credentials, allowed access. Everything behaves exactly as designed. That makes detection much harder.
If we don’t have control over the security of vendors, what can we actively do to lower the risk of being a victim of such an attack?
Limit everything as narrowly as possible. Some vendor employee leaves the project? Revoke access. A project finished? Remove vendor access. We all know how it goes: permissions grow and grow over time, and nobody knows exactly who can access what. Make sure you see it. Make sure you know at a glance who can access what to narrow down potential attack vectors. Tracking this or cleaning up permissions is not very convenient. But when we choose convenience over security, we lose the race against attackers.
Also question every connection. Is it necessary? Is it needed during normal operations? Is the project still active? Is the user still working on that project? Make every external connection visible so you are able to answer what is connected, what it can access, and who is part of that group. That makes it easier to track down a potential attack. And keep it updated. Don’t document it once in your internal wiki and then forget about it for the next five years.
What is the potential impact? Personal information being exposed. Financial data being at risk. Follow-up attacks based on the exposed data. Ransom demands without ever having an alert in your SIEM. Reputation damage. Identity theft, and so on.
So if we go back to the apartment example, we can transfer exactly what we’ve described to the physical world. You won’t see any traces of a burglary at the locks or windows if someone breaks in with a key. They can steal things and sell them, expose private belongings to damage your reputation, or demand a ransom. Don’t just take care of the security of your locks, also know who can access them.
And this is the uncomfortable reality we are in right now. We can secure our systems as well as possible, spend a lot of money, and still remain vulnerable because someone is misusing trusted connections. Context matters. That’s one of the risks of having highly interconnected systems at this scale.