Published: 02 May 2016
The POODLE attack caused many organizations to update their security practices to avoid enterprise encryption vulnerabilities caused by client or server fallbacks to Secure Sockets Layer 3.0, an older but widespread communications protocol used to encrypt data in transit. Google is credited with identifying the SSL 3.0 vulnerability in October 2014.
At FICO, the credit risk organization in San Jose, Calif., best known for its FICO scores and fraud protection analytics that retail banks use, the threat of man-in-the-middle attacks against the "Padding Oracle On Downgraded Legacy Encryption" exploit required internal updates of its servers. In addition, FICO needed to get customers to patch their own software to support Transport Layer Security (TLS) encryption, the successor to SSL 3.0.
CISO Vickie Miller says FICO has covered the entire spectrum of encryption choices and is "tracking with all the advances being made in this space." However, that strategy doesn't always translate into "no problems," according to Miller, who admits to experiencing some challenges managing a heterogeneous encryption ecosystem. "But it is an acceptable tradeoff for having strong encryption diversity," she says.
Encryption, sometimes referred to as cipher text, is a powerful tool, but its implementation -- from secure handshakes to encryption algorithm choices to public and private cryptographic keys -- presents its own set of perils.
"In information security, we focus on the so-called CIA triad -- confidentiality, integrity and availability," says Joel Bilheimer, vice president of cybersecurity at Pershing Technologies LLC, a consulting firm in Columbia, Md. "I have had many clients and customers state that they don't need to worry about data confidentiality because it's encrypted." However, he points out, "implementing encryption without understanding the context in which it is placed benefits no one and, in all likelihood, grants a false sense of security to the data owner."
Know Your Algorithms and Keys
Rich Guida, the former head of information security at Johnson & Johnson, says in his position he learned that successful enterprise encryption required ensuring best practices on multiple fronts. First, you must pick the right encryption algorithm and key size (the number of variable random bits used to encrypt or decrypt data) in order to have confidence in its security.
"I can tell you from personal experience that there are a lot of vendors selling encryption algorithms that are proprietary," says Guida, who is now managing director of his own consulting practice, Guida Technology Associates Inc., in Hillsborough, N. J. When cryptography is customized, according to Guida, it means they don't really understand the issue. The encryption algorithm needs to be publicly known so you can understand how it works; because, ultimately, you are relying on the key more than the algorithm.
Second, you have to ensure the implementation of the enterprise encryption strategy conforms to whatever standards have been set for that algorithm. "Usually that means something approved by the National Institute of Standards and Technology," Guida says. For most enterprises, that's the Advanced Encryption Standard (AES), a NIST specification for encryption of electronic data that the U.S. federal government adopted in 2002. The specification is used worldwide and has spread to the private sector.
Part of the ISO/IEC 18033-3 standard for data confidentiality, the AES algorithm is a symmetric-key block cipher that uses the same cryptographic keys to encrypt plain text and decrypt cipher text. "It does have some modest vulnerabilities that have been uncovered in the last few years," Guida says. "But it hasn't been broken, and it remains the standard for the federal government." One strength: AES can grow over time by simply implementing longer key lengths; 256 bits is the current champion, but 512 bits is a possibility in the future.
You also have to ensure that the cryptographic key -- and anything related to it -- is properly controlled and secured, so there is no way to deduce the variable strings. "If it is not properly protected, it is like having a state-of-the-art lock on your house door, but then leaving the key under the mat," he says.
John Kindervag, vice president and senior analyst at Forrester Research, agrees key management is the biggest hurdle facing enterprise encryption -- at the moment. However, something beyond public key infrastructure is needed, due to the unwieldiness of the technology mechanisms from an operational standpoint. The PKI is a framework of software, hardware, digital certificates and policies that bind public keys to identities, authenticating people and computers to ensure secure encryption. The argument Forrester makes is that the number of standalone encryption functions that must be embraced (laptops, networks and so on) imply that no vendor will ever be likely to provide a unified cryptographic system based on PKI.
The proven value of APIs in other roles offers a model for supporting interaction between and among cryptographic subsystems, according to Kindervag and his colleagues, who outline their findings in the report, "Welcome to the New Era of Encryption," published in September 2015. Assuming this trend emerges, Forrester predicts it will spur a growth in centralized or enterprise key management systems.
Encryption usually works. Unfortunately, most of the weaknesses associated with the technology revolve around its implementation, not usage, asserts Alex Pezold, CEO and co-founder of TokenEx LLC, a cloud security provider in Tulsa, Okla., whose data platform offers encryption, tokenization and key management. "What I mean by that is, if you try to brute force the cipher text output from AES 256 chances are, we'll never see the original plain text that was pushed through the AES 256 algorithm in our lifetime," he says. However, if attackers are looking for the cryptographic key used to encrypt the data instead -- that's where the weakness resides.
Key management is one of the biggest challenges of building an enterprise encryption strategy because the keys to decrypt the cipher text have to be "living" somewhere in the environment, and attackers often have a pretty good idea of where to look. Organizations that need to access encrypted data on a regular basis often place encryption keys in stored procedures within a database management system, where protection may be inadequate. Another risk factor is SSL, "which has recently been compromised to the point where you cannot use it anymore," Pezold says.
To have a higher confidence in your enterprise encryption strategy, the first questions to ask, according to Bilheimer: Where are the encryption keys maintained, and who retains ownership of them? Many consumer-oriented cloud services retain private keys at the service layer, which means your data may be accessible to administrators on that service. That's great for availability -- your data is mobile and recoverable -- but not for confidentiality.
An information security plan that allows individuals to recover personal data if they forget their passwords is very different from one in which there are multiple redundant access points to that data by design. Security and risk management varies depending on whether you're considering onboard encryption for consumer products, such as smartphones or laptops, versus enterprise encryption schemes for organizational data. "The former is generally accessible to an individual, but the latter must necessarily be accessible to large numbers of users," Bilheimer says.
It's also an aphorism that for every action, there's an equal and opposite reaction, notes Bilheimer. If your encryption strategy is to build a PKI, you need to make sure to protect against man-in-the-middle attacks. If you are planning to archive data over time, then you need to preserve your keys and plan for crypto obsolescence. "The biggest concern I have is that people think encryption somehow trumps that fundamental balance -- and it almost never does," he says.
Encryption of personally identifiable information (PII) and other sensitive data does not protect organizations from regulatory scrutiny or interference, as Apple discovered. The balance between privacy and national security is shifting as intelligence services and law enforcement in the United States and Europe debate newly proposed encryption laws.
The many data privacy laws in place or evolving globally can only be addressed successfully with encryption "or its cousin, tokenization," Forrester's Kindervag says. One big driver will be data residency requirements, which he views as largely impractical to implement. However, the concern over privacy must be addressed.
Encrypted data also shields companies against many breach disclosure laws, he says. This precedent was first set by the "granddaddy" of such laws, the California Security Breach Information Act (SB-1386). The California state law, initially passed in 2003, requires organizations that maintain personal information about individuals to only inform those individuals if the security of their unencrypted PII is compromised. Some jurisdictions have tried to forbid encryption, but it has become so central that such an approach is no longer appealing or practical, Kindervag notes.
Enterprises need to pay close attention to international data privacy laws and licensing or other regulations related to the import and export of cryptography tools. Some countries demand that organizations have the expertise to decrypt information on any product they sell if asked to do so by authorities. "You must have the ability to open the box, so to speak," Guida says, although he cautions that he is not a lawyer. "That precludes true encryption best practices and places a big burden on an enterprise."
"Encryption for the privacy of data, while it may not please everyone, should be universal," says Pezold. If you look at countries in the European Union, for example, their data privacy laws are very stringent and they do not have the same challenges as citizens in the United States when it comes to identity loss or theft, he notes.
"At the end of the day, as with any technology, the strength with encryption resides completely in its implementation. If it is not implemented correctly, or if the components used to ensure strong encryption are not secured correctly, then this technology is at risk," he says.
FICO would not be able to do business without encryption acknowledges Miller. However, she adds, "You will never go wrong with over-architecting the way you manage, store and rotate keys."
About the author:
Alan R. Earls is a Boston-based freelance writer focused on business and technology.
More on data encryption in the cloud
A primer on encryption and cryptography
The right move? Bring your own encryption keys