When attackers targeted Australian health insurer Medibank in October 2022, every single one of the company’s 3.9 million policyholders had their data exposed, along with many past customers. That raises a troubling question: how could so much data walk out the door all at once? Probably more easily than anyone expected.
Many databases are designed to allow users (any user) to export unlimited amounts of whatever data they want. As long as a user can authenticate their way into the database, they have free rein over the contents and little to nothing prevents them from downloading the whole thing. That’s why in the Medibank example and so many others, we see that data breaches quickly escalate to massive scale and catastrophic consequences (the breach will cost Medibank at least $35 million). There’s a simple explanation for why: attackers can easily export as much data as they want, so why not take it all?
The self-evident solution would seem to be capping data exports, yet many companies have yet to take this step. In this blog post, we want to explore why, then highlight how easily companies like Medibank could have kept the attack from becoming the devastating breach that it did.
Outdated Attitudes About Database Security
Databases of the past lived securely inside corporate networks and had little need for authentication or access controls. Database administrators were the only ones going into the databases and taking data out, and that was probably only a few people at most. Granting them easy database access and broad privileges to export data posed little risk and only helped the DBAs be more productive. Security wasn’t a priority for the simple fact that it didn’t need to be.
The situation looks much different today. Databases get accessed constantly by far more people than just the DBAs, including a fast-growing number of applications and services hungry for information. No longer the quiet center of the tech stack, databases now see flurries of requests from developers, data analysts, applications, and BI tools (just to name a few). The way we use databases has transformed over the last 20 years. The way we secure them, however, remains trapped in the past.
Cyral Founder and CEO, Manav Mital, and I spoke about why databases need more robust authentication measures, along with access that consists of only the least privileges necessary in a recent webinar Automate Least Privilege for Data. It’s vital to rethink who gets into the databases, how, and what they can do inside. But if one area of database security matters most, it’s what people have permission to export. Fraudulent database access is bad, but data theft cuts much deeper. One big reason data breaches recently hit an all-time high and the number of records exposed keeps going up is, quite simply, that strict export controls are still not the norm.
We allow a breach to happen. That means we can deny it too.
Learning From the ATM Example
The financial services industry learned long ago that when the risk of fraud is high, trust needs to be low. That’s why you can only withdraw a certain amount each day from an ATM – if someone stole your card and PIN, they couldn’t empty your account.
It’s a potent example about facing up to the reality of risk. ATM providers know that fraud is inevitable. And they admit that they can’t see or stop every instance. So they take preventative measures in the form of withdrawal limits for users but provide reliable and meaningful fraud prevention as a result. If you need access to funds beyond the daily limit, you can escalate privileges with a teller inside the bank.
The same goes for database security. In the same way that someone wouldn’t withdraw their life savings from an ATM, a legitimate database user would never need to download a million social security numbers at once. So why even make it possible? Limiting the type or quantity of sensitive data that people can take from the database are rarely disruptive for legitimate users. These security controls, however, are a extremely effective and undermining would-be attackers and thwart data breaches right before data can be exfiltrated.
ATMs use strict controls and powerful protections as the last line of defense – right before a machine dispenses the cash. It’s only logical that databases do the same.
Adding Export Controls to Existing Databases
The case for putting export controls on databases couldn’t be stronger, and the inverse reinforces it even more: why not put controls in place?
That leads to the question of how? The vast majority of databases have only two types of roles, admins and users, and only few types of access, including read/write and read/only. The options leave no way to put hard limits on data exports, so the worst-case scenario – losing everything – is still on the table. They also leave no way to grant least privileged access, which compromises both security and productivity. Finally, databases don’t create audit trails of who accesses what data, making it difficult to refine access and export controls over time. All databases need these controls – none have them natively.
Cyral created a platform that integrates with the most popular database products on the market so companies could manage access like never before. Among other things, Cyral adds policy-based access controls to databases so that users can only see and take the data (down to the field level) they’re allowed to. And with just that, the risk of data breaches drops dramatically.
Data researcher, Alissa Knight, put Cyral to the test in her new research Dark Tide Rising: Hacking and Securing Sensitive Datasets. You can see exactly how data masking and rate limiting stopped her from gaining unfettered access to sensitive data.
