Why “NoSQL” doesn’t equal “insecure”

The NoSQL database is a product of the 21^st century desire to deliver increasingly fast, always-on digital experiences. Where traditional, so-called ‘relational’ databases require predictable, structured data, NoSQL (Not-Only-SQL) provides an extremely dynamic and cloud-friendly way for organisations to manage real-time, unstructured data. However, unlike traditional databases, which are almost always located on premises, some of the first NoSQL databases were exposed to the internet by default. This simple setup configuration has subsequently led to users of some of the most popular NoSQL databases falling victim to catastrophic ransomware attacks and reputation-crushing database leaks.

For example, in late 2017, reports suggested that tens of thousands of publicly-facing NoSQL databases had been accessed and held to ransom, with some even wiped when users failed to pay up. More recently, cybersecurity researchers have continued to find troves of sensitive data laying unprotected in open databases. In September 2018, an unsecured database belonging to a Californian email marketing company leaked 11 million users’ personal data, including names, email addresses and physical addresses. And it hasn’t taken long for 2019 to see some potentially devastating leaks either; 202 million job-seekers in China had their CVs leaked by an unencrypted database, whilst smart doorbell company Ring was recently found to be giving access to every single customer’s camera footage to its R&D team – all because the company had not properly considered its security practices.

It’s no surprise that the volume of database leaks has garnered apprehension, but it would be wrong to write off NoSQL databases as fundamentally insecure. In truth, the issues primarily come down to user error and poor database design – two things that can be tackled. As long as vendors implement secure-by-default features and users follow security best practices, NoSQL databases are just as secure as their predecessors.

The proof is in the plan

It sounds crushingly simple, but businesses must plan to prevent leaks before they occur. Choosing the right NoSQL provider is clearly the first basic step. Don’t make the mistake of trusting your database with anyone that considers cybersecurity an addition to their services – it should be built into their systems from the outset. Make sure you question any providers about their knowledge of end-to-end security. Look at whether they show a history of responsibly reporting vulnerabilities. Ask about how easy it is to implement security capabilities around the database. Properly researching your provider may seem obvious, but it could make the difference between suffering a leak and not.

The next stage of planning your database security is to think about how your data is secured in transit. It’s a given for businesses that data will need to be transferred both internally and externally – this is not dangerous, in itself. However, the transferring of data externally has the potential to expose it to unauthorised third parties, because many businesses forget that encryption is vital for every dataset – regardless of where it’s stored. It’s therefore vital that you can secure data both at rest and in transit, by investing in SSL connections for client/server and server/server communications.

The security planning for your database doesn’t end when you roll out your NoSQL database. It’s essential that you have visibility of and continually review the security roadmap of your database. As NoSQL databases are relatively new to the technology scene and therefore constantly developing and improving, it’s vital to understand exactly how any upcoming improvements or launches will impact your cybersecurity policies or needs.

Five tips to security success

It’s one thing planning your NoSQL security process, but putting it into practice is a different story. Here are some key tips businesses must remember if they want to avoid catastrophic cyber-attacks:

• Never expose databases to the internet. When it comes to database security rules, this is as important as they come. If you don’t store all nodes behind a strong database firewall, you risk the security of your sensitive information.
• Keep your server operating system up-to-date. Unless you install the latest encryption patches, no data security can be guaranteed. As the WannaCry and Spectre/Meltdown issues have shown, there’s no substitute for responsible patch management.
• Always delete “default” and sample databases. The security industry may not like the word “default”, but it’s not something to be brushed under the carpet. As those who have suffered cyber breaches will know, it can nearly always be replaced with the word insecure: default passwords are insecure passwords; default settings are insecure settings.
• Use strong and unique passwords. Thanks to the rise of Open Source, it’s relatively simple to find out about security settlings like default passwords. Businesses can therefore never be too careful in ensuring any new project or database is given a strong password that is not used for anything else.
• Report security holes straight away. Even if it seems minor, you can help the wider community by sharing it. Coercive silence helps no one but cyber criminals, so if you see something that doesn’t look right, report it without fail.

A problem shared

As bleak as it sounds, businesses must accept that hackers will always be a threat. With every new technology that emerges, hackers become more sophisticated, constantly creating new methods to exploit vulnerabilities and disrupt enterprises. Rather than viewing this as a threat, however, businesses must see this as an opportunity to invest in education and best practice.

Crucially, businesses should also begin to share the responsibility of compliance and security. From web, mobile and app developers through to C-suite and technology executives, everyone involved in databases has responsibility for ensuring they are secure. There’s also an onus on the NoSQL vendors to honour the trust that organisations place in them. Providing the NoSQL database isn’t just a case of implementing a product – they also have the responsibility of ensuring users are able to protect their data. To do this, vendors need to make sure their services are secure by default and avoid necessitating extra steps that do nothing but confuse the user.

Whilst it would be nice to believe NoSQL data breaches and leaks are a thing of the past, that’s unlikely to be the case. Going forward, however, the leaks that have occurred – and are yet to occur – can serve as a reminder for businesses to take database security seriously.