Cyber security is nothing new. For nearly two decades people have talked about and spent billions of dollars on solutions that protect information on the Internet. The problem is those same security evangelists, the people who are supposed to protect consumers, have focused far too much on credit card data.

Last week we had another sobering reminder about the sensitive nature of data stored in the cloud. This extends far beyond the 16 digits on your credit card to include things like addresses, birth dates, social security numbers, physicians’ names, national provider identifiers, tax identification numbers, and procedure codes designed for billing purposes. These were just some of the bits and bytes of information that were compromised when hackers broke into the Utah Department of Health servers.

In total, more than 500,000 records and 280,000 social security numbers were stolen. The agency is cooperating with law enforcement in a criminal investigation, but that’s little assurance to the hundreds of thousands of Medicaid and CHIP clients who were affected.

The Utah Department of Technology Services servers have multi-layered security systems with many controls, including: perimeter security, network security, identity management, application security and data security. But they were missing the one step – transparent data encryption - that might have prevented this ordeal. Sure this wouldn't have prevented hackers from circumventing the security system via a configuration error, however if the data had been encrypted, it would've been meaningless to those who stole it.

Gazzang enables organizations to transparently encrypt sensitive, proprietary data in any cloud environment on any NoSQL platform (including Hadoop, Cassandra and MongoDB). For more information, visit www.securingbigdata.com.

It’s been quite an eventful week for big data and cybersecurity. The White House announced its plans to spend $200 million on big data R&D. Meanwhile, credit card processor, Global Payments Inc., acknowledged a massive security breach may have impacted at least 50,000 customers.

We’ll continue to follow both of these stories and will most certainly comment on them in upcoming blogs and announcements. Today though, we’re going to keep the Friday Top Five pretty light and focus on one of my favorite marketing items… the almighty Infographic.

Now, I willfully acknowledge that there’s a subset of the public that despises infographics. I presume these are folks who would rather read a lengthy white paper (Good news! We have those too) or Dostoyevsky novel. Personally, I can’t get enough of infographics.

If done well, they tell a compelling story using very little text. And any story that can be told in pictures vs. plain text is the best kind of story.

Here are a few security-related infographics caught my eye this week. See what you think:

1. What’s the origin of hacktivism, and how did we get to a point where hacktivists made up the majority of cybercrime in 2011? Check out A History of Hacktivism.


2. Data encryption continues to be a top concern among U.S. companies storing data in the cloud. Check out How Secure Is the Cloud to see whether we’re trusting the cloud just a little bit more these days.


3. 2011 was a painful year for a number of companies. Here’s a list of some of the worst hacking scandals from the past year.


4. How many Libraries of Congress does it take to screw in a lightbulb? I have no idea, but it takes about 18 million of them to house all the data we’ll create in 2015. More fun stats available at Big Data: Defining the Digital Deluge.


5. And finally, here’s an Infographic that unfortunately has absolutely nothing to do with my day job. Did you know the annual revenue from Girl Scout cookies is only about $40 million less than the total revenue from all NCAA sports combined? More delicious info about Thin Mints can be found here.

This past week, the Jumpstart Our Business Startup, or JOBS Act, which was endorsed earlier by the Senate, cleared the US House of Representatives by a (380-41) vote. The bill helps entrepreneurs looking for capital, and is a positive move that is pro-business, pro-jobs, pro-growth, pro-innovation, and pro-wealth creation. Kudos to Capitol Hill. BTW: why would any rational representative be “anti” all those things?

I have been closely watching the creation of the JOBS Act, and Gazzang even signed letters to our representatives to support the bills that undperinned this proposal.

The first is the Entrepreneur Access to Capital Act which makes it easier for businesses to raise capital through what has been called “crowdfunding.” This technique uses the Internet to solicit small investments from large numbers of people. The legislation allows businesses to use crowdfunding to sell unregistered securities as long as the total amount raised is $2 million or less. The bill also limits individual investments in crowdfunded securities to $10,000 or 10 percent of the investor’s annual income. So, it opens up the opportunity to invest in early innovation, while still protecting “Aunt Jenny” from losing her life savings if things don’t work out.

Second, the House voted 421-1 to reform the Securities and Exchange Commission’s Regulation A. This rule currently allows small companies to offer up to $5 million in stock to the public without registering it with the SEC. The Small Company Capital Formation Act raises that threshold to $50 million, which would allow more companies to raise capital without going through the lengthy and costly SEC registration process.

These are both good pieces of legislation that move government out of the way so companies and entrepreneurs can create jobs. We need to all retire the myth that the government can create private sector jobs. What it CAN do is create an environment that is productive and fosters the free movement of capital and ideas. That is how it works.

I spoke to the Austin American Statesman about this topic on Tuesday. Click here for the article: http://bit.ly/GVvnoS

I wanted to share another article on the topic of Securing Big Data. This one appeared in Database Trends and Applications (DBTA) following an interview we gave about our recently launched. Here’s a link to the article: http://bit.ly/HhANHS

Of course I’m a little biased when it comes to news about Gazzang. If you take us out of the equation, however, there are still some really compelling points for any company using data to advance its business goals (and what company isn’t?)

I’ve highlighted some of those points below with a little commentary:

“Right now, everyone is relying on just a simple layer of security like a firewall. What we found was that organizations want to really protect it by encrypting what's being stored and analyzed so that if there ever is a breach, the data is useless.”

I think this statement speaks for itself. Firewalls and intrusion protection are simply not enough anymore, especially with rise of ‘hacktivism’ where data, not money, is often the target. If your data is encrypted, it basically has no value outside the organization.

“Isolate the key from the actual data to ensure that the key is just as secure as the data.”

Key management is often one of the very first conversations we have with our customers. It’s probably the most difficult thing to do associated with encryption, and it’s also the most important. It’s surprising how many companies with homegrown encryption solutions store their keys in the same place as their data.

That’s kind of like “hiding” the key to your car in the ignition. If a thief breaks into your car, you just made it that much easier for them to steal it. Our advice is to store the key far away from the data. So, if we continue with the car analogy, you would store the key in another town, in a safe.

“If it [encryption] is really inexpensive, and it's really fast, why wouldn't you do it?"

Open source tools like eCryptfs are driving down the price of encryption. Meanwhile technologies that enable “transparent” encryption are allowing organizations to maintain big data performance and availability.

Put it this way. If I told you that for a $100, I could rig your car so that only you and those you authorize could operate it, and that parts of the automobile would melt if someone tried to disassemble it, would you do it?

Of course you would. And encrypting big data has a similar effect.

The downside of encryption is you don’t get the awesome flame decals.

We’re going to have a little fun today, both at the hype surrounding big data, and at our CEO, Larry Warnock’s expense. This week, Larry gave an interview to CIO.com in which he likened big data to “"a giant fishing net dragging the bottom.”

Here’s the full text of that quote:

"It's like a giant fishing net dragging the bottom," Warnock says. "There's big fat tuna and swordfish in there, but also mussels and lobsters and flounder. They're just scraping data and they don't know yet what they're going to do with it. The correlations that could be drawn from that data haven't even been determined yet."

You can determine whether that’s really the best analogy for big data. Cleary someone needs to explain what the hubbub is about, because there’s apparently a lot of confusion over what big data actually is.

So with tongue firmly planted in cheek, I’d like to present five other big data analogies that have nothing to do with the fishing industry:

5) Big Data is like the WOPR. If HAL 9000 and Johnny 5 had a baby, it would look like the War Operation Plan Response (WOPR) from WarGames. For most of the movie, the WOPR sits idly by with lights blinking randomly. But what we don’t realize is this machine is ingesting and analyzing data in real-time about potential nuclear strikes and the effectiveness of countermeasures. If only the WOPR was smart enough to realize it’s primary source of information was a high-school kid with a bad haircut and a penchant for ditching class.

4) Big Data is like a vacuum cleaner. Credit this one to Larry too. Big data is quickly sucking up tons of content. Some of it good (coins, lost jewelry, etc…); but some seemingly useless at the time. In many cases you don’t realize what you have until you sift through it, and make sense of it.

Usually, I find crushed cheerios and raisins. Thanks kids.

3) Big Data is like a box of chocolates. On a related note, if Whitman’s actually used big data, they’d realize nobody like the ones with the raspberry filling.

2) Big Data is like fine liquor. Gazzang chief architect, Dustin Kirkland came up with this one. The basic idea is that the whole is greater than the sum of its parts. To realize the whole, or in this analogy, the keen insight, you need the right ingredients (data), a precise distillation process (parsing and analytics), yeast (different data) and fermentation (time).

With big data, you don’t often get brilliant results the first time out, so you need to repeat the process. In much the same way, the best liquors are distilled several times over. Where the analogy changes a bit is this. A great tequila or scotch may take several years to reach its full potential. With big data, however, all you need is extra hardware and software, and you can hit your destination in hours, even minutes.

I guess what I'm saying is, it’s Friday and I'm thirsty.

1) Big Data is like The Matrix. I think I’m going to save this explanation for a future blog, but just know this. There’s absolutely no way Keanu Reeves learns Kung Fu in five seconds without using big data.

In fact, I’d go so far as to say if the Matrix weren’t an enormous big data project, the world the computers created probably would probably resemble a crudely animated cable show:

Regardless of how you define big data, it’s important to remember that if the data is important enough to be analyzed, it’s important enough to secure.

What do you think? Send us your best big data analogies?

I wrote about the topic of securing big data on MongoDB last November, but given our product launch last week, I thought it would be worth revisiting.

MongoDB has emerged as one of the leading NoSQL/big data platforms. It’s not surprising that valuable information including private, personal and security-related data and intellectual property is being collected. This is data that requires strident protection from theft and tampering. Make no mistake, this is type of data is being targeted.

MongoDB databases contain data that needs to be secured and encrypted. Gazzang zNcrypt allows users to easily encrypt this sensitive information with AES-256.

I’ll show you here just how easy that process is for Mongo. In the demonstration below, we’ll refer zNcrypt as “ezNcrypt.” I am demonstrating this technique on a single server; however, this can just as easily be managed across a large number of MongoDB server shards and replicas. This setup also protects journal data and other security information (users etc.) in the mongo admin database.

In this example you will see how to:

• Go through a setup of MongoDB
• Populate MongoDB with test data
• Show that the data is easy gleaned from the files
• Install Gazzang’s zNcrypt – at a high level
• Encrypt the MongoDB data
• Setup the access control for mongod to access that data transparently.
• Confirm that the data is now protected from root and is AES-256 encrypted

1. Create a user
   Created a Linux user called mymongo
   Note: I gave mine system admin privs so I could sudo

1. Login as mymongo
   http://www.mongodb.org/downloads

1. Start mongodb up
   Start up mongod
   $ cd ~
   $ ./mongodb-linux-x86_64-2.0.1/bin/mongod --dbpath /var/lib/mongodb/data/db/

1. Login to mongo – Populate with some test data
   $ ~mymongo/mongodb-linux-x86_64-2.0.1/bin/mongo
   
   Insert data or not. I just did this to get some data in there.
   
   > use mydata;
   > for (var i = 1; i <=110; i++) db.things.save({x : 4, j : i, k : 'testing'});
   
   Spot the data in my files
   $ cd /var/lib/mongodb/data/db
   $ strings * | grep testing
   
   Of course I found the data

1. Install ezncrypt
   Go to http://download.gazzang.com

1. Now I want to Encrypt my data
   

   Shutdown mondodb

   $ ~mymongo/mongodb-linux-x86_64-2.0.1/bin/mongo
   > use admin
   > db.shutdownServer()
   > exit

   $ cd /var/lib/mongodb
   $ sudo /usr/sbin/ezncrypt --encrypt -n @mongodata data 

   Note: I don’t have much disk on my virtual server so I am using 
   -n (--no-backup ). By default we create a backup. 
   You will want to delete it once you are up and going.

   $ sudo /usr/sbin/ezncrypt --encrypt -n @mongodata data
   [sudo] password for mymongo: 
     ezncrypt | Checking system dependencies
              | Verifying ezncrypt license
              | getting information about location
              |   > path: /var/lib/ezncrypt/ezncrypted/mongodata
     ezncrypt | Checking encryption status
              | done!
       keymgr | Retrieving key from KSS
              |  > Encryption password retrieved from KSS
              | generating keys    
              | done!
       backup | backing up data
              |  > Backup disabled.
     ezncrypt | encrypting files
              |  > checking disk space
              |  > encrypting /var/lib/mongodb/data
              | done!
     ezncrypt | congratulations. you have encrypted your Files!!
          log | File: /var/log/ezncrypt/ezncrypt.log

   Now if you try and startup mongod you would see that it will fail – which is to be expected.

   $ cd ~
   $ ./mongodb-linux-x86_64-2.0.1/bin/mongod --dbpath /var/lib/mongodb/data/db/
   …
   Tue Nov 8 17:02:46 [initandlisten] exception in initAndListen std::exception: boost::filesystem::exists: Permission denied: "/var/lib/mongodb/data/db/", terminating
   …
   and
   $ dmesg
   [226661.489410] ezncryptfs: access denied PID=4452 UID=1001 NAME=mongod EXEC=/home/mymongo/mongodb-linux-x86_64-2.0.1/bin/mongod TO=/var/lib/ezncrypt/ezncrypted/mongodata

   BTW - The same information is in the linux syslog – and its something you can alert on – IDS for your files.

2. So now lets add the Access Control so the mongod process can have transparent data access.

   $ sudo /usr/sbin/ezncrypt-access-control --add "ALLOW @mongodata * /home/mymongo/mongodb-linux-x86_64-2.0.1/bin/mongod" [sudo]

3. Restart mongod

   $ cd ~; ./mongodb-linux-x86_64-2.0.1/bin/mongod --dbpath /var/lib/mongodb/data/db/

   Now its starts

4. Run a quick re-test

   $ ~mymongo/mongodb-linux-x86_64-2.0.1/bin/mongo

   > use mydata
   switched to db mydata
   > db.things.find();

5. Try to get to the data now

   As root even – access is denied
   $ sudo ls /var/lib/mongodb/data
   ls: cannot access /var/lib/mongodb/data: Permission denied

   If I go to where the actually files are
   $ cd /var/lib/ezncrypt/.encrypted_private/mongodata/var/lib/mongodb/data/db

   $ strings * | grep testing
   As expected and wanted - this finds nothing

   If you look (cat or vi) at the files you see they are all AES-256 encrypted.

Next Steps
So – I suspect there may be some additional rules needed for the mongo utilities – nothing is jumping out at me at the moment – but I will add to this blog when I spot a need. I might want to encrypt my mongo backups/exports. Basically out create the backup directory, run zNcrypt –encrypt on it. And then create the ACL permissions for mongodump.

Conclusion
Plenty of important data is going into NoSQLs these days and especially mongodb. If you need to protect that data and improve and harden the security for the environment within which it runs, ezncrypt is a great solution.

I had a really interesting conversation with Thor Olavsrud of CIO.com yesterday about securing big data. The discussion lasted about 40 or so minutes and touched on everything from homomorphic encryption to dredging the ocean floor for mollusks (as an analogy for Big Data).

The result was an insightful and well-written column that appeared today, called “How to Be Ready for Big Data.” It’s one of the first pieces I’ve read on big data that seriously looks at the how organizations are going to secure the massive amounts of information they’re collecting.

And Thor isn’t just hearing about this from Gazzang. David Saul, chief scientist at State Street Bank, also gets the need for organizations to think about big data security from the outset:

"I believe the biggest mistake that most people make with security is they leave thinking about it until the very end, until they've done everything else: architecture, design and, in some cases, development. That is always a mistake."

We’ve touched on this before. Retroactively trying to protect big data is expensive, time consuming and fraught with peril. Thinking about security from the very beginning is the best way to protect your data.

Finally, I wanted to leave you with my top four tips for securing big data. Thor asked for these yesterday, and although they didn’t make the final article, I thought they’d be worth sharing with you.

1. Transparently encrypt data as it’s being written to disk
2. Establish robust, policy-based key management
3. Monitor your big data. Know who’s accessing the data and why
4. Establish a breach or violation response policy ahead of time

If you have any additional tips, please add them to the comments section.

Gazzang brings Transparent Data Encryption to securing big data with its proven high-performance kernel module, remote encryption key management and process based access control lists. Our goal with the Gazzang Encryption Platform for Big Data is for end users to not notice any performance degradation after deployment. Performance is paramount with the ezncryptfs kernel module, and our customers have found that it meets their needs

The goal behind remote key management is that the encryption key never sits next to the encrypted data. Instead it’s stored on a separate secure server and only loaded directly into memory on the server that decrypts the data so it never gets stored on disk. The remote key management also enables administrators to "lock down" encryption keys during a potential compromise of their systems.

Process-based access control lists (ACLs) are a very powerful and unique feature of the Encryption Platform. The main difference between the Hadoop, Cassandra, and MongoDB Jumpstarts are their access control list rules. As anyone familiar with linux knows, the default filesystem permissions are setup as read, write, execute per owner, group and everyone. With the Encryption Platform (referred to in the example below as ezNcrypt), we have extended the filesystem permissions to individual processes. This allows you to secure data so that only the defined allowed processes can decrypt and read the encrypted data.

To better understand the process-based ACL let's take a look at a MongoDB deployment.

In this example each MongoDB shard has three mongod servers in a replica set. Each of these servers will have a running mongod process typically located at /opt/mongodb/bin/mongod. To configure an ezNcrypt ACL, we need to run the following command on each node or as part of the deployment scripts:

#sudo ezncrypt-access-control -a "ALLOW @mongodb * /opt/mongodb/bin/mongod"

When running this command you will be promoted for the encryption passphrase. After successfully configuring this rule, the only process authorized to decrypt and read the data @mondodb will be /opt/mongodb/bin/mongod. This insures that no other process can gain access to the secured data. A malicious user or a compromised httpd process for example will not have access to the secured data.

What mongodb data gets encrypted is controlled by the @mondodb secure container. You can define the data that gets encrypted by dropping it into this container by running the following command:

#sudo ezncrypt --encrypt @mongodb /var/lib/mongodb/data

By executing this command you are telling ezncrypt to move all the files from /var/lib/mongodb/data and drop it into the @mongodb secure container. For mongodb to work transparently with this secure container, a symbolic link will automatically be created in its place, linking the original location to the secure data.

To find out whether the data is encrypted and working, you can run a very simple test. Try to access the encrypted data directory with an ls command. You can even try this as root user.

#sudo ls /var/lib/mongodb/data

ls: cannot open directory /var/lib/mongodb/data: Permission denied

You should receive a Permission denied error. OS users will no longer have access to the data, yet mongod process continues to run, decrypt/read data as well as automatically write/encrypt any new data.

The access control lists for Hadoop, Cassandra, are similar to the ones for MongoDB but require some extra steps as they use java rather than a standalone executable.

Behind every wave of new technology, there’s a second wave that trails closely behind it. Often that’s where we see security come into play.

It’s no different with big data. Petabytes – even exabytes – of data are spread across hundreds of commodity servers with information divided and replicated across nodes and distributed configurations for high availability and maximum performance.

Ok. It’s great that we can do this, but what’s keeping this widely disseminated data secure? And, if the data is protected, are the security measures negatively impacting big data performance?

High-performance is a key tenant of big data, so much so that it’s built into the NoSQL architecture. In fact, these days performance is expected anywhere a user needs to access data: a busy airport, at home or on vacation on a remote island.

So how do you secure big data without penalizing performance or radically re-architecting your application and the environments in which you’re deploying?

To respond to this unique big data challenge, last week we launched the Gazzang Encryption Platform for Big Data. You can read more about the product and our view on big data at www.securingbigdata.com.

We’ve been talking a lot this week about securing big data. It’s an important subject, and you’re going to be hearing a lot more from us about it.

But today, I want to take a look at what else is making news in the world of security. Let’s get to the headlines:

SC Magazine - Exclusive: How Sony is Fighting Back
April 2011 was a difficult and costly month to say the least for Sony’s PlayStation Network. This is well-covered territory by now. It’s good to see Sony battling back by bringing in a former U.S. counter-intelligence officer to run their security operations. Brett Wahlin knows he’s in for a different kind of fight this time around, batting ‘Anonymous’, which operates very differently from state-sponsored groups.

Mobiledia - Hackers Speak out at SXSW
And speaking of ‘Anonymous’, a few members of the group were on hand at SXSW this week for the premiere of the documentary, “We are Legion”. Unfortunately, none of them bothered to stop by our GazzangBang last week.

Today - The Lost Cell Phone Project
Symantec conducted an elaborate social experiment to find out what happens when someone finds a lost cell phone. Would folks try to track down the owner or rummage through the data and apps? I guess I’m more disappointed than surprised by the results. A few takeaways from this story:

1. Password protect your phone. Even if you don’t use it for work, your address book alone contains enough sensitive data about you and your acquaintances to do serious damage.
2. Encrypt your most sensitive data and applications. Password protection only goes so far. It’s more a nuisance to hackers than a deterrent.
3. Move to Ottawa. People are apparently far less nosy there.

The Register - IDC Big Data: Big Biz Worth $16.9 billion by 2015
OK, you didn’t think I’d go an entire column without mentioning big data, did you? This article lends further credence to the belief that the big data market is real, it’s growing and it’s not going away anytime soon.

“When you look at the servers, storage, networks, software, and services that comprise this big data market as defined by IDC, you get a market that was worth $3.2bn in 2010 and that is expected to grow at a compound annual growth rate of 39.4 per cent over five years to hit $16.9bn by 2015. That growth rate, says IDC, is seven times higher than that of the overall IT market over the same five-year span.”

This data needs protecting in motion or at rest. You can read a lot more on this topic at www.securingbigdata.com

Huffington Post - And the most commonly used password is…
This may be the least shocking piece of information you’ll read this year. This story simply shows that most people do the absolute minimum when it comes to meeting security requirements for passwords. As someone who works in marketing for an IT company, this story just makes me shake my head.

As someone who works in marketing for an IT security company, this story makes me want to ram my head through my monitor. If only there were a video that parodies how silly some people’s passwords are…

Oh wait, there is. Check it out.