Databases are one of the most important architectural components of modern product design. DBs come in different forms such as commercial RDBMS, open-source NoSQL, managed cloud provider DBs, embedded DBs for small scale applications, etc.
It’s no hidden secret that DB security is vital for protecting customer data, yet we continuously see large DB breaches with millions of customer records being leaked on a regular basis—despite efforts to improve DB security.
Two main types of attacks that apply to DBs are online and offline attacks.
As the name suggests, online attacks revolve around online DBs that attackers can communicate with. These attacks look at exploiting DB software vulnerabilities, configuration issues, inadequate authentication protections, network exposure etc.
Protecting a DB against online attacks requires a multi-pronged strategy such as continuous patching, configuration hardening, authentication/role enforcement best practices, network-level protection using a firewall or a network ACL, etc.
Offline attacks target DB backups, primary DB storage and replicas thereof. These attacks can be carried out without the timing constraints of online attacks. Hence one may not even know about the extent of the damage caused by these attacks. This article will focus on offline attacks on DBs and describe strategies that can be used to mitigate these attacks.
Offline attacks on DBs
Data leak. Entire datasets could get leaked if the data-at-rest protection is not implemented correctly or if the Key management process is not following best practices. Importantly, many DBs keep indices for speeding up search and if these indices are not handled with caution, then partial data breaches could occur. Any partial data breach typically reduces the exhaustive search required to break encryption, which in turn reduces the work required to perform targeted attacks.
Data modification. If the data is secured against theft (confidentiality), but not integrity protected (authenticity), then an attacker could alter DB records including deletion of records. This attack can be performed in an offline manner by, for example, targeting records in the backup. Such attacks could be as bad as loss of data if processed without checking for authenticity.
Data re-ordering. Even if the integrity of individual records is ensured, an attacker can still violate the integrity of the DB as a whole. For instance, many of the transaction/audit usages in a DB depend on the order of records. An attacker could reorder records without being flagged by encryption or authenticity checks.
Data replay. Similar to the attack described above, an attacker can violate the integrity of the DB by replaying existing records thereby creating duplicates or by re-introducing records that were previously deleted.
Is your primary/backup store protected? There are many ways to do this and not every method provides the same level of security. Your choice must account for scenarios that your application is exposed to.
You should ask following questions before proceeding with making changes. Are your primary/backup/replicas,
- protected by the storage?
- protected by the DB?
- Protected by the application itself?
If your DB persists sensitive data on a storage service (onprem storage, cloud storage, backup/archiving solutions, etc.), then you are transitively putting your trust in the storage service’s ability to protect data at rest.
This Includs the ability of such a service to withstand offline attacks that attempt to break encryption on failed/replaced drives/SSDs/Tapes.
External KMS for Onprem storage or Bring Your Own Key (BYOK) for cloud storage provides a way to externally manage encryption keys and provides a kill switch for scenarios where physical breach/access is detected.
The Fortanix Data Security Manager (DSM) integrates with many of the storage vendors (such as NetApp Ontap, VMware vSAN etc) using KMIP interface. DSM also provides BYOK management with all public cloud providers for keeping your keys secure within your control when using Cloud Storage.
Most databases can protect data by transparently encrypting data before persisting it to a storage medium (Transparent Data Encryption, or TDE for short). This method provides better protection than storage-level protection as you are not dependent on Storage vendors implementation (which are mostly proprietary in nature).
DB-level protection usually protects backup with the same security properties as the primary store. DB-level protection can be combined with storage-level protection to further enhance security guarantees.
Key management is still a critical requirement when using DB-level protection. Most databases integrate with an external KMS such as the Fortanix DSM using the PKCS#11 interface to provide seamless integration.
Cloud databases such as Cosmosdb (Azure), Dynamodb (AWS) provide a way to integrate with external KMS such as Fortanix DSM to provide encryption at rest using customer managed keys.
Storage- and DB-level protection schemes do not require any changes to the applications. I.e., even legacy applications can be protected.
But if you want to have complete control of your application’s security, then your application should never write anything without encrypting.
While this is the best option from a security perspective, the implementation and execution does require deep understanding of doing encryption right.
Fortanix DSM provides client interfaces in many frameworks and programming languages. With support for interfaces like Java Cryptography Extension (JCE), Microsoft Cryptography API (CNG) applications can easily achieve this.
Also, the Fortanix DSM accelerator can be used as a drop-in replacement for these clients in high throughput/low latency use cases.
Protecting your database should be a key design aspect of your application’s architecture and needs to be decided in the early stages of building your product.
In any case, using a good crypto implementation and an external Key management is necessary. Fortanix DSM / DSM-SaaS can help you achieve this with simple and scalable integrations for all types of databases.
Finally, we must remember that protecting DB is not just a compliance requirement. Doing this right is important for building customer’s trust in your brand.