Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

Proactively Protecting Sensitive Data

Today’s cybersecurity efforts and implementations are not working. Cyber-attacks are intensifying and hackers are still getting through, in part due to many organizations’ focus on defending the perimeter and the misguided belief that those defenses will hold up.

With more than 3,800 publicly disclosed data breaches in the first half of this year alone, according to Risk Based Security, up from 54% compared to the same period last year, we are facing a cybersecurity crisis.

Perhaps it’s time for enterprises to consider a different approach – one where if hackers get in, they don’t walk away with anything of value. Consider a jewelry store where every item on the shelves consists of worthless glass gems – all the diamonds, rubies, and emeralds are kept offsite in a safe. In the event of a heist, the front window might be shattered and all the glass gems taken, but the cost hit in terms of precious jewels – data – is minimal.

One of the most effective ways to put the equivalent of costume jewelry in your database is with expanded use of encryption and tokenization, both of which can be implemented without disrupting current applications and processes. By using these technologies, organizations use cryptography to transform sensitive customer and other data into a non-readable form. Even a massive data breach yields nothing of value to the hackers. The risk has been mitigated. 

Encryption is one of the most effective security controls available to enterprises. Yet to date, database administrators and IT professionals have historically viewed encryption as carrying unacceptable performance overhead, and data security professionals have viewed it as redundant — only useful if firewalls, identity management, and other security measures fail.

Clearly, traditional cybersecurity defenses are insufficient, as the steady stream of data breaches indicates. It’s time to make the case for application encryption.

A different approach: application encryption
One of the best approaches to enterprise data security is proactively encrypting sensitive data as soon as possible. Implementing encryption up front at the application layer minimizes exposure of clear-text data. This “top-down” approach also reduces the need for secondary encryption platforms like full-disk hard drive encryption software. This largely addresses the concern that encryption at the application layer – where it’s needed the most – is cumbersome to deploy and manage.

Fundamentally, application encryption allows organizations to encrypt entire files or specific fields of data at the application level, before it is stored. With application encryption, data is encrypted immediately upon ingestion into an application, which protects it across its entire lifecycle, from input to storage.

For added flexibility, application encryption can work together with other cryptographic techniques and use cases such as Point-to-Point Encryption (P2PE), tokenization, or any other additional encryption-based data security mechanisms.

To ensure system performance, organizations can easily fine tune their application encryption by only targeting specific files, data types, or columns of data that are deemed sensitive. This reduces unnecessary encryption of non-sensitive data and minimizes any effects on system performance.

Avoiding common mistakes
An effective application encryption solution requires key management combined with general purpose encryption within the application. For large organizations, this will require implementation of a hardened key management infrastructure.

A common mistake is performing key management within the application itself. This is troublesome for multiple reasons, as this model places the keys within the application, which subjects them to the same network threats as the application itself.

It also requires the extension of key management access to each application manager, which raises the risk for internal theft or negligence. Other encryption mistakes that can lead to vulnerabilities and data breaches:

  • Misconfigured implementations
  • Deploying vulnerable versions of crypto solutions
  • Using the same key in both directions for communication
  • Failure to understand the points of weakest controls
  • Implementing weak cypher suites
  • Siloed cryptography
  • Using software-based key storage programs

Software-based encryption programs are inherently flawed due to their vulnerability to malware, keylogging, and other attacks that attempt to determine encryption keys. To avoid these risks, the preferred approach is to use hardware security modules (HSMs) to store encryption keys.

HSMs offer a far more secure option and are scalable and flexible enough for enterprise-level application encryption. HSMs store keys in an internal secure cryptographic device that is fully compliant with industry requirements (specifically FIPS 140-2 Level 3). Such a device offers sophisticated levels of physical security, including:

  • Tamper-responsive circuitry that erases sensitive data upon detection of any intrusion attempt
  • Physical security barriers that prevent access to internal components
  • Digital signatures of cryptographic modules that prevent substitution attacks

Data breaches are a fact of life in every industry, encrypting data at the application layer is one of the most effective ways to keep your sensitive data out of the hands of criminals.

Implementing application encryption can be accomplished without impacting your existing applications’ performance or usability. It requires an adaptable and secure hardware platform for general encryption and key management that meets stringent levels of compliance for physical and logical security. Application encryption is a must for organizations serious about protecting data from end to end.

What’s Hot on Infosecurity Magazine?