Thanks to the General Data Protection Regulation (GDPR) and other regulations, it's tempting to encrypt every bit of personally identifiable information that exists in your environment. Encryption is certainly important, but a recent application security research report indicates that's not enough.
Before implementing encryption, make sure you understand what you're encrypting. It is a good start, of course. While GDPR doesn't require encryption, there are four mentions of encryption in the GDPR that provide incentives for organizations to use the technology.
For instance, 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 an attacker can't use it.
There are other incentives, too. The new California Consumer Privacy Act, which takes effect on January 1, 2020, states in section §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."
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.
Encryption seems to be the way forward, and companies will need to implement the technology if they haven't already. But be careful how you approach this. Here's how to do it the right way.
The encryption stack
It's useful to think of encryption at different levels of the TCP/IP stack—a notional "encryption stack" that closely parallels the TCP/IP stack. Transport Layer Security encryption—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 work 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 understand that when you encrypt at a specific place in the stack, the encryption protects only against threats that target layers at or below the level where the encryption takes place. Data is still in clear text above that layer.
[ Special Coverage: RSA Conference 2019 ]
What's protected, and what's not
If you safeguard data with FDE, for example, the encryption will protect the data stored on encrypted disks. But when the data leaves the disks and is handed off to the network access layer, FDE no longer protects it.
So, if cyber-criminals manage to steal a hard disk that is encrypted with FDE, they will probably be unable to access its contents. But if cyber-criminals intercept information being transmitted across a network, FDE provides absolutely no protection for that 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.
For its part, 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 unaffected by TDE.
And 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-level 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. And since these are the most common forms of encryption currently used by businesses, many organizations are not sufficiently protecting their data, or their customers, 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 of application security.
GDPR Article 32 requires that a business 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."
If you expect to achieve comprehensive data security, these technical measures must include a formal process for application security and vulnerability assessment.
Keep learning
Understand the newest privacy laws with this Webcast: California’s own GDPR? It’s not alone.
Take a deep dive into the new privacy laws with TechBeacon's Guide to GDPR and CCPA.
- Get up to speed on cloud security and privacy and selecting the right encryption and key management with TechBeacon's Guide.
