Privacy Protection Means Encryption at the Application Layer

This post was originally published on this site

Comprehensive Data Security Measures Should Include a Formal Process for Application Security and Vulnerability Assessment 

Encryption is a popular topic with recent regulatory emphasis on “pseudonymisation and encryption of personal data” (Article 32(1)(a) of the General Data Protection Regulation). The requirement to notify affected customers within 72 hours of a data breach is waived for encrypted data, because no personally identifiable information has technically been exposed if the attacker can’t use it. While GDPR doesn’t require encryption, there are four mentions of encryption in GDPR that provide real incentives for organizations to use encryption.

The new California Consumer Privacy Act, scheduled to take effect January 1, 2020, states in § 1798.150(a), that any consumer whose non-encrypted or non-redacted personal information is stolen or disclosed as a result of a business’ lack of reasonable security measures, may sue that business for up to $750 each. A single data breach could result in a class-action lawsuit with penalties in the millions, if a sizable database of consumers and their personal information are exposed.

There is a temptation, therefore, to encrypt every bit of data of personally identifiable information that exists in your environment. That’s important, but a recent 2018 application security research report (PDF) indicates that it isn’t enough. Before implementing encryption to meet these and future regulations, make sure you understand what you’re encrypting.

The Encryption Stack

It can be useful to think of encryption as necessary at different levels of the TCP/IP stack – a notional “encryption stack” that closely parallels the TCP/IP stack. Transport Layer Security encryption that is used by secure web sites, for example, operates between the Application layer and the Transport layer. IPsec encryption—used to create virtual private networks (VPNs) operates at the IP layer. Link encryptors encrypt at the Network Access layer. Full-disk encryption (FDE) operates below the Network Access layer, as does transparent database encryption (TDE). 

There are good reasons to encrypt at different places relative to the TCP/IP stack, but it is important to understand that when you encrypt at a particular place in the stack, the encryption protects only against threats that target layers at or below where the encryption takes place (data is in clear text above the layer where encryption takes place.)

If you protect data with FDE, for example, the encryption will protect the data while it is stored on encrypted disks. When the data leaves the disks and is handed off to the Network Access layer, FDE no longer protects it. So if a cybercriminal manages to steal a hard disk that is encrypted with FDE, they will probably be unable to access its contents. But if a cybercriminal intercepts information being transmitted across a network, the FDE provides absolutely no protection for the data.

Similarly, malware that reads data from a hard drive protected with FDE will be totally unaffected by the FDE—once the encrypted data is read from the hard disk, the FDE no longer protects it. TDE protects data only while it is stored in a database. When the data is read from the database, the protection provided by the encryption is lost, so attacks that operate at most levels of the encryption stack are totally unaffected by TDE. And if you are using TLS to encrypt data between the Transport and Application layers, TLS will protect against attacks that target the Transport layer, the IP layer, and the Network Access layer, but it will not protect against attacks that target processes running at the Application layer.

The case for Application layer encryption 

The biggest and most severe data breaches that have affected both the public and private sectors all operate at the Application layer. This includes almost all versions of both malware and advanced persistent threat (APT) attacks. Because of this, encrypting at the application layer is the only form of encryption that will address these serious threats. TLS, FDE and TDE encryption are all insufficient when used alone. But since these are the most common forms of encryption currently used by businesses, most of their use of encryption is ineffective at protecting against the most serious threats they face.

As organizations garner their resources to address GDPR compliance requirements it would be a mistake to implement data security measures without holistic consideration for application security. It is therefore imperative for organizations to ensure that all systems, services, and applications that handle and process sensitive data are secure by themselves.

GDPR Article 32 requires businesses to protect its systems and applications “from accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data” by taking into account “appropriate technical and organizational measures”. These technical measures must include a formal process for application security and vulnerability assessment if comprehensive data security is to be achieved.

view counter

Travis Greene, Identity Solutions Strategist at Micro Focus, possesses a blend of IT operations and security experience, process design, organizational leadership and technical skills. After a 10-year career as a US Naval Officer, he started in IT as a Data Center Manager for a hosting company. In early 2002, Travis joined a Managed Service Provider as the leader of the service level and continuous improvement team. Today, Travis conducts research with NetIQ customers, industry analysts, and partners to understand current Identity and Access Management challenges, with a focus on provisioning, governance and user activity monitoring solutions. Travis is Expert Certified in ITIL and holds a BS in Computer Science from the US Naval Academy.

Previous Columns by Travis Greene: