Database security – You need to pay better attention to it

Almost 2 years ago, it was reported that over 10,000 MongoDB databases had been deleted by ransomware groups – and much of that was done in a week’s time. Let that sink in for a minute – 10,000 databases in a week – it’s mind boggling. Makes you think twice about your own databases, doesn’t it? Now the truth is that most of these compromised databases were, I’m sure, either poorly configured or poorly secured databases, set up by business organizations with limited IT focus (or perhaps even limited IT common sense). Constantin’s article also mentions that the ransomware groups didn’t back up the data, so even when the targeted companies paid the ransom, their data was lost anyway.

But it doesn’t stop there – another article reports that CouchDB, Elasticsearch and Hadoop databases are also being targeted. Some of these attacks aren’t even ransom-related, but could be classified simply as vandalism. And the sad thing is that it isn’t ending anytime soon – at least one of the ransomware groups is actually selling its ransomware attack toolkit on the dark web.

So why is this happening? Well, ransomware has been around for a while – it’s just one more of many heinous hacker criminal activities – and it started as a very simple, straight forward attack. Fool a computer user into clicking a nefarious link, secretly download some nefarious code, encrypt some or all files, and demand payment to de-encrypt the data. Pretty simple; easy money. It’s happening now to companies running these relatively new types of databases because they’re everywhere, they’re easy to learn, often not well secured, and more importantly, a business typically has more money to extract, and exhibits more urgency when their data is threatened.

So why doesn’t this happen to more robust and secure databases like Oracle, or even the most secure database in the world – mainframe Db2? Well, it does happen. It’s just that it happens less often, and you’re less likely to hear about it. (Although with GDPR, that may be changing.)  But it is still less likely to happen because there are fewer criminals who know both how to make their way around the internet and connected systems, and how to access data from a mainframe. There’s just so much more to learn, so there are fewer criminals with the necessary knowledge.

But there are plenty of smart criminals out there, and mainframe systems can be compromised. If you can fool a person with high-level IT access, you may very well be able to obtain system access, no matter how robust security systems are. And that applies to IT personnel associated with Db2 databases.  Unfortunately, those people are the biggest threat to corporate data – whether they are honest or not. Code flaws, errors in judgement concerning incoming personal emails, overlooking blind spots, and ignorance of the latest risks can all conspire to turn an honest and capable IT professional into a serious threat to company assets.

At the end of the day, no one IT person should be a single point of failure; a company needs to understand this, and to put best practice safeguards in place. It is great to have the most secure system in the world guarding your precious company data, but you also must have the most effective security practices in the world in place for it to make a difference. And putting those security practices in place is up to you.