For years, the use of encryption to protect data-at-rest on computers within the enterprise was solely the responsibility of developers who coded the applications that used or generated the data. Early on, developers had little choice but to “roll their own” encryption implementations. Some of these early implementations were mathematically sound and somewhat secure. Other implementations, while perhaps not mathematically sound, were adequate for the risk developers were attempting to mitigate.

ClickToTweet: Critical Considerations for Application #Encryption from @ChrisEOlive http://bit.ly/1Y084Bh

As technology progressed, choices for encryption matured and solidified across development stacks. Callable libraries were born. Algorithms were perfected, significantly strengthened and pushed into the public domain. And beyond application encryption, encryption itself began to offer benefits to the enterprise at an operational level – within turnkey, off-the-shelf solutions that could be aimed at specific enterprise use cases such as end-point data loss prevention (DLP), encrypted backups, and full-disk encryption (FDE) among others.

Today however, when CISOs and senior security, software and enterprise architects think of protecting data-at-rest, their conceptions can sometimes harken back to days of old and they will stipulate encryption solutions as necessarily needing to be implemented at the application layer.

And while it turns out there is actually no extreme fallacy in this thinking and some benefits at this layer remain, there are some considerations and tradeoffs surrounding application encryption that aren’t overtly obvious. These considerations and tradeoffs can get lost when not weighed along with more recent turnkey, transparent solutions that get implemented at a different architectural layer with nearly the same benefit yet with much less risk and cost association.

Let’s look at and consider some of the ins and outs of application encryption. Hopefully the following thoughts and considerations will help those who are deep in the throes of needing to make a decision around encryption of data-at-rest.

Benefits of Application Encryption

More Secure: In general, the closer encryption is applied and closely coupled to the data, the more secure the solution will be and the more granularly and targeted it can be applied to that data. So of all data-at-rest encryption solutions, application encryption remains one of the more secure choices.

Minimal Upfront Cost: It’s a well known axiom within the software development lifecycle (SDLC) that the more up front you can make software architectural decisions, before any code is developed, the better and less costly the development will be. If new development efforts lie in front of you and encryption needs to be applied, implementing encryption at the application layer can make a lot of sense with almost no additional development cost (in terms of time) if included in the initial software design of an application.

(If application encryption is being considered for refactoring an existing application, which more often this is the case, then the costs change dramatically; I will discuss this later.)

Compliance Scope: Application encryption can take data out of compliance scope if the encryption implementation is such that it’s tightly coupled to storage and/or encrypted before ever hitting the network. If encryption were applied at a different architectural layer, the data may still technically remain in scope either over the network or on the server(s). It’s always important to understand the expectations from your auditors and compliance teams when selecting encryption approaches. But due to its granularity, application encryption can often help with reducing compliance scope.

DBA Exposure: It’s very difficult if not almost impossible to remove data from the exposure and reach of database administrators (DBAs) within a traditional relational database aside from using application encryption. If your requirements are clearly defined as needing to remove DBAs from access to data inside of databases, then application encryption is almost certainly how you will have to accomplish it.

Considerations of Application Encryption

As a practitioner out in the field who consults regularly with CISOs and senior security and IT leaders, I sometimes hear surprising myths about application encryption. Some encryption vendors will go so far as to hand wave the effort, and assert that application encryption is simply an exercise in “adding a few additional lines to an application” and <poof!>, everything will be encrypted.

Having a fairly extensive background in application development myself and for those who make a living in that arena, especially now, given the scale and importance of application development in the enterprise today… we know it’s not quite that easy and inexpensive to change and refactor existing enterprise applications.

But again, application encryption is absolutely valid, beneficial, secure and in some instances must be used to solve certain use cases. So my caution would be to step into solving use cases using application encryption based on a recognition of the following associated risks and costs:

Risks

For those going down the path of application encryption, they will need to consider these risks:

Full Data Analysis: To eliminate risks based on disruption, even if only one field is being considered, a full data analysis will need to be performed. All data points and data elements need to be considered and mapped against an application matrix. That is, which data elements need to be encrypted, where do they live, and what applications use, touch or interact with those data elements? Without this information in hand, the full cost and potential disruption cannot be adequately determined.

Search, Query & Analytics: Search, query and analytics are the very lifeblood of enterprises today. How will encrypting the data elements in what applications affect searching, ad hoc querying and analytics performance in all affected applications? Absolutely critical to consider and of medium to high risk.

Data/Software Architecture: Intrinsically, full blown encryption APIs place a lot of power and decision making usually into a few hands. In my experience, those decisions are often made by software architects who have little to no security background or experience in fully understanding exactly when and how the encryption API should be properly leveraged. That’s a fairly significant risk to couple with the fact that just in general, software design and business logic efficiency is a risk for many organizations to begin with, aside from layering in encryption to address significant security and compliance concerns.

Costs

For any organization with robustness and rigor built into their SDLC, if even one line of code is added or refactored in any application, a cost to the organization is exacted. Thanks to recent advances in automation around software development, testing and release (based on DevOps), those costs have been dramatically reduced. But it still doesn’t eliminate all the costs around time-to-implement and the release of a new version of software with application encryption.

Automation and strict SDLC policies around code check-in, continuous integration (CI), versioning, unit testing and even integration testing will certainly reduce the implementation and early testing costs. But consider that even within CI, new tests will have to be written and placed within the CI process. And outside of CI, functional, performance and QA testing will still need to take place.

It’s easy to believe that in later stages of testing, the possibility of some significant oversight to the functionality of the application will be revealed once changes are made to encrypt data. This is where encrypting can have impacts on search, query and analytics performance as well as on overall application performance where these functions are heavily relied upon.

These discoveries often come late in the testing cycle – after newly automated unit and integration testing all pass with flying colors. These issues have to be identified and pushed back as defects that must be addressed. And some of these defects will likely be architectural (and therefore much more costly in time to fix) if the proper data analysis wasn’t done upfront to drive the right software architectural design around application encryption.

Conclusions

Realize that all of the risks and costs associated with application encryption come per application. So to fully protect an enterprise, all applications that touch or produce critical data would have to be considered based on the risks noted above and costed as the cumulative time to fully analyze, implement, test, fix and release each application into production.

In our experience at Vormetric, ballpark figures made with customers run from months to years to implement encryption in a single application based on factors mentioned above. (One high-level estimate at a Fortune 50 customer with over 100 servers to protect, projected 2 years and over $2MM to apply application encryption. Transparent encryption was applied in less than 90 days at a fraction of the cost.)  When multiplied by the number of applications that must be encrypted, often the implementation of application encryption across all applications becomes cost prohibitive with respect to time and the associated risks due to continued exposure of the data to insider threat and potential breaches.

An Alternate Approach

One approach Vormetric often lays before customers based on the cohesiveness of the Vormetric platform is to first transparently encrypt all data that needs to be protected. Transparent encryption, which operates at a different layer and doesn’t require application changes, can usually be implemented in days or weeks instead of months or years as with application encryption.

Transparent encryption with strong policies and access controls usually resolves about 90% of the use cases and risks associated with unencrypted data (i.e. privileged access, insider threat, threat of breach, etc.) Once transparent encryption is in place, then organizations can afford to take the time to circle back and use application encryption to further secure critical applications and their data to bring the organization to a higher percentage of completeness and an even lower percentage of risk.

Summary

Application encryption is a valid approach to encrypting enterprise data and has benefits that can sometimes outstrip other solutions, depending on the use cases. However, application encryption also carries different risks and inherently a much higher cost than other solutions. Our experience at Vormetric is that these risks and costs are not as often considered when weighing how best to address data encryption and security in the enterprise.

If you have any questions, concerns or comments around application encryption or data security in general, please feel free to reach out to me on Twitter @ChrisEOlive or feel free to leave your comments below.