Whoever said crime doesn’t pay hasn’t heard of “Ransomware-as-a-Service.” The cliched image of a salty hacker in a dark room, punching out lines of code as they play hide-and-seek with preventative cybersecurity measures is more a movie trope than anything else. Modern online attacks are often industrialized in terms of automation and scale and are very lucrative.
And you don’t even need ransomware encrypting files. That’s what is so interesting about the recent hack of some 23,000 MongoDB databases. An apparently lone hacker scripted an attack on thousands of such databases whose administrators had left them password unprotected. The attacker wiped the data and left a note demanding a ransom and threatening to report the breach to the relevant GDPR authorities.
The intent was that the data owners would panic and pay an admittedly small ransom in the hopes of getting their data back. Above all, the criminal(s) involved knew that paying a small ransom — even if there is no guaranteed return on data — is better and cheaper than GDPR scrutiny and fines. They’re not wrong, and it’s telling that the same laws meant to reduce cybercrimes are now being used by criminals to turn the screws on data owners. Sophisticated? Not particularly. But clever? Yes, very clever.
The sheer complexity of maintaining a cost-effective database environment has led many companies to take unfortunate shortcuts or try to move that risk wholesale to third-party providers.
And so utterly avoidable. Not the criminals, they’re omnipresent, but those database policies that open the doors to such a broadside breach tactic. A common misconfiguration, failure to enable password protection or a lapsed policy consideration can lead to a wide-scale scripted attack. These kinds of cyberattacks abound precisely because they’re so easy and low-risk — the proverbial low-hanging fruit, if you will. Think about the implications though, for business continuity- and/or cyber-insurance. The underwriting agent’s expression must have been priceless as he or she queried: “You didn’t password-protect your database? And you expect us to pay? Do you even know how insurance works?”
Bad actors are breaching databases because administrators are leaving the virtual keys in the door, which is also ajar. And I believe the reason comes down to one factor: the sheer complexity of maintaining a cost-effective database environment has led many companies to take unfortunate shortcuts or try to move that risk wholesale to third-party providers.
Virtual private clouds (VPCs) are an example of the latter type of solution. Some types of data simply aren’t suited for public cloud storage, so enterprises want private clouds instead. But they also want to avoid the headaches of infrastructure ownership, so they use a VPC. This approach blends the benefits of the cloud with a private data storage environment, without the headaches.
Yet there are compromises, such as data sovereignty and visibility. Another is that they might not notice the cracks in their policies to secure that data — this lapse stems from culturally handing off the responsibilities that would have led them to those cracks. But doing the opposite — taking full control — neither alleviates the complexity nor the cost issues around database infrastructure.
One answer is to do both: use a VPC environment, but one in which visibility and data control remain squarely in your hands. This emerging best practice is known as in-VPC database deployment. The concept is simple: deploy a virtual private cloud but use independently developed software to separate the database layer’s control plane and visibility from the infrastructure. This design reduces your dependence upon your cloud providers bundled-in software packages, which are often black boxes that block transparency. This deployment philosophy allows you to continue maintaining your own security best practices to fully control your data’s security and location while also clearly understanding your performance, consumption patterns and spend.
In-VPC also ensures that if compliance and policy are already in place, migrating to a VPC environment won’t undo all that work, as your business does not cede control of its data, but instead retains the integrity of your efforts to become compliant with regulations as laid out by GDPR, CPPA, HIPAA, and other regulatory bodies. Nor does the enterprise run the risk of becoming locked into a specific provider. An in-VPC deployment delivers the best of three worlds: cloud’s OPEX and scale, the cloud provider’s skills and security investment, and an unbroken natural extension of policy, compliance, and data sovereignty controlled by the data owner.
It’s worth reiterating: a seemingly lone criminal launched a scaled attack on tens of thousands of databases, all likely misconfigured because that responsibility got lost in the fog of provider-customer engagements and lax password enforcement featured by software providers. Maybe someone thought an SLA would cover the shortfall. Whatever the cause, this smacks of the Someone Else’s Problem field, that devious cloaking device from the Hitchhiker’s Guide novels.
It was only a matter of time before customers learned that their problems and cloud providers’ problems are not always one and the same. Criminals are exploiting this flaw. They are literally threatening to call the cops after burglarizing you, so you get punished for the poor security. That’s crazy, but not stupid. The only foolish thing is thinking someone else cares more about your data than you do. Separating those responsibilities by using tools in the cloud can deliver all the promise of cloud infrastructure without compromising the due diligence of data owners. Don’t indiscriminately deploy your data to the cloud in whatever fashion is up for grabs. If you don’t retain control, then very soon some script-writing cybercriminal will seize it.
Feature image by Aline Dassel de Pixabay.
