But the eWeek article demonstrates that the same concerns [nb: about security] exist where Hadoop implementations are concerned. The article says: “It [Hadoop] was not written to support hardened security, compliance, encryption, policy enablement and risk management.”

The story goes like this: in the early days of NoSQL, when no NoSQL database had any sort of security features, people behind the projects answered: “it’s too early. we’re focusing on more important features. and you can still get around security by placing your database behind firewalls”. Today, when more and more NoSQL databases are adding security features, the story these same people are telling is quite different: “ohhh, security is critical. we don’t really see how you could run a database without these features”.

Security is always critical. And exactly the same can be said about maintaining a solid, coherent story of what you are telling your users.

Original title and link: Hadoop, Security, and DataStax Enterprise (NoSQL database©myNoSQL)

via: http://www.datastax.com/2013/04/hadoop-security-and-the-enterprise

1. Start Early! Determine the data privacy protection strategy during the planning phase of a deployment, preferably before moving any data into Hadoop. This will prevent the possibility of damaging compliance exposure for the company and avoid unpredictability in the roll out schedule.

2. Identify what data elements are defined as sensitive within your organization. Consider company privacy policies, pertinent industry regulations and governmental regulations.

3. Discover whether sensitive data is embedded in the environment, assembled or will be assembled in Hadoop.

4. Determine the compliance exposure risk based on the information collected.

5. Determine whether business analytic needs require access to real data or if desensitized data can be used. Then, choose the right remediation technique (masking or encryption). If in doubt, remember that masking provides the most secure remediation while encryption provides the most flexibility, should future needs evolve.

6. Ensure the data protection solutions under consideration support both masking and encryption remediation techniques, especially if the goal is to keep both masked and unmasked versions of sensitive data in separate Hadoop directories.

7. Ensure the data protection technology used implements consistent masking across all data files (Joe becomes Dave in all files) to preserve the accuracy of data analysis across every data aggregation dimensions.

8. Determine whether a tailored protection for specific data sets is required and consider dividing Hadoop directories into smaller groups where security can be managed as a unit. ?

9. Ensure the selected encryption solution interoperates with the company’s access control technology and that both allow users with different credentials to have the appropriate, selective access to data in the Hadoop cluster.

10. Ensure that when encryption is required, the proper technology (Java, Pig, etc.) is deployed to allow for seamless decryption and ensure expedited access to data.

Wait… where’s point 11, buy Dataguise?

Original title and link: Dataguise Presents 10 Best Practices for Securing Sensitive Data in Hadoop (NoSQL database©myNoSQL)

via: http://www.businesspress24.com/pressrelease1213023.html

Dataguise says the latest version of its data-protection product enables users to encrypt sensitive data right down to specific fields within an open source Apache Hadoop database.

DG for Hadoop 4.3 also makes use of the traditional Dataguise “masking” capability across single or multiple Hadoop clusters to camouflage sensitive data.

$25.000 a piece (hopefully not a piece of encrypted data though).

✚ Apache Accumulo is known to offer a BigTable inspired open source implementation with cell-based access control.

Original title and link: Field-Level Encryption for Apache Hadoop From Dataguise (NoSQL database©myNoSQL)

via: http://news.techworld.com/security/3437999/dataguise-introduces-field-level-encryption-for-apache-hadoop-database/

This means carying about your users’ data:

What we intend to do is shut off updates from the master git repo to the anonymous-git mirror, and to github, from Monday afternoon until Thursday morning. Commit-log emails to pgsql-committers will also be held for this period. This will prevent the commits that fix and document the bug from becoming visible to anyone except Postgres committers. Updates will resume as soon as the release announcement is made.

Original title and link: Extra Security Measures for Database Projects (NoSQL database©myNoSQL)

via: http://www.postgresql.org/message-id/14040.1364490185@sss.pgh.pa.us

Robin Schumacher describes the new security features added to Apache Cassandra and DataStax Enterprise:

This article will concentrate on the new internal authentication and authorization (or permission management) features that are part of both open source Cassandra as well as DataStax Enterprise. Authentication deals with validating incoming user connections to a database cluster, whereas authorization concerns itself with what a logged in user can do inside a database.

I’m happy to see NoSQL databases entering the space of security as this would ease their way inside enterprises. But I fear a bit the moment when the marketing message will change from “it’s too early to provide security features” to “the first enterprise grade NoSQL database”.

Original title and link: A Quick Tour of Internal Authentication and Authorization Security in DataStax Enterprise and Apache Cassandra (NoSQL database©myNoSQL)

via: http://www.planetcassandra.org/blog/post/a-quick-tour-of-internal-authentication-and-authorization-security-in-datastax-enterprise-and-apache-cassandra

In short, if you try to authenticate to a MySQL server affected by this flaw, there is a chance it will accept your password even if the wrong one was supplied. The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password.

  $ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done

Don’t try this at home. Or if you try it, don’t tell anyone the result.

Original title and link: A Tragically Comedic Security Flaw in MySQL (NoSQL database©myNoSQL)

via: https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql

The Gazzang Encryption Platform for Big Data works as a last line of defense for protecting data within Hadoop, Cassandra and MongoDB, non-relational, distributed and horizontally scalable data stores that have become common management tools for big data initiatives.

Sounds good so far. But then:

Gazzang today launched a cloud-based encryption […] The Encryption Platform transparently encrypts and secures data “on the fly,” whether in the cloud or on premises, ensuring there is minimal performance lag in the encryption or decryption process.

Anyone having any idea how a cloud-based solution could encrypt/decrypt on premises data on the fly? I don’t.

Original title and link: Data Encryption for Hadoop and NoSQL Databases From Gazzang (NoSQL database©myNoSQL)

via: http://blog.gazzang.com/company-0/news--amp-press/Gazzang-Launches-Big-Data-Encryption-and-Key-Management-Platform/

Many useful pieces of advice—from the very basics to renaming commands—in Marc Wickenden post about securing Redis:

Redis doesn’t have much in the way of security so I knew that anyone who managed to pop the box could theoretically connect to the local Redis instance and mess around. I’ll take you through the steps I took to install and harden Redis, on a Debian Squeeze GNU/Linux box.

Archived.

Original title and link: NoSQL Security: Installing and Hardening Redis (NoSQL database©myNoSQL)

via: http://blog.7elements.co.uk/2012/03/installing-and-hardening-redis.html

Herman Stevens summarizes the findings of the paper “Security Issues in NoSQL Databases”:

The paper itself concluded that the main problems to both Cassandra and MongoDB are “the lack of encryption support for the data files, weak authentication both between the client and the servers and between server members, very simple authorization without support for RBAC or fine-grained authorization, and vulnerability to SQL Injection and Denial of Service attacks”

Cassandra security reviewed

MongoDB security reviewed

Even without the findings of Attacking NoSQL and Node.js: Server-Side JavaScript Injection (SSJS) things might be scary.

Original title and link: NoSQL Databases and Security: Cassandra and MongoDB Security Reviewed (NoSQL database©myNoSQL)

via: http://blog.astyran.sg/2011/11/there-is-no-security-in-nosql.html