In a previous article, I discussed the “Cambrian Explosion” of new data management solutions that are evolving and competing for market and mind share, and the implications this explosion poses for a data security space that has grown up around relational databases.

Combining NoSQL and Security Endeavors

To quickly recap, everyone has heard of Hadoop-based systems, but there are also a wide variety of NoSQL (“Not Only SQL” or “No SQL”) systems that can operate in a Hadoop environment or are serving new applications completely outside the scope of Hadoop. In the 18 months or so since I wrote my initial article, we’ve had dozens of enterprise clients asking us about how they can audit and protect these systems, such as MongoDB and Cassandra, which indicates to me that use of NoSQL systems is moving beyond the experimental phase and into full-blown production in a number of innovative organizations.

Security teams should be involved early on when a decision is made to bring in a new database system. This ensures that the system has appropriate security and authorization controls in place or, if not, that appropriate compensating controls are present to protect sensitive data from attack. The audit team may also require that the system provides adequate auditing facilities and compliance reporting. Ideally, it would integrate easily with the existing audit and compliance infrastructure.

Think about the phases of data security and what you’ll have to consider at each stage:

1. Discover

How will you know when new databases are on the network? How will you know if there is sensitive data, whether it’s your organization’s “crown jewels” or personal data that requires special protection for compliance? Unlike relational database systems that may spread sensitive data among several tables — for example, ZIP code in one table and date of birth in another — a NoSQL system is more likely to store complete documents, which makes it much easier for cybercriminals to get what they need in one fell swoop.

2. Harden

How do you know if security best practices are being followed? Are the database administrators keeping the system patched? Recently, German researches found almost 40,000 MongoDB databases open to the world. This could have been prevented with a simple configuration change. An automated approach to vulnerability scanning and patch management for systems such as MongoDB could easily have detected this misconfiguration.

3. Monitor

Are you able to monitor privileged user activity? Is there any suspicious activity that could indicate attackers are infiltrating the system, and will your team be alerted on it right away? Are you able to collect audit data with minimal impact on the performance of the system while also auditing and keeping the data separate from the hands of savvy privileged users? Will you be able to detect NoSQL injection attacks or, even better, detect risky functions in the application?

4. Protect

How granular are the access controls that are in place? Is sensitive data at rest encrypted? Are there ways to prevent leakage of sensitive data? Is there a way to mask data? Can a cybercriminal or rogue administrative user actually be prevented from reading data if they bypass normal audit controls?

I’ll be presenting on some of these topics with regards to MongoDB specifically at the NoSQL Now! conference in San Jose, California. Anyone who wants to dive deeper into NoSQL should check out this article series on IBM developerWorks, where you can see how technologies can help identify injection risks, provide granular monitoring and protect against data leakage.

Download the ebook to learn more: NoSQL does not have to mean no security