Why Encrypt Your Data?

Why Encrypt Your Data?

Before you decide to encrypt your data in storage, you need to ask yourself some questions. Answer truthfully, now:

  • What is the usefulness of your data?

  • Is your data valid?

  • Can you verify the owners/creators of the data?

  • What would it cost you to replace or repair the data?

  • If your data started appearing in bus stops all over the city, would it bother you?

  • If your data became front-page news, would it affect your business?

I like the bus stop question the best. That one usually stops people short and makes them think. I’ve had decision makers in both public and private industry tell me that their data didn’t need protection, only to suddenly reverse their decision when they imagined hard copies of their data floating around the city unconstrained.

Encrypting your data is also a way to stop abuse and misuse because only the people who have the correct keys can open the data. Therefore, you can control who can see and change data. For example, you could set your system up so only the HR department and executives could open the files containing salary data and yearly budgets. Everyone else who tried to view this data would only see meaningless garbage instead of spreadsheets and memos.

By signing with digital signatures or fingerprinting your data with one-way hashes, you can ensure the validity of the data. You can find out if it has been changed, when the change was made, and who made the change. From those facts you can also find out if the change was authorized. This is important to protect critical software, too. When software has an associated hash, any change made to the program can be detected by a change in the hash. That can save you from using Trojanized software that has back doors and sniffers incorporated.

Then, too, many people underestimate the value of their data. They forget the man-hours or the man-months it took to create it. Although your data may be a conglomeration of public-domain information, its value is in how you massaged that data in order to turn it into a profit-making product. You may also have software that you have used for years, but it was created by someone long gone from your employment. If that software became unusable, what would it cost you to replace it? You’d have to hire programmers and you may never end up with the same usability.

And, what about the vast amounts of data that sits on the desktops and never makes it to backup media? Think of all the correspondence, facts and figures, proposals, and general business information that could be at risk of misuse or abuse. Many desktop machines are not automatically locked when the user walks away for a few moments. Almost anyone can sit down at an unlocked machine and fiddle with the data. Who would know? Not to mention the fact that it would appear that the changes were made by the data owner. The veracity of this data should surely be protected.

Here are some types of data that you may want to consider encrypting:

  • Financial data (yours and your customers’)

  • Personnel files

  • Executive correspondence

  • Sales figures and projections

  • Intelligence about your competition

  • Market intelligence about your customers — past, present, and future

  • All data on a laptop, because they are easily lost or stolen

Shame on me! I’ve used “encrypting” in a very loose sense here. What I really mean is that you may want to consider encryption technologies to either digitally sign your data, encrypt your data, create a hash, create a MAC, or a combination of these. They all use algorithms and keys, so I include them in the encryption basket of goodies.

You may have already protected your network with filtering routers, firewalls, DMZs, network address translation (NAT), intrusion detection systems (IDS), access controls, and physical security for the server rooms. But, have you ever tried to read the logs from firewalls? It’s like trying to read War and Peace with no punctuation, no paragraph spacing, and very small text — not only that, imagine that it’s all written in pidgin English. Not only are the logs difficult to read, it’s even more difficult to figure out if any particular event was really a hack attempt or not. The same is true with intrusion detection, the tattle-tale of network security. Intrusion detection systems have the capability of overloading you with so many alerts that your only recourse is to ignore them and pretend all those red flags are just the system crying wolf.

No system is hack-proof. Nor are they idiot-proof. People who can’t get through the security mechanisms will find newer and better ways to circumvent the systems. And, when you consider all the “allowed” traffic that has to pass through the system, you’ll realize that that legitimate traffic can carry piggy-backers. But, all this is moot if the data is strongly encrypted. Imagine the frustration of a determined hacker who has spent weeks crafting just the right exploit only to find out that he has stolen tens of megabytes of gobbledygook. The hacker now has to decide whether to try to crack the encryption. More likely than not, the hacker will go on to easier targets. Most hackers are opportunists — remember that.

So, what if you’ve done your risk assessments and it comes down to the fact that there’s nothing in your system that a hacker would really want. What about your employees? Many of the big credit card hacks and identity theft hacks were carried out by former employees who were holding a grudge against their former employers. If those companies had encrypted their data, the hackers still would have been able to get in, but the hackers would still need the valuable key needed to unlock the data.

I could go on all day quoting facts and figures, but now it’s time to get down to brass tacks. Let’s just say that you’ve decided to give encryption a try. Where do you start?

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows