Last week I cited the rising importance of vendor risk management as one of the big compliance events to watch in 2018. One week into the year, we have a great example of just how slippery this challenge can be.
The example comes from Meltdown and Spectre, security flaws announced last week that exist in virtually every computing device today: every PC, phone, tablet, and server, regardless of manufacturer. With some clever hacking, outsiders could exploit those flaws to steal encryption keys, data, passwords, and anything else your organization wants to keep secure.
The good news is that Meltdown and Spectre aren’t dire threats. Using them to steal data is quite difficult; hackers can’t easily reach through the Internet and manipulate these weaknesses from some perch in Iran or Russia or New Jersey. Frankly, corporate IT systems have plenty of other weaknesses that hackers can exploit more easily to steal your online crown jewels.
Still, these particular flaws are so maddening because they are in the microchips themselves, rather than in software like most other flaws. Since almost all microchips use the same basic design, this means the flaws are in almost every machine that exists today. And because redesign of a microchip takes years, it will be years before “safe” chips reach the market and we’ll be rid of these threats once and for all.
Until that day comes, companies need to depend on software fixes. Those patches tweak the code running on the faulty chips, so the software operates securely despite the vulnerabilities the chip has. Hence, when Meltdown and Spectre were announced, software companies rushed out patches that customers should install immediately.
Which brings us, yet again, to cybersecurity risk and vendor risk management.
Have Procedures in Place
Meltdown and Spectre are vendor risk management threats because so many companies now use software (or other IT services) provided over the cloud. That is, the faulty chips aren’t on any machines you can control. You might never know where the machines are that run the software you use.
You only know the software vendor contracted to provide services to you. So you need some mechanism to assure that they implement these patches in a timely manner, to protect your data. Therefore, some questions to ask yourself…
- Do we know all the vendors providing IT services to us?
- Do we know all the vendors that specifically have access to data that’s proprietary, or that qualifies as personally identifiable information subject to privacy regulations?
- Do those vendors have policies in place for timely software updates, when security threats are discovered?
- Do our vendors communicate those policies to us, so we know what’s going on?
- Do we have SOC 2 reports on all the vendors that handle our sensitive data?
- Can we audit those vendors’ patch management programs, if our data is sensitive enough to be worth that level of attention?
Spoiler alert: for many companies, the answer to those questions is no. Last fall the Ponemon Institute published a survey of 625 corporate executives that asked about their vendor risk management, and the news was not good. The average number of third parties with access to your company’s sensitive information rose 25 percent last year, from 378 to 471 third parties. Meanwhile, 57 percent of survey respondents said they can’t determine whether a vendor’s safeguards and security policies will actually prevent a breach as promised.
Now, we can give most vendors some benefit of the doubt. Meltdown and Spectre are problems for them, too, so a great many of them probably will implement these patches as soon as they can. For your company, however, the question is how you can gain assurance that those patches have happened.
After all, should the worst happen, and some hacker does steal your corporate data by exploiting Meltdown and Spectre at a cloud-based service provider — your company will be the one facing unhappy regulators, customers, or board directors. If you have to admit that you didn’t know the vendor had access to your sensitive data, or that you didn’t confirm their security protocols, prepare for an awkward conversation after that.
We also need to remember that while cloud-based vendors are the most pressing risk, your organization might have some internal risks too. For example, some of your applications might be purchased and running on machines you own. That means you’ll need your own patch management process to protect those devices. You might want to revisit the company’s IT usage policy, and remind employees not to install their own equipment without consulting the IT department first.
Even better: the patches that software vendors are offering do impede the chips’ performance. For most of us, fiddling with databases or typing memos and emails, that slower performance will be negligible. But for some data-intensive chores (modeling the weather, for example, or other data visualization work), the slower processing speeds could degrade your performance to a material degree. And if you’re providing those services to others, you might violate some contractual obligation to them.
Enter Vendor Risk Management
At large organizations, the IT security teams should already understand most of these consequences. And remediating the effects of Meltdown and Spectre is their responsibility, not yours. Nobody is saying the compliance, audit, or risk management team should be going around installing software patches themselves.
You should, however, be going around and talking to all relevant parties within your organization to be sure they understand these risks and have a system in place to govern them.
For example, the internal audit team should regularly assess cybersecurity and patch management processes, but the audit team also needs to understand that the nature of this risk has changed. Your own organization’s patch management might be peachy, but that won’t make a whit of difference if the contracts you have with cloud-based vendors are a mess. Or, worse, you don’t even know what the contracts say, because nobody is tracking the vendors that your employees are using.
Meltdown and Spectre show that cybersecurity risk has evolved, and the corporate response evolve along with it. We’ve gone from “How can we protect our data?” to “How can we assure that our data, wherever it may be, is protected?”
There’s a world of difference in those two statements. The first implies that you can control what you have; that your company can exert “agency” in a direct way. The second implies that you need a process to protect yourself in a much more complex, “open-border” environment. The second is about assessing risk accurately and building strong processes in response.
That’s what compliance, risk, and audit professionals were born to do. I suspect we’ll be doing a lot more of it, in 2018 and beyond.