Is Your Big Data Vulnerable?
The year 2017 started on a dramatic Hollywood-style note for a few database-service providers. In a series of events, some database became victim of ransomware. This raised questions about the security of cloud-based databases which has been the biggest drawback of cloud so far.
MongoDB and Elasticsearch Fell Victim
In what seemed to be a hacking attempt by an individual or a group, thousands of MongoDB-based databases fell victim to a cyber-attack. The hacker claimed to have access to many databases and threatened to delete or encrypt the data if a ransom was not paid.
While many were trying to get over the MongoDB instance, another news regarding Elasticsearch clusters started doing rounds. In this case, the data was deleted from the cluster and a message asking for ransom was left behind. Experts are working on establishing whether this is an isolated event or is it related to the MongoDB attack.
Hadoop and CouchDB Instances
When Hadoop and CouchDB started facing similar issues where data was deleted from the instances, the first thought that crossed many peoples mind was that these have also been hit by ransomware. But, the reality came out to be different than thought. The hackers targeting Hadoop left messages that asked for stronger security systems to avoid such attacks, the CouchDB instances turned out to be ransomware.
Like in almost all ransom cases, Big data developers experts do not believe that the ransom should be paid because there is no guarantee that the hackers have taken a back-up of your data before deleting it.
The Mistakes
These attacks do not naturally imply that databases are not safe for data. It throws light on the mistakes that people often make by subjecting the database to public forum and many such issues like these. Immediately after the attacks on MongoDB, Elasticsearch, CouchDB, and Hadoop, companies and database experts starting sharing blogs on the common mistakes that make us prone to such attacks.
- Not following the security established security protocols is the biggest mistake. Almost all service providers have a recommended setting which can be altered if required. The recommended settings usually provide enough freedom to work without restrictions and also disable features that might expose us to attacks. Many times, we enable features to experiment or work and leave them that way without realizing the after effects. A good way is to follow the security settings without fail.
- There are many preventive measures as well. In the cases discussed above, the victims deployments were exposed to the Internet and this is what made them vulnerable. Creating a simple alert which will send prompt to you in case your deployment is exposed will help you keep an eye on any suspicious activity. For example, in MongoDB, users can create alerts in Cloud Manager by setting the target as Host, host type as of any type, and condition/metric as is exposed to the public Internet.
- It is a big mistake to not have a backup of data and completely relying on the database instances and deployments. Incidents like these can happen with any system no matter how full proof it claims to be. Therefore, it is imperative to have a system where backup of data is taken and maintained locally. There can be a protocol in terms of how frequently this activity needs to be repeated.
It is these mistakes and not a lapse in database security system that has enabled hackers to delete the data. It is better to understand that each of the platform has a security system and the suggestions to tackle the ransomware issue would differ from one to other. For details on how MongoDB, Elasticsearch, CouchDB, and Hadoop suggest handling the issue, visit the respective pages.
The Preventive Steps
If you have already become a victim of the ransomware, you and your team would have by now known what went wrong and how to overcome the issue. If not, the official pages above would serve as the best guide. But, if you have not become a victim yet, then it is time to revisit a few things:
- Check your security settings and comply to with the recommendations unless you have a strong reason for not doing that. If possible, disable or enable the required settings only temporarily and then restore it to the recommended settings.
- Check your internal data breach policy for clauses on how to tackle such attacks. If you have a plan that serves a purpose in such cases, then no need to worry. But, if you do not have a clause for this, then you should immediately include one.
- Create a back-up procedure right away if you have not been doing that so far. This is extremely important not only because of the current incidents, but also because back up can prevent loss of important data which can happen for numerous reasons.
Unfortunately, attacks like these only seem to be increasing without any respite in the future. Our best chances are to avoid making common mistakes and have a plan to curb issues like these if they ever crop up.
