The scale of these breaches has brought the issue of NoSQL security to the attention of the masses, but it would be a mistake to think that NoSQL databases are inherently insecure, far from it. NoSQL databases can be just as secure as their transactional and analytical counterparts, provided that users follow best practice and NoSQL vendors adopt more secure-by-default features.
So what exactly does NoSQL cyber-security best practice look like? Answer: A lot like other areas of cyber-security best practice. First and foremost, better information security requires a mindset shift, which means having technology, process and people working together to become more secure. NoSQL is no different. All NoSQL database installations should follow the best practice steps outlined below, none of which are overly complicated or time consuming:
Choosing the right NoSQL provider is paramount. Finding a provider that has built in security at the forefront of their services, rather than tacked on as an afterthought, can help take the onus off the developer and may make the difference between being breached or not. Having a database with secure-by-default features makes it much easier to follow best practice and makes it harder for users to shoot themselves in the foot.
In evaluating the security of a database, organisations should focus on the comprehensiveness of a vendor's understanding of end-to-end security, the existence of clear vulnerability reporting and handling policies, and ease of implementation of security capabilities. NoSQL databases are relatively young when compared to legacy databases and are constantly improving, which means that understanding a technology's security roadmap is even more important.
NEVER expose databases to the internet: The first cardinal rule of any database security strategy is never expose your database to the internet. A strong firewall is an essential tool in any database security strategy. It's important for all nodes to be stored behind a database firewall to protect access to sensitive information. This was a step ignored by the vast majority of NoSQL breach victims this year – if not all of them.
The server operating system must be kept up-to-date with the latest security patches. WannaCry and Spectre/Meltdown have been seminal moments for the cyber-security industry, and both are prime examples of the importance of patch management. It's staggering to think how much pain and suffering could have been avoided had these machines been kept up to date with the latest software updates.
“Default” and sample databases should be deleted, no exceptions. Default is not a word that people in the security industry like, and for good reason. When used in a sentence, it can invariably be replaced with the word insecure: default passwords = insecure passwords, default settings = insecure settings etc, etc.
On a similar note, organisations should use a strong and unique passwords for all databases. The nature of OpenSource means that it's easy to find installers online that incorporate outdated or misguided security settings, including default passwords. This just means that businesses need to be extra-vigilant when embarking on any new project.
Securing data at rest and in transit: Businesses are continuously transferring data both internally and externally, which can potentially expose data to unauthorised parties. Administrators can secure data in-transit by enforcing SSL connections for client/server and server/server communication and at-rest using file system encryption or more extensive encryption products.
We haven't seen the last of NoSQL data breaches but, in 2018 and beyond, the hope is that the events of 2017 and the sheer number of breaches will be a much-needed wake-up call. Provided users heed the advice above and start taking NoSQL security more seriously, the year ahead promises to be much brighter.
Contributed by Perry Krug, principal architect, Couchbase.*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media UK or Haymarket Media.