Adding Voltage for Secure Databases

When I moved to the US to return to teaching, I knew that things worked a little different here. One of the things that surprised me was how often I was asked for my Social Security Number (SSN in the US; SIN in Canada). It wasn't that hard to get one but it seems near impossible to keep secret.

Everyone – and I mean EVERYONE – wants it for one thing or another. How is an individual to keep it secret when everyone wants it? And if it's hard for me, what about companies that have to store it in their credit card databases?

Most companies use a variety of methods that piece things together in hopes that what needs to remain secret does. And when it came to actually protecting the data itself, often a restructuring of the database environment is necessary. This means higher costs, more downtime, more potential for error as systems are transferred over and just general headaches for administrators.

Why can't you encrypt the data without having to change the environment? We would no longer have to force the square block into the round hole. We can, instead, transform the square block so that it's a round peg, but still contains square data – just encrypted.

Voltage has introduced FPE, or Format Preserving Encryption. Simply, it encrypts the data in the same length and character type as the original data. This means a database doesn't need to be recreated to account for encrypted data and that makes it easier to incorporate into existing systems, even legacy systems.

Another plus is platform independence. And the ability to be called into a script or via command-line is a big plus in my book.

When you look at the alternatives, you really do realize that this is the way to go. Let's consider our other options.

First, you could encrypt the whole database. Oh joy. Performance-wise, this ought to be fun when it comes to adding data regularly. As an administrator the last thing I want to deal with is a slow database. Because that means users get to call me when I'd rather be out playing WoW or golf or something else.

A second option is to encrypt at the column level, but this requires specific database types, removes separation of duty options and limits the amount of security in applications. This means I have to spend for a specific database type, not all my applications will be protected and I still get calls. Not a good thing. I really don't like be limited to the database type I can have, not when I'm in a recession and trying to save money by using my legacy database as long as possible.

For a third option, I can encrypt from the application level down, but I have to plan for that first before implementing it because it means the database has to be designed for it. That's great out of the starting gate, but what about those older applications with hundreds of gigs of data and a database schema I'm happy with? Planned downtime with a permanent coffee IV? I don't think so.

And that is no better than doing a "look-aside" database where critical info is kept in an encrypted database that's referenced by a key. We'd still have to re-engineer everything to account for it and take a performance hit while waiting for a search for data to return information that is encrypted into an unencrypted format.

Why would I go through any of these when I can use my existing database and encrypt the data so it's the same length and format as the clear-text version of the data? I save myself so much time and effort that I can use doing other things.

With FPE (aka Voltage's SecureData), we can avoid many of the above issues, plus: no need to hire experts; no lengthy install/integration into existing systems; can use existing legacy databases; can keep full separation of duties; very little overhead to existing queries (batch queries might experience a small performance hit). And, if you're inclined, you can create our own applications that can tie into the existing toolkit (using Java or C code).

To further bolster this, FPE employs AES256, meaning that data can meet the rigorous encryption standards that are required for many applications and environments. And since we don't have to redo our databases, FPE can scale well as a company grows over time.

"Per infrastructure" pricing starts at $35,000, according to the company.

This is all great stuff. The one downside is the inability to deal with things like audio and jpegs. But that's OK in general. Most critical data is text based, representing the majority of what we want to protect (e.g., credit card numbers, SSNs).

I think that if I knew more organizations were using this to protect my SSN, I would not be as concerned about being asked for it so often.

This article was first published on EnterpriseITPlanet.com.