31–35 of 35 posts
Earlier quoted context omitted.
Serious question -- was your post generated by a Markov chain? While the sentences and paragraphs are basically grammatical, they make no sense at all.
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?
Earlier quoted context omitted.
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 premi…
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.
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.
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 s…
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)
Earlier quoted context omitted.
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?
What's your takeaway from it?
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)
AFAIK OrientDB is the only NoSQL supports security: http://code.google.com/p/orient/wiki/Security.