Application Security // Database Security
2/6/2012
09:33 AM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

A Response To NoSQL Security Concerns

Three key takeaways from a recent webcast about database security in the NoSQL database movement

In response to Ericka Chickowski's article "Does NoSQL Mean No Security?" I was asked to attend a webcast with executives from CouchBase and 10Gen -- makers of MongoDB. The goal was to discuss database security in the NoSQL database movement and address some of the accusations made in Ericka's post. I encourage you to listen; it's illuminating for developers and security professionals alike.

From a security perspective -- this is a database security blog, after-all -- you may think I'm casting stones at the security "nonbelievers." Not so. The goal is to share the perspective so you understand what NoSQL security facilities are available to you and why that's the case.

Here are what I consider to be the key takeaways from this recent webcast:

1. Security By Design: All of the NoSQL providers I have spoken with, including Couch and Mongo DB, do have some security within their development life cycle. Usually there are design choices to address specific threats and some tests provided in the quality-assurance phase of the application development life cycle. But statements by the webcast participants make it clear that these precautions are minimal. They compose a tiny fraction of the overall development resources. And that's the way it should be. Each flavor of NoSQL is designed to meet a specific challenge, be it handling very large datasets, redundancy, map-reduce analytics and metrics gathering, or focusing on specific types of content. Security is not the goal -- never was, it's not today, and won't be for some time. If you don't like it, then use something else. Or you can augment your application to provide the missing security layer. You also can alter what you store in the database, but don't bet on your big data repository being secure.

2. Security Model: It's clear, both through the interviews I've had and design documents I've read, that the NoSQL security model is for the databases to be buried deep within an IT organization and behind other systems. Everything I have heard clearly states that the security model intends for the database to reside in a secure environment, protected by a firewall and access controls fronting any application. This is the old-school view of network security where you keep outsiders out of your network and everything will be fine. The irony is that just about every application platform designed specifically for use with NoSQL databases is a Web-centric (Node.js, Java, Ruby on Rails, PHP) application. Having an open front end universally accessible from any Web browser makes development easier, but the open user-interface vision is at odds with a behind-closed-door security model.

3. Dumb Data Bucket: NoSQL is a giant data bucket. While relational database systems are designed to maintain tight controls of data, NoSQL provides loose controls over datasets. Relational systems use metadata to precisely control data type,and heavily synchronized process controls to maintain data integrity. NoSQL uses loosely synchronized processes to scatter data across many systems, with small regard for the status of any one server or quality of data being stored. That's not a negative judgment against NoSQL; rather, I am stressing the philosophical differences in approach needed to meet the core design goals. It's a giant self-organizing bucket you put data in. Once again, don't expect it to be secure. If you want security, then build it into your application. Or only store secured (encrypted, anonymized, tokenized) data. But don't expect the bucket to do much more than efficiently store your data.

Open-source NoSQL databases are a greenfield opportunity for security vendors; monitoring, assessment, access control packages, labeling, and masking are all needed technologies.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2008-3277
Published: 2014-04-15
Untrusted search path vulnerability in a certain Red Hat build script for the ibmssh executable in ibutils packages before ibutils-1.5.7-2.el6 in Red Hat Enterprise Linux (RHEL) 6 and ibutils-1.2-11.2.el5 in Red Hat Enterprise Linux (RHEL) 5 allows local users to gain privileges via a Trojan Horse p...

CVE-2010-2236
Published: 2014-04-15
The monitoring probe display in spacewalk-java before 2.1.148-1 and Red Hat Network (RHN) Satellite 4.0.0 through 4.2.0 and 5.1.0 through 5.3.0, and Proxy 5.3.0, allows remote authenticated users with permissions to administer monitoring probes to execute arbitrary code via unspecified vectors, rela...

CVE-2011-3628
Published: 2014-04-15
Untrusted search path vulnerability in pam_motd (aka the MOTD module) in libpam-modules before 1.1.3-2ubuntu2.1 on Ubuntu 11.10, before 1.1.2-2ubuntu8.4 on Ubuntu 11.04, before 1.1.1-4ubuntu2.4 on Ubuntu 10.10, before 1.1.1-2ubuntu5.4 on Ubuntu 10.04 LTS, and before 0.99.7.1-5ubuntu6.5 on Ubuntu 8.0...

CVE-2012-0214
Published: 2014-04-15
The pkgAcqMetaClearSig::Failed method in apt-pkg/acquire-item.cc in Advanced Package Tool (APT) 0.8.11 through 0.8.15.10 and 0.8.16 before 0.8.16~exp13, when updating from repositories that use InRelease files, allows man-in-the-middle attackers to install arbitrary packages by preventing a user fro...

CVE-2013-4768
Published: 2014-04-15
The web services APIs in Eucalyptus 2.0 through 3.4.1 allow remote attackers to cause a denial of service via vectors related to the "network connection clean up code" and (1) Cloud Controller (CLC), (2) Walrus, (3) Storage Controller (SC), and (4) VMware Broker (VB).

Best of the Web