Wednesday, December 12, 2007

Is your encrypted data also RIP with NeoScale?

There has been lot of talk in trade publications and blogs about demise of NeoScale. Jon Toigo asked interesting questions about the go-forward strategy of nCipher after picking up remains of NeoScale. Storagezilla also air-raided the encryption appliances by poking holes in Decru and his reluctant acceptance of appliance approach to some "data at rest" encryption problems (I wonder what problems, he is referring to).

After hearing the demise of NeoScale, my second reaction was:
"Hmm ... I wonder if NeoScale customers will think about decrypting the terabytes of vaulted data that was encrypted using Cryptostor before their appliance fails and no chance of finding a replacement."
I am sure Decru and other encryption vendors are salivating on the opportunity to sell in to NeoScale customers, BUT
Can their encryption solution decrypt the data encrypted through Cryptostor?
That is the question NeoScale customers should be asking when talking to encryption vendors about replacing Cryptostor.

I expressed my concerns to some people who are using encryption products. None had considered and/or planned for decrypting the data upon losing access to the tool (product) or method (algorithm) that was used to encrypt the data. It is a real scenario for encrypted data on any kind of removable media despite availability of correct encryption keys.

Just imagine what will you do if seven years from now a government agency requests financial data that was encrypted and archived on a removable media vaulted offsite. And, you realize that you can't read data because you no longer have the original system capable of reading and/or decrypting that data. I experienced the same challenge in a customer environment few years ago though with unencrypted data.

Unlike Mark, I am not very enthusiastic about encrypting "data at rest" specifically where encrypted data is stored separately from the system that wrote the data or is capable of reading that data. The demise of NeoScale may be just the wake up call for the trouble you may get into if you encrypt the "data at rest" and you have no way to decrypt the data because you lost the method or tool or keys to decrypt.


  1. Data at rest is often times stored in a much less secure way than your real-time system, particularly when it is in transit (is your iron-clad backup service leaving tapes lying around on loading docks?). Having it encrypted is not only wise, it would be negligent not to do so. How many stolen backups do we need to read/hear about before we get the message?

    Tools/products merely enable a tighter security infrastructure: Key management is a big part of regulatory compliance. The method/algorithm should always be one that is well-known, public, and scrutinized. Just like any data, keys must be backed up, but with much greater care when it comes to access and process.

    The focus on these appliances tends to be their hardware encryption capabilities, but key management is really their central function. Naturally, the two are combined in appliances since pulling keys out of your box defeats the purpose (somewhat). Scalability is not the specter Mark makes it out to be.

    On the other hand, there are still organizations that rely heavily (or entirely!) on process and eschew encryption.

  2. Dale: Nevada legislation requires encryption of data in motion. Legislation pending in Michigan and Washington would require encryption of data at rest.