Protecting Your Data From RansomwarePublished July 6, 2017 by Matt Kelly • 3 min read
On a certain aesthetic level, you have to admire ransomware attacks. At first glance they seem like just another headache under the broad category of “cybersecurity risk”—but nothing could be further from the truth.
Ransomware is fundamentally different from run-of-the-mill threats like network penetration attacks or phishing scams to get the CEO to email employees’ personal data. Foremost, nothing gets “stolen” in the traditional sense of the word—which can mean, under a strict reading of the law, that ransomware attacks don’t need to be disclosed.
That crucial distinction has big implications for your internal controls and third-party oversight so that your firm doesn’t fall into ransomware’s trap. Let’s take a look.
First, ransomware doesn’t necessarily trigger a duty to disclose, because ransomware doesn’t steal data in the same manner as traditional cybersecurity attacks. That is, if the attack only locks employees out of their IT systems, the data itself hasn’t been compromised. If the victim company then pays the perpetrators and the lock is released, the data was never harmed. Customers weren’t exposed to the threat of identity theft.
Under a scenario like that, the argument to pay the ransom and keep your mouth shut can be compelling. The ransomware perpetrators usually don’t ask for much money: an average of $1,077 in 2016, according to a report from Symantec. Disclosing a ransomware attack can invite regulatory scrutiny of your control environment. It can bring unwelcome headlines. It can alienate customers. So why not fork over the bitcoin and then scramble (quietly) to clean up your data access and security controls?
At large companies, keeping quiet about ransomware probably isn’t feasible. Too many employees might talk; too many operations can get disrupted. The unsettling question, rather, is whether your data service providers are not disclosing ransomware attacks to you.
Protecting Your Data from Ransomware: Enter the SOC 2 Audit
Measures to prevent that sort of abuse are easy enough to envision: include clauses in your contracts with data service providers requiring them to tell you when they experience a ransomware attack. (“Any disruption in service caused by an outside entity seeking financial reward” might be a better way to phrase it.) We still have two problems:
- Your data service provider might lie to you about having good security;
- Your data service provider might not know it has bad security.
An excellent tool to address the first two points is the SOC 2 audit: a special type of audit that examines the security controls of a data service provider. The tricky part is that SOC 2 audits can be designed any way you want—so setting the scope of a SOC 2 audit wisely, to include the risks that ransomware brings, becomes crucial. (I wrote a more detailed post on this subject for Reciprocity Labs not long ago.)
For example, SOC 2 audits can be based on any of five principles, including security, privacy, and availability. Well, if your data service provider suffers a “screenlock” ransomware attack, where users can’t log onto their IT systems to access data, that’s a weakness in availability—but if your SOC 2 audit only examined security and privacy controls, you might discover the availability flaw the hard way.
So you, the large corporation using data service providers, need to ask: What are our most critical assets? To what extent is access a critical asset? What are our disclosure obligations if we don’t have access—even to customers or investors, if not regulators? Have we matched those needs to the correct data service providers in our extended enterprise, and designed SOC 2 audits to match those needs?
Your IT audit or IT security folks will probably oversee the obtaining of SOC 2 audits from your data service providers. The compliance officer’s role is to help tailor the scope of those audits correctly: to identify your regulatory requirements (after all, even if your provider doesn’t have a duty to disclose a ransomware attack, you might), and ensure that those requirements translate into tests and evidence the SOC 2 audit provides.
Just remember that even under the best of circumstances, organizations are reluctant to disclose cybersecurity attacks. Ransomware, in particular, might not have any force of law that compels a victim to disclose; and the temptation to pay up quietly is great.
Will your data service providers ever be entirely immune from ransomware? No.
SOC 2 audits and carefully crafted service-level agreements, however, can at least mitigate the risk that you’ll be left in the dark when they fall victim with your data. That, in turn, will bring added pressure to your service providers to pay even more heed to cybersecurity risk—and lord knows, we all need.