In the current era of emerging and sophisticated cyberthreats and attacks, encryption is one of the major defensive approaches that is being implemented in IT Infrastructure systems whether on-premises or in the cloud not only for compliance reasons but for its effectiveness in deterring attackers from data ex-filtration attempts. It's true that it has some drawbacks, and certain limitations that this blog will talk about, but encryption is still the most robust defensible approach.

Cloud vendors by default encrypt data on the network level and on the storage level, to protect their customer data. This defense in-depth security approach leads to exploring the common encryption levels currently being used when protecting database systems as database systems are the main IT platform to store your jewels (your data).

These levels are:

• Network Encryption
• Encryption At Rest (physical database files are encrypted)
• Application Level Encryption (field/column) level encryption

Each encryption level can secure and protect data hosted in database systems.

Network Encryption:

In a classical client/server architecture, data transmitted over the network can be compromised by man-in-the-middle attacks as attackers will be able to view the data in clear text if network encryption is not in place. To implement network encryption in database systems either a self-signed certificate (which is not the best practice as it will not enforce validation) or a certificate issued by CA (Certificate Authority) should be configured to enforce network encryption between the application and back-end database system.

Here are a couple of different examples of database systems where network encryption set-up options are available:

• In the Oracle database systems, there are two network encryption options:
  • Native Network Encryption: a database engine-level encryption through SQLnet.ora file configuration set-up.
  • TLS Network Encryption: encryption is using a TLS certificate.
• In the MongoDB NoSQL database system: you can enforce network encryption either by using self-signed certificate (through OpenSSL for example) or using a CA certificate.

Encryption At Rest:

Database systems store data physically as binary files in the hosting operating systems. If an attacker was able to exfiltrate these binary files, data could be read in clear text. This requires the attacker to have the ability to breach the operating system itself to steal the data files or steal the physical disks hosting database system data files. To prevent an attacker from viewing sensitive table data, encryption at rest, called Transparent Data Encryption (TDE), is important. It’s transparent because no application logic change is required, and data gets decrypted automatically whenever SQL query execution is being processed.

To have a TDE setup based on best practice, a key management infrastructure, such as the Hardware Secure Model (HSM), should be in place to store the keys. It’s best practice to rotate the encryption keys on a regular basis.

It is worth stating that this type of encryption will not protect against insider threats. A system administrator can view and access the data, so other means of protection are required to prevent system administrators from viewing the data.

Cloud providers currently provide virtual-based cryptographic key storage solutions to host secrets, certificates, and keys. Another method is hosting a dedicated physical HSM in the cloud infrastructure. Keep in mind that key management must be in compliance with Federal Information Processing Standard (FIPS) 140.

Application-Level Encryption (Field/Column) Level Encryption:

This type of encryption encrypts a specific set of columns hosting highly sensitive information. The column data will be encrypted on the storage level and can only be decrypted at the application level. So, the application will push the data in an encrypted format and data will be stored in cipher format so that even the system administrator will not be able to view it in clear text or decrypt it because it’s all controlled from the application level. The application will be written in specific code (language) and driver and will encrypt data through a key stored externally that is not accessible by the system administrator.

Examples of this type of encryption implementation:     

• MongoDB Client-Side Field Level Encryption
• Microsoft SQL Server Always Encrypted

Comparing The Three Levels of Encryption:

When considering all three types of encryptions, there are benefits and challenges with each. A benefit of the application-level encryption is that it will provide the best data protection in transit and at the storage level and will protect against a system administrator’s capability to view the specific set of sensitive columns. This encryption setup is a great protection, but it is also challenging when it comes to implementation as it requires development side changes.