The conversation I have repeated most this year doesn't start with a technical question. It starts with an uncomfortable sentence: “we were attacked, but the attack didn't come in through us.”
And after that sentence there is always a silence, and out of the silence comes the question that really matters: whose problem is this now?
Whose problem is it when the attack comes in through someone else?
It is worth taking a mental inventory. The vendor that invoices you. The one with a VPN open to provide support. The software firm that manages your ERP and logs in with a privileged account. The accounting firm that keeps your entire payroll. The tool someone on your team signed up for in three clicks with the corporate card and that today reads the email of half the company.
All of them are inside. Not figuratively: they have a username, permissions and a key you haven't reviewed in months.
Legally, responsibility can be shared, and that is what contracts and lawyers are for. In practice, the split is far less elegant. The customer whose data was leaked doesn't call the vendor: they call you. The regulator doesn't write to the vendor: it writes to you. And the name that appears in the press release is not the vendor's.
Your vendor had the incident. You have the problem.
The two numbers worth taking to the board
There is no need to fill a presentation. Two figures are enough, and both are from this year.
The first: the annual Verizon data breach report found that 48% of the breaches analyzed involved a third party. Almost half. And it is not a stable figure: it grew 60% compared with the previous year, which had already doubled.
The second is the one I find most revealing. According to the SecurityScorecard supply chain study, 78% of organizations acknowledge that their security program covers less than half of their vendor ecosystem.
Read them together and the picture becomes clear. Half of the attacks come in through the door almost no one is watching.
What will you be asked, and when?
You will be asked this sooner than you think, and it probably won't be the attacker who asks first.
Auditors are already asking about it. Parent companies ask about it when they consolidate risks. And cyber insurers ask about it in a very specific way, because the premium, and sometimes the coverage itself, depends on that answer: they want evidence that you monitor and that you know how to respond, and they want to know what happens when the one who fails is one of your third parties.
When I sit on that side of the table, there are three things I try to be able to answer without looking at my phone.
How many vendors have access to our systems today, with what permissions and since when. That list almost never exists, and when it is put together for the first time, there are usually people who shouldn't be on it.
If one of them is compromised in the early hours of this morning, how do we find out: do we detect it ourselves from that account's unusual behavior, or do we wait for the vendor to have the courage to call us three weeks later?
And what the contract says. Notification deadline, obligation to report, right to audit. If it is not in writing, it doesn't exist.
None of the three depends on the vendor. They depend on someone watching those accounts continuously, including the early hours of Saturday, which is when a stolen support credential gets its first use. I have already written about how to evaluate whoever you hire for that, when we discussed what to look for when choosing a security provider, and the criterion is the same one I now apply to the rest of the chain.
If you don't have that list of third-party access today, it is the first thing we put together in the free assessment. It is usually the part of the report that surprises people most, and not because of the technical details.
Because your company's attack surface no longer ends where your company ends. And neither does your responsibility.
