Skip to content ↓ | Skip to navigation ↓

In an article we wrote for Tripwire, we discuss the advantages of encryption and tokenization. The premise of our argument is as follows: slow down your adversary by making your data meaningless to them. In other words, make yourself a “goes nowhere” project forcing your adversary to seek out a target that does not cause them the grief you do.

Encryption works precisely because it slows down an actor but it comes with some bad news, as well. Therefore, we wrote this add-on article to explain some of the drawbacks of encryption.

The first is that encryption is not widely employed (especially at the everyday user level) because it can be frustratingly difficult to employ. For example, Pretty Good Privacy (PGP) is a great tool for email encryption, but it can reach levels of head-bashing frustration given that you have to exchange keys with all your contacts to enjoy secure email (reason #14,352,785 why the words “secure” and “efficient” should never be used in the same sentence).

Here is another reason why encryption gets a bad reputation though (apart from some noted frustrations of implementing it): you need to do it right. We know this sounds obvious, but encryption implemented in the wrong manner will give do the following: give you the false sense of security (as in reality you have none) and make you a big fat juicy target if anybody finds out you that have implemented your encryption incorrectly.

Unfortunately, correct implementation can be quite difficult because of the platforms we use, meaning that there are a series of challenges that must be addressed. Cryptographic systems that are secure and robust require good math (and let’s be honest, most of us are not math geniuses). Therefore, we are often left to the “trust us” word of vendors, IT staff, and your niece or nephew that has to fix your computer every time you click the wrong thing.

So, how do you get around this problem? Do some homework and make sure whatever you are being sold meets NIST Cryptographic Standards. If you cannot do this on your own, find somebody who can do it for you. Taking this step make cost you more up front in both time and money, but this effort could very well be the life-saving step you take to protect your data.

Therefore, a word of caution: if you do not know what cryptographic system is being employed, you run the risk of possibly implementing an insecure system. Why do we say possibly?

Cryptographic systems that are proprietary (those that have not been publicly tested and scrutinized) may very well meet mathematical robustness. The problem is you have no way of knowing, or testing, whether or not the cryptographic system is actually secure unless you have insider information. Therefore, be cautious if somebody is promising you a pot of gold.

To help solve this problem, NIST offers a very useful public resource: the Cryptographic Algorithm Validation Program (CAVP) which lists tested and recommended cryptographic algorithms. If the system you are being sold is listed on there, chances are you are in good hands.

The next challenge that comes with encryption actually has little to do with encryption. You could have implemented a robust cryptographic system, but what if you are leaking information?

This scenario could come in a variety of forms. From a technical perspective, your operating system has not been updated with the latest patches. So, you may be thinking you are using some secure application on your device, but the encryption scheme on the application is actually quite useless if your operating system has already been hacked.

In plain English, what this means is that the adversary is viewing all your information in plain text before it even has a chance to become encrypted and transmitted or stored. It is sort of like using a car with seatbelts, airbags and lane departure warnings but that’s had its brake lines cut.

From a “people perspective,” you walked away from your computer and did not lock it. You can use all the encryption methods known to mankind, but if you are using your “secure” device in an airport lounge and walk away for a moment to reload your drink, well, in those few seconds that you do not have “eyes on” your computer, an adversary could pick up vital information just from a quick viewing.

Why? Because that “secure” device is operating in an “unsecure” mode (chances are you are not doing homomorphic encryption in your head…we’ll leave that topic for another post).

Remember, DiM and DaR are two entirely different concepts and must be protected accordingly, which begs the following question: what good is it if your data is being transmitted securely if there is a nefarious actor sitting on your server waiting to scoop it up once it has been converted back to plain text?

The point we are trying to make is that any information leakage creates vulnerability, so do not fall into the trap of thinking simply because you were told you are now using AES256 and SHA3-512 and who knows what else that you are “perfectly secure.” Again, any information you leak gives the adversary a clue and these clues could easily make your life miserable, especially when they make it out into the wild for analysis, just like the collection of 177 million stolen accounts from LinkedIn in 2012.

This is an oversimplification, but it drives home the point: just because your car has an airbag does not mean you should drive without your seatbelt and forget all the rules of the road. You are dealing with a “system of protections,” and each piece of that system supports and protects the other.

 

About the Authors: 

Paul FerrilloPaul Ferrillo is counsel in Weil’s Litigation Department, where he focuses on complex securities and business litigation, and internal investigations. He also is part of Weil’s Cybersecurity, Data Privacy & Information Management practice, where he focuses primarily on cybersecurity corporate governance issues, and assists clients with governance, disclosure, and regulatory matters relating to their cybersecurity postures and the regulatory requirements which govern them.

George PlatsisGeorge Platsis has worked in the United States, Canada, Asia, and Europe, as a consultant and an educator and is a current member of the SDI Cyber Team (www.sdicyber.com). For over 15 years, he has worked with the private, public, and non-profit sectors to address their strategic, operational, and training needs, in the fields of: business development, risk/crisis management, and cultural relations. His current professional efforts focus on human factor vulnerabilities related to cybersecurity, information security, and data security by separating the network and information risk areas.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.