NoSQL, no problem: securing non-relational databases
NoSQL, no problem: securing non-relational databases
NoSQL databases were created to offer organisations a new way of managing their data. More aligned with modern consumer expectations of the digital experience, they are an alternative to traditional transactional or analytical databases. However, in 2017 a selection of some of the most popular NoSQL databases fell victim to devastating ransomware attacks. A combination of user error and poor vendor design choices meant that tens of thousands of databases were infected, many of which were wiped out entirely. 

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.

Last but by no means least, if you do find a security hole, report it immediately so that you can help the wider community. No one wins through collective silence, only the hackers

We will continue to see new holes in security and new vulnerabilities discovered. A product is typically built with a set of assumptions, and the (holes) insecurities are based on violated bad assumptions. Getting the assumptions perfectly correct from the very start is very hard. For organisations to achieve this, it is important to understand and accept that hackers are getting more sophisticated, and are constantly developing new tactics, techniques and procedures to disrupt businesses. With attackers always out there to get to your data, businesses must continually invest in security and emphasise the importance of security education and best practice. 

There must also be a shift in mindset within a business so that security and compliance is viewed as a shared responsibility. This includes the developers at the coalface of web, mobile and app design, as well as the CIO and business tech roles, who may have chosen the NoSQL platform in the first instance under the scope of the original project. For the NoSQL vendors themselves, organisations are placing their data and their trust in them, and there is a responsibility to honour this trust. They must ensure that users are fully confident in their ability to protect their data, by making good security as easy as possible, with services that are secure by default, not through additional steps that may be onerous or confusing to the user. 

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.