Does NoSQL Mean No Security?

The burgeoning use of NoSQL databases within the enterprise has given users better scalability and flexibility with how they store data and how applications tap into those stores, but security experts warn that there are some serious security considerations to take into account when diving headfirst into a deployment of such an immature technology.

"We think the lack of security around NoSQL is going to take a toll on organizations," says Amichai Shulman, co-founder and CTO of Imperva. "We'll see a lot more organizations starting or going into deployment of NoSQL in the next year and we believe what they are going to find out after they put the data there is that there are some security issues they should have considered."

An alternative to the traditional relational database, NoSQL systems do not use the SQL language for queries and are schema-less systems that allows users to change data attributes on the fly. These databases are known to scale well and offer performance advantages in transactional situations where a large amount of application users need to interact with the database in real-time, says James Phillips, co-founder and senior vice president of products for Couchbase, a NoSQL platform firm.

"NoSQL is about transactionality. It's about real-time and it's about doing something with the data right now, in particular facilitating interactive software systems," Phillips says. "One of the big benefits is that you can change your mind (about attributes) at any time. They tend to be schemaless."

But this biggest benefit of NoSQL is also one of the biggest cause of concerns for security experts.

"One of the things about NoSQL is that the data model is pretty much dynamic," Shulman says. "I can add attributes to records as we go along. So the security model for this kind of architecture must have some notion of forward-looking security. So, understanding what happens with the new attributes that I introduce to the database and what the privileges that are granted into the new attributes that are added to the database. This is a concept that is non-existent and, quite frankly, no one has given thought to it so far."

According to Phillips, some NoSQL platform developers have started to work on adding some semblance of control around at least controlling the integrity of data.

"In the relational database world if you don't form your data correctly and it doesn't adhere to the schema you will be unsuccessful at inserting that data. There are all sorts of validation rules and sanity checks," he says. "But it turns out you can do that with a NoSQL database as well. Our solution and others is to allow you trigger on the insertion of a new record or document rules that have been executed to ensure you are not inserting data that is malformed."

However, even if these types of optional functions offered a full array of security capabilities, one of the big issues is that there would be very few users out there that would know how to implement them.

"Because practically everyone is new to NoSQL, the first thing they care about is to make it work," Shulman says. "And then don't touch it and we'll talk about security in two years or so."

Shulman says he expects new users to make big configuration mistakes right out of the gate, not because IT staffers are incompetent, but because it is new technology with little knowledge base around it. Alex Rothacker, manager of Application Security Inc.'s research division, TeamSHATTER, tends to agree. He says that one of the big issues with training is the fact that a lot of users who are attracted to NoSQL also tend to be young startups with technical staff who have little to no security experience in the first place.

"So if they were to at least use a relational database there's at least a certain amount of enforced security," he says. "On the NoSQL systems, you have to really look at the workarounds and do a lot of research to figure out how to get these things secure. So probably 90 percent of people don't have the knowledge or the experience or the time to do it."

While Phillips agrees that there is still an experience gap with such a new technology, he believes that some of the security concerns should be at least a little quelled if organizations consider the typical use case for NoSQL. He believes that these data stores usually contain less sensitive information than the typical relational database and that they tend to have limited touch points to other applications within the enterprise network.

"They're using the technology not as a database per se, like you would consider perhaps an enterprise data store where you're collecting and aggregating lots of the business data of the organization that other apps are going to tie into," he says. "Rather, if I'm building a social network or social game or building a very specific web application that has certain functionality, it tends to sit behind the firewall and it ties to this application and usually isn't available for other parts of organization to tap."

But Rothacker says that that kind of dependence on perimeter security for a database system is scary.

"These systems rely on the whole perimeter security model," he says. " There is very weak authentication and none of them have a concept of how to secure multiple users and their access to the data. Pretty much if you have any account you have access to the whole data store. Brian Sullivan, for example, at Black Hat last year showed that even if you don't know what data's there, you can figure out how to enumerate it and pull all the data out."

And according to Tim 'TK' Keanini, CTO for nCircle, even if a NoSQL database is limited to one application use that application is exposed on the Internet. Without careful network segmentation, it could be a point of entry to more tasty data stores held elsewhere.

"Because NoSQL is designed to be deployed at Internet scale, it's also more likely to be directly attached to the Internet and thus likely to be subjected to a far greater number of Internet scale attacks," he says

One of the most possible attacks are the type of injection attacks that run rampant in the relational database world. Even though NoSQL doesn't use SQL as a query language doesn't mean it isn't subject to injection attacks, they warn.

"People say you can't do SQL injection but the principles are exactly the same, you just have to change the syntax of what you put in the form," Rothacker says. "Instead of SQL injection you have JavaScript injection or JSON injection."

And hackers are likely sharpening their claws in anticipation of attacking these databases. The unfortunate reality about securing immature technology is that it doesn't take nearly as much ramp up time to learn how to break a system as it does to learn how to secure it.

" So I think that hackers are going to be much faster into this than those in charge of deployments ," Shulman says. "Unfortunately it is easier to break things than to create them in a robust way and we've already seen some vulnerabilities published about NoSQL technology, in particular one attack vector that is being discussed is JSON injections."

However, that shouldn't stop businesses from using NoSQL, he says.

"I think that the decision is ultimately a business decision and if there is a business opportunity that can only be pursued using these new technologies then the business must take the risk," Shulman says. "But there are steps that can be taken to try and mitigate that risk."

For example, Rothacker suggests that because of the dependence on the perimeter to secure these databases, organizations strongly consider encryption whenever possible. And both he and Shulman warn organizations to very carefully code the applications tapping into NoSQL databases.

"Which means that organizations need to be very careful about the people they choose to deploy these projects and really invest your best people in this," Shulman says. "Make sure that when you write your applications on top of NoSQL, you use veteran programmers because a lot of the security is going to go into the client software. Really take some extra buffer in terms of times to deploy , allow your staff extra time to review what they're doing and allow them extra time to consider security at least a little bit." This, in the end, may be no different than developing for the relational database.

" Ironically, the advances in database application security in recent years have very little to do with databases themselves," says Oliver Lavery, director of security research and development for nCircle. "Programming languages and frameworks like ASP.NET, Django, Ruby on Rails, etc. have evolved better language support for building database queries that prevent mixing query code with data and this provides the only strong safeguard against injection attacks."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.