Why NoSQL Equals NoSecurity
informationweek.com
informationweek.com
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.
I don't know what you're trying to say with regards to SSL, or how it can be reasonably compared to runtime hardening.
I didn't mean to imply TTL incrementation was magic remote root.
As far as SSL, you're right in that it is a bit tangential. I'm just trying to illustrate the huge security flaws that, in my eyes, stand in front of "can someone sniff my traffic".
(One of my business partners is the author of firewalk).
What I mean to say is that your authority is better than mine on this - so if you think SSL is secure, then I'll start telling people SSL is secure. I just think the numerous vulnerabilities unearthed so far, ranging from the eminently practical (Compromise a CA!) to the blindingly obvious (SSLStrip) constitute a poor record.
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)
In what way is my SQL DB (which I use with prepared statements and placeholders) more vulnerable than any NoSQL thing?
> 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
So the major commercial firewalls aren't written in C or C++? I find that mildly surprising, since I know only of netfilter and pf, and both are written in C
While the editors may have sensationalized the title, the key here is that the majority of the users of NoSQL databases are not security researchers or even developers that understand proper defense in depth. Most are using these "database technologies" to solve a specific problem or because they are "cool" so when they go from dev to production, very few controls are implemented anywhere in the stack (network, OS, or app).
Furthermore, if the solution to securing a NoSQL DB is to "secure everything around it" (e.g, the references in the posts to hardening the OS, Network, segmenation, etc) then I can tell you it isn't happening and the deployers of NoSQL don't know that.
The financial institutions that are using NoSQL, that I have assessed, aren't using commercial versions mostly because a developer throws something together, proves it works, and moves it into production rather quickly. I think they will move to commercial versions though as more support is needed.
I don't have an axe to grind, and if you look at my previous database security reports I don't think the big SQL DBs are great either BUT they do provide more options for controls to be put in place at the database level. Of course the rest of the stack should be secured too(duh) but when it comes to defense in depth you want to have as granular controls as possible as close to the data as possible.
I did not make the claim you shouldn't use these technologies, rather I make the claim you can't assume these technologies support the same controls as other relational databases have and call it a day. You have to be much more creative to properly control and audit access.
Lastly, it is difficult to provide actionable technical advice in a article format such as that used by InformationWeek because of the wide variety of readers. Rather, we make recommendations that readers can use to do additional research and find the proper answers which is what we did provide in the actual research report (which is longer and more detailed than the articles).
Oh, and I think Tom had the right idea. Can you explain your firewall and SSL comments? Also, xp_cmdshell as been disabled by default since SQL 2005, so that isn't valid example of "in-secure by default" for a new deployment (even though an attacker can re-enable it if they are 'sa'). If you are deploying SQL 2000 into an environment in 2012 you have other issues)
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.
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.
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.
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.
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.
IMO the main benefit of having an ACL is to compartmentalizes your database so that a SQL injection against one app (maybe) won't spill over to a different app. That's not something that makes me feel good at all.
I'm curious though -- what security features (if any) does HN think NoSQL DBs are missing?
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 ;) ).
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.
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.
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.
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.
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?
AFAIK OrientDB is the only NoSQL supports security: http://code.google.com/p/orient/wiki/Security.