
Why NoSQL Equals NoSecurity - jordhy
http://www.informationweek.com/news/storage/portable/232700412
======
ZephyrP
I'm the author of a (very) new NoSQL datastore called Artifact
(<http://zv.github.com/artifact/>), that, admittedly, is very prototypical and
is not representative of MongoDB, Couch, Riak or any of the other major
players. I'm also a vulnerability researcher who makes his way in the world
finding and dissecting security bugs and holes in network infrastructure.

I feel this article misrepresents a lot of facts about security in the same
way that articles discussing the relative security of passwords misrepresent
security.

Here's what I mean

Question: Whats the most obvious way to attack a system? Answer: Guess
Passwords.

Because this is the most obvious way to attack computer systems, an undue
amount of attention is paid to the topic because it's the only way we're aware
of. In reality the vast majority of systems compromised happen because of
memory corruption vulnerabilities, or in recent years, (predominantly) web
bugs like SQLi and LFI. Explaining the dynamics of taking control of a program
through smashing the stack and getting EIP is tough, at least in contrast to
explaining how guessing passwords works. So people worry that "their passwords
aren't secure" despite that any real black hat deleted D8.dic off their
harddrive years ago. Thus, theres a million articles and sites on how secure
your password is, but not that many to check if you've got address
randomization enabled.

Are Blackhats trying to read your NoSQL stores after staging an internal
attack? Possibly, but not nearly as likely as the fact that you've got
xp_cmdshell enabled. Attacking MongoDB is tractable, and provides numerous
opportunities for a wide nop sled w/ memory mapped files and more than enough
opportunity for use-after-free attacks in objects, but the same (and then
some!) can be said of any modern SQL database.

The fact that query strings are safe in every major NoSQL datastore is such a
massive advantage over SQL DBs that, even if you're using prepared statements,
NoSQL is almost assuredly more secure in a day to day context, except against
zero-days (Which we can reasonably say are less frequent in established
datastores, irrespective of their design decisions).

The fact that he quasi-attacks stateful firewall security in the article is
pretty much baseless, clever TCP bugs are long since worn out, and all the
things that mainstream developers have thought is clever like firewalk(8)
haven't been effective since I was 11. It's not unreasonable to trust major
commercial firewalls for anything you'd trust SSH for. It's not reasonable to
trust C/C++ applications in general, as even the most valorous efforts at
secure software have turned up short (The beautiful irony here may be that
SSH, as trusted as it is, has had numerous pre-auth exploits in it, as it is
written in C++)

Finally, let's be real, as an article aside -- SSL does absolutely nothing.
Every single year there are multiple complete breaks in what SSL is supposed
to do, both practical and theoretical. These complete breaks are regularly
released with executables, so don't give me that "We're only raising the ba-"
Nope, ASLR and W^X raise the bar, you could argue SSL widens your attack
surface on anything but HTTP transactions. Furthermore, if MITM is the biggest
thing you're worried about then I'd encourage you to download any of the
latest XML parsing libraries or PDF readers to rectify that -- it's tragically
only minor exaggeration to say attacking these complex, loosely interacting
components such as parsers to stage a more complex internal attack _is_
organizational computer hacking in 2012.

~~~
jmillikin
Serious question -- was your post generated by a Markov chain? While the
sentences and paragraphs are basically grammatical, they make no sense at all.

~~~
viraptor
I found the post very clear and interesting. Maybe it was written like a rant
that you'd normally say out loud rather than write down, but it was good
nevertheless. What did you find confusing?

~~~
tptacek
What's your takeaway from it?

~~~
viraptor
Multi-layer security is an interesting issue where each service can be
exploited in a couple of ways. There are app-logic layer problems like not
escaping input as well as app-internals layer where app's language matters to
some extent. Java does have reasonable protection from buffer overflows...
unless it's a bug in jre where all apps suffer. On the other hand we only have
some unfortunate exceptions like unusable but safe qmail.

So while it's not the end of your worries of course, from the developer's
point of view if you can make sure you're running on a system handling ASLR
properly, using a language with managed-memory, designing a system to not
require escaping in the first place, so there's nothing to forget about... you
can eliminate several classes of attacks without even starting to think about
specific scenarios and business logic itself. (not all follows from the post
itself, but this was on my mind after reading - so matches your question
hopefully)

------
NyxWulf
We use hadoop, cassandra, and redis in production. I've never found
Information Week to be a high quality source of information, and unfortunately
this is no exception. Data systems almost always rely on being in segmented
and protected portions of a network with access being controlled by
applications and firewalls.

Overall this article struck me as having an axe to grind. I wouldn't put, SQL
Server, Oracle, MySQL or any other database on the web with open access. Just
like we don't do that with any of our NoSQL solutions. Generally, I've found
that security granularity is not as robust in the newer Big Data tools, but
that was the same argument against MySQL and Postgres a decade ago.

* Edit: Since we are playing on names, apparently Information Week = Information Weak.

------
jedberg
This article makes it sound like relational databases are the pinacle of
security. Sure, they have usernames and passwords and other controls, but the
data is still usually stored unencrypted.

I don't think putting a few username/password credentials onto the datastore
will make it much more secure, especially if I can put those same access
controls into a database access layer.

In the end you need to defense in depth just like always, and that includes
putting access controls, network controls, OS controls and everything else.

~~~
ks
I haven't tried it myself, but Redis has support for simple authentication at
least. <http://redis.io/topics/security>

~~~
ZephyrP
Just in case you want to open up your Redis instance to the internet?

Sometimes I think people like antirez add these features just so an article
isn't published proclaiming Redis security to be broken because of no password
authentication.

------
thezilch
WTF? If you can't trust your network, OS, and user level access, how are you
going to trust a DB ACL? I'll put everything up against Information Week using
a caching layer (Re: memcached), which has unfettered access without security
from an external layer. Non-NoSQL don't magically make security a non-issue;
what a joke; in all cases, equally, one has to be aware and diligent about
securing your network.

~~~
nupark2
_> WTF? If you can't trust your network, OS, and user level access ..._

You can't trust them all equally, and allow for a failure in any one of them
to result in a total failure of all security. That's the M&M security model --
crunchy on the outside.

This is one (of several reasons) I wouldn't use memcached without
authentication if it could lead to a privilege increase: It completely breaks
defense-in-depth. Compromise of just one system can lead to total system
compromise.

~~~
thezilch
The article's author/etc simply has an axe to grind with NoSQL. Are we going
to throw out our *nix flavors that have us disable root SSH? Our FSes that
don't have or disable-by-default block encryption? Security should definitely
be championed, full stop, but I'm not convinced by this article that NoSQL or
relational DBs have any reason to be implementing the secure layers on my
systems.

A big draw to NoSQL is not only the ease of use. One advantage is the
separation of working parts. Not jack of all trades, master of none
architectures.

------
haldean
The article doesn't make it clear what sort of security features the author
would like to see in NoSQL databases beyond SSL support, which they then admit
is offered by MongoDB's "commercial offering". Never mind that the commercial
version is, I'm assuming, the one that is used by all of the financial
institutions the author is worried about.

I'm curious though -- what security features (if any) does HN think NoSQL DBs
are missing?

~~~
hughw
Exactly -- for his example of a financial services system, just buy the
commercial version, or tunnel using ssh.

You can also encrypt the underlying file system using your OS's tools.

I can't speak to how financial institutions use, say, Oracle's authentication
and authorization. Most web apps & services use their own logic to manage
access control. I'd love to hear what someone form that industry has to say.
(An "architect" preferably. Not a mere "developer", who are the cause of this
whole security problem ;) ).

------
datasage
RDBMS's, put a large focus on data integrity and access within the datastore
layer itself (To differing degrees); NoSQL systems more or less offload that
responsibility into the application layer. There is still a responsibility of
running it within a trusted network.

This is a decision that may not be appropriate for everyone, but that does not
make it wrong. Many people who used mySQL to power web applications did use
just one credential to access the database. In that scenario the
authentication overhead is pretty much just a waste of time.

------
methodin
I would tend to think financial/banking/<insert would-be secure application
here> would be insecure no matter what data store they use. It seems to just
be part of the game - ask anyone that's developed for one.

One would assume that by adopting NoSQL that would mean a refresh of
code/architecture/security but only a small part of me actually believes that.

I also do not really understand the point of this article ad it did not
provide me with anything useful.

~~~
NyxWulf
I'll play. I worked at a financial institution for several years. On the one
hand you'd think we were secure because we used a relational database, but we
also had a heavily segmented network with all of the databases in their own
VLAN's with highly restrictive permissions. On top of that each application
was locked down to exactly which data it could use and what could be done with
that data.

So if you buy the premise of the article, it wasn't NoSQL, so it must have
been secure. In reality we were very secure from external breaches, at least
as secure as you can reasonably be.

Personal information was secured to the maximum extent possible. Encrypted,
backed up to multiple independent tapes stored in separate locations etc. On
the other hand, the overall complexity of the system was very high and if
someone breached our network there would have been a very large surface area
to attack. I didn't feel like the article addressed this aspect of security in
the least. Security just isn't one of those things that are easy or are ever
done. It takes constant vigilance and continuous adjustment and improvement.

~~~
methodin
Did your institution go the seldom traveled route of encrypting sensitive
information? Typically all the effort is spent trying to avoid breaches
instead of protecting against them when they occur.

~~~
NyxWulf
Initially it was not encrypted and was stored in plain text in the database.
Then we started encrypting sensitive information at rest, both the database
files and the backups. We also encrypted certain sensitive information with a
secondary encryption. The next massive undertaking was to find all of the
processes that use the data, how they use it - both internally and externally,
and then ensure the data was protected throughout the entire process. The
company was still working through that process when I left. They had
identified many places that were problematic and were actively working on
fixing them. The team I managed was the payment processing and cash management
team. There were a number of legacy systems written in access, fox pro, DTS,
Excel even. Many of those were the most painful, and frankly the most
problematic.

Many people were put in a situation where the requirements for getting
something implemented through the IT teams would take months, yet they were
still held accountable for getting things done, so they would build an Excel
process to get the job done. They would build some fantastic process, and get
promoted, then that Excel system would get dumped on either someone in IT or
someone replacing them.

I'm getting off track, but looking at it superficially the data was encrypted.
If, however, you watch the data through it's entire value stream, there are
many places it is vulnerable. Given the state of affairs in most companies and
how few of them think in terms of managing value streams, I expect my
observations are fairly widely applicable.

------
count
How much information from highly secured RDBMSs is leaked and lost on a daily
basis? How much of that leakage is prevented by the database's security
mechanism, vs. that of the application connecting to it?

And to pick on certain things - does SSL connections REALLY matter? If you're
running over an untrusted network (bad idea, in general), why not just use
IPSEC?

------
protomyth
Sybase and Oracle do have pretty good security solution when you dive deep
into them, but I gotta question the whole premise of the article. I have
always believed if a outsider can get to your database / datastore then you
already have a ton of problems.

------
luca_garulli
Seems like NoSQL target was to solve small part of your Big-Data problem. This
is changing because NoSQL can replace RDBMS in many fields and Security is
becoming a MUST to have too.

AFAIK OrientDB is the only NoSQL supports security:
<http://code.google.com/p/orient/wiki/Security>.

