The Use (and Overuse) of Encryption

Somewhere over the last decade, there’s been a shift in the focus on using encryption. We used to use both HTTP and HTTPS, FTP and SFTP/FTPS, and understand when one is used versus the other. But something has happened along the way and now it’s become a knee jerk reaction to automatically put in place encryption for anything that you are going.

Putting in a Web Application internally? Use HTTPS even though it’s not externally focused. Transferring files over a ESB internally? Gotta use SFTP.

What been lost along the way is the understanding of the information that is being communicated and it’s importance. Remember, if information is considered public, it doesn’t mean that you have to treat it like it’s the crown jewels of the organization. At the same time, the internal strategies of the company aren’t something you want everyone to know.

In short, people got lazy and started treating everything as if it was sensitive data. It’s easier to just automatically use encryption regardless of whether it’s needed or not simply because you don’t want to have to make decisions. Or, and I wouldn’t be at all surprised by this, maybe security people started saying “always encrypt”.

Encryption is an important tool in the toolkit of a Security Architect. It’s great for securing that sensitive information that is in the database that you need to protect. It’s great for ensuring that the information you want to send from one partner company to another partner company isn’t intercepted. And the use of keys is a great way of ensuring that there’s proper authentication of disparate systems.

Oh, and by the way, there IS a difference between using Keys and using Certificates. But, again, people don’t understand the difference and how/when to use either.

But there’s are downsides to using encryption that people have to remember. For instance, as computers become more powerful, it becomes easier to decrypt something that shouldn’t be decrypted. The use of Encryption will impact the performance of systems because it’s just another activity that the resources of a server has to deal with. And certificates can expire so you have to have a set of management activities in place to ensure that the expiration doesn’t occur unintentionally.

It used to be, back around the turn of the century, that there was going to be “the year of PKI”. Never happened. People started putting in PKI solutions so that they could manage the certificates and keys that were being used. But guess what happened? Projects started using self signed certificates and not those being issued from PKI infrastructure. Why? Probably because it was too much of a bother to get one. You had self signed certificates and you have Publicly issued certificates from Verisign, Entrust, et al. To also have a managed system was to now have 3 different processes for 3 different types of certificates. Guess which one got ignored.

Here’s my rule of thumb; If someone hasn’t determined what their information classifications are, then any requirement for encryption can’t be backed up. You have to understand the importance of the information before determining if encryption should be used.

Here’s another rule I go by; in an Enterprise sized organization, expect one system a year to fail because of expired self signed certificates. It’s going to happen so plan for it and plan for how to mitigate it.

Here’s another rule, related to the last one; Enterprises will NOT know where self signed certificates are located. I would recommend when you first start with an organization to arrange for a discovery of self signed certificates. You can arrange for the use of a tool from a number of Vendors that have them available. Just do a search in Google for “Certificate Discovery Tool” and you will get a list.

Here’s one last one; Don’t create your own encryption standard. Make use of the NIST released draft “Draft SP 800-175B, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms“. NIST updates their guidelines for approved algorithms on a regular basis so why try to be an expert when that is what NIST is for.

Where do I use encryption? I use it for both data in flight and data at rest. For “Data in Flight”, I’m looking at SSL and VPN. If I have that, in only the most extreme cases am I also requiring the data going across that encrypted channel to be encrypted as well. Otherwise, it’s just overkill. For “Data at Rest”, there are very specific requirements laid out in things like PCI and HIPAA. If an industry standard requires encryption of the data at rest (ie. in a database or while residing in memory), the I do it. Otherwise, I only require encrypted data if it’s classified as sensitive by my organization. Maybe Private information is considered that, but that’s determined by the internal Security Standards and Policies.

Encryption is important but don’t over do it. Like with anything, it’s possible to overdo the implementation of security and that makes systems more complicated. And a complicated system is much more likely to be broken or become a security risk than a simple system.

Hope that helps …



Leave a Reply

Your email address will not be published. Required fields are marked *