Security pros are always challenged by cyberthreats – and bad actors have the skills to breach enterprises by malicious hackers seeking to monetize stolen data. The good news for security pros: encryption offers a robust last line of defense.
According to a 2021 study by the Ponemon Institute, half of organizations now claim to have an encryption strategy. When data has been encrypted, in most user cases it’s effectively useless to bad actors. The problem is that it’s complicated to encrypt and decrypt the operational data upon which businesses rely.
Those obstacles explain why encryption of data at rest has not yet seen anywhere near the acceptance of encryption of data in transit via the ubiquitous SSL/TLS protocols. The exceptions historically have been in government and military systems, where ironclad data security has become non-negotiable. But as regulations and penalties have grown more stringent, and as database encryption solutions have improved in usability and efficiency, more enterprises now realize they must integrate database encryption into their cybersecurity strategy.
Even so, challenges remain. Database encryption options abound and it’s challenging to determin the best solution – as can managing the cryptographic keys that enable decryption. Start by sorting database encryption into three methods: application programming interfaces (APIs), database plug-ins, and transparent data encryption (TDE).
The API method
This method of database encryption relies on individually modified applications that encrypt and decrypt data in and out of the database in real-time. The burden of encryption and decryption falls on an encryption agent within the application rather than on the database. On the surface, this seems like a simple solution: once encryption is in place at the application level, it’s one and done.
Yet in practice, the API method has so many drawbacks, some consider it a legacy option. The team must allocate significant development resources to modifying commercial or proprietary applications to support encryption. Plus, not only must the team encrypt data, but they have to modify queries and searches to access encrypted data. It’s a heavy lift in a world where development resources are perpetually overstretched.
Scale presents another issue. Encryption at the application level may perform well at first, but as the volume of data and queries rises, application performance decays unless more compute power gets allocated dynamically. We compound the problem when multiple applications, which may have been built or modified by different teams, read and write encrypted data to and from the same database.
Worse, it’s nearly impossible to orchestrate the sharing of an encryption key used by one application and database pair across other applications within the same database. That flies in the face of one of the most fruitful enterprise trends: consolidating data for analysis purposes to enhance customer relationships, optimize business operations, and identify new opportunities.
The database plug-in method
In the database plug-in method, all encryption/decryption goes through a module that integrates with, but is separate from, the database itself. Neither applications nor the database shoulder the computational burden of encryption. Most encryption plug-ins are specific to a single database software product, although a few support several.
Database plug-ins require some administrative and development effort. DBAs must take on new software to deploy, maintain, and update. More importantly, modifications to applications are required to query the encrypted data, although not as extensive as those demanded by the API encryption method.
On the plus side, with the plug-in method many modules come with additional capabilities, such as auditing, access control, and compliance management. With a variety of plug-in choices and features, determining the best solution can get complicated, as companies weigh the capabilities of modules against the functionality they already have in place.
The TDE method
Security pros should focus on the “T” for “transparent” – as the word implies, the TDE database encryption method requires the least administrative effort. Here, we embed encryption capability in the database engine itself, either as a feature offered by the database vendor or as a third-party tool that modifies the database software. No modifications of applications or queries are required.
With TDE in place, the database gets encrypted and decrypted in real time, along with database backups and log files, without the client being the wiser. Yes, TDE does place the encryption/decryption burden on the database engine itself, but we experience a performance hit typically in the low single-digit percentages – less if the data gets accessed in memory.
It’s clear why many prefer TDE. Developers, users, admins, and applications can proceed without caring about encryption at all – almost. As with all encryption methods, we need an encryption key to access the data, so proper management of those keys becomes essential.
Database encryption key management
The final piece of the puzzle: effective encryption key management – which 56% of respondents in the 2021 Ponemon Institute study considered a painful process. Managing encryption keys properly serves as the only way to ensure that only authorized users or applications can access encrypted data.
Think of database encryption as typically symmetric, which means the private keys that enable encryption and decryption are the same. It’s more straightforward than the asymmetric encryption used for data-in-transit, which requires a public key for encryption and a private key for decryption. Yet the simpler symmetric method underlines the vital importance of securing the private encryption key.
Both keys and certificates are generated by a certificate authority. Once created, the keys themselves are encrypted. Admins need to think in terms of the lifecycle of keys – the greater the volume and sensitivity of the data being encrypted, the shorter the lifecycle should be (one year vs. two years, for example). Fortunately, a wide selection of key management tools (including cloud services) make the administration of keys easier and include APIs to call on their capabilities.
Secuirty pros also have to consider the level of encryption desired. In most cases, database encryption gets applied at the column level using the industry-standard Advanced Encryption Standard (AES) with block lengths of 128 bits, or 256 bits when seeking stronger protection against brute force attacks. AES supports longer block lengths of 192 or 256 bits, but longer blocks tend to degrade performance. For all intents and purposes, 128-bit strength will dissuade malicious hackers from attempting to crack encrypted data given today’s compute and tooling.
Defense-in-depth
Cybersecurity threats never falter from their upward curve, interrupted by spikes stemming from unforeseen vulnerabilities, from the Log4j flaw to insecure software supply chains. Perimeter security, network security, application security, and endpoint security will always have their place in a robust security strategy..
Don’t think of database encryption as a panacea, but if adopted widely, it has the potential to vastly reduce the damage incurred by data breaches. It can also quickly accelerate the organization’s efforts to comply with security regulations. True, database security functions as just one of many security layers an organization needs to consider. But it’s the deepest one – without which organizations are likely to find themselves at greater risk in an ever more challenging cyberspace.
Dan Garcia, chief information security officer, EnterpriseDB
