Legacy Data Encryption Solutions Were Never Designed to Protect Data in Use.  Why Protecting Data at the Application Level is so important. 

Data has never been more plentiful or more valuable, nor has it ever been more at risk from breach. Though hundreds of billions of dollars are spent each year on cyber security, data breaches continue all over the world, and sensitive data is still frequently compromised.  

Why is this still happening?  Surely, enterprises now know that they are responsible for protecting the sensitive information they acquire from their customers. More than 135 countries around the world mandate data protection and privacy through regulations, not to mention the seemingly endless industry standards like PCI, HIPAA, or the Graham Leach Bliley Act.  

And yet in a recent survey1, two-thirds of global companies reported being breached at some point in the past, and nearly half of American companies reported a data breach in the past year alone. In the USA, breaches cost companies nearly $10 million on average.            

 

It no longer appears to be IF a breach will target an enterprises’ sensitive data but WHEN. 

The reality is that most breaches happen at the application layer when data is exposed and susceptible.  Global analyst firm Gartner addressed this in a research note2: 

The reality is that most traditional data protection solutions were never designed to address protecting data in use – instead, they protect data in encrypted storage devices, databases, or file structures, securing sensitive information when its stored.  In these traditional systems, when an authorized application retrieves information from a storage location, the data is decrypted and passed it to the application unprotected. This means that most data is left exposed when in use at the application layer, where the majority of data breaches occur. 

 

 

In a recent survey, 85% respondents (IT professionals from two continents) reported being somewhat or very concerned with unprotected sensitive data at the application layer.  Despite this, fewer than 25 percent of respondents reported that they are actually applying data protection techniques at the application layer, instead relying on data-at-rest encryption3 

So if there is so much concern, why aren’t more people doing something about it?   Well… it’s complicated.  

Historically, protecting data at the application layer has been messy. In order to protect data at the application layer, at the moment when sensitive information is created, cryptographic libraries and data protection functionality must be interwoven into the application itself.  Developers needed to have some expertise in cryptography in order to understand what cryptographic keys to use for securing data and how to share those keys with other applications attempting to access data that the initial application had secured.   

Add in all of the other functionality related to modern data protection, such as tokenization, hashing, masking, digital signing, redaction, and then try to customize how data is revealed by the user trying to access it, not to mention the need to maintain, traceability, and alerting when things change, and the complexity grows exponentially. Attempting to manage this complexity in an application, which might not have encryption as its primary function, is, in the words of a recent analyst presentation, “ideal, but too difficult to be practical.”  

As a result, those charged with securing the most sensitive information of their customers have found themselves in a bit of a quandary: add complexity, or risk exposure. Unless something could be done to simplify protecting data at the application layer, data might never be truly secure. 

Nearly a decade ago, the Prime Factors team began seeing this evolving challenge, and we set out to develop a way to simplify protecting data where it is most at risk.  We architected a data security platform that can define and enforce data security policies that protect sensitive information and enforce data privacy wherever data is used, moved, or stored.   

Leveraging our data protection policies (DPP) engine, customers can quickly, easily and comprehensively define: 

  1. What data should be protected using which type or combinations of broad-spectrum security techniques (encryption, tokenization, hashing, signing, masking, redacting, etc.),  
  2. Who should be able to access or “unsecure” the data, and  
  3. What form the data should take when access is granted (clear, masked, tokenized, partially tokenized, redacted, etc.).   

We implemented this solution with an architecture that allows us to deploy exceptionally quickly and apply DPPs to data immediately when it’s created, at the application layer, without needing to interweave protection into applications themselves.  This means the highest level of data protection (application-native data protection) can be integrated in a matter of hours instead of months (or years, in some case) – on premises, in the cloud or in hybrid environments.  We call it EncryptRIGHT® – application-level data protection SIMPLIFIED. 

Learn more about how  EncryptRIGHT® software helps to simplify protecting data everywhere it is used, moved or stored. 

 Citations 

  1. 451 Research Customer Survey – 2018 
  2. Gartner, Security of Applications and Data Primer for 2019, February 2019 
  3. Application-Level Data Protection Survey, Lucid – a Cint Group Company, 2021 

Leave a comment