A Short but Comprehensive Guide to Database Security

Introduction to Database Security

Say what you will, relational databases are still the backbone of the Internet.

Over the last 10 years there has been an explosion of new ways to store and access data. Each brings its own benefits and interesting applications. With each new data store inevitably comes a wave of claims that “this is the future” and “relational databases are the past.” A quick Google of Graph, Web3, NoSQL and “replace relational database” will render plenty of results. I’m sure we will see some claims soon that vector databases can replace relational databases too.

However, the ground reality is that for most projects, an RDBMS is the right architectural choice. Even when you’re working with other types of databases, chances are that at least one component of the application will benefit from a relational database. Given this, it’s safe to say that relational databases will continue to play an integral role in applications for a considerable time to come.

Given the lasting importance of RDBMS, it’s crucial to secure the data within them effectively.

This security guide covers techniques primarily for relational databases. To make this guide easy to digest, I’ll focus on web interface-based applications built in AWS. However, the principles could apply to any web-based application or data storage structure.

Let’s think about the architecture as so: A request is made to a web server / application, a workload component (Kerbnetes, EC2, Lamda) handles the request, processes it, then, as needed, writes and reads to a relational database (MS SQL, MYSQL, Aurora, etc.). The database may be managed or self-hosted on EC2.

A simple web application architecture

To determine how we should protect the data hosted on the database, let’s think like an attacker before thinking like a defender.

Thinking Like a Hacker

From an attacker’s point of view, databases are a prime target for either stealing data or disrupting services. A truly vindictive hacktivist may just mangle records in subtle ways.

There are many approaches that an attacker could take to get to their ultimate objective.

I’ll glaze over the discovery phase of an attack (i.e. how an attacker figures out where a database may exist) as security through obscurity is not an approach I support. Nonetheless, an attacker will do some reconnaissance to figure out the method of attack that is likely to succeed. This can be network scanning, probing an application’s inputs to see how it responds, or open intelligence gathering (for example, a job posting about a new DBA role for your primary customer application likely tells a malicious party more than enough to come up with some ideas on where to start).

Once the attacker knows data is likely stored in a relational database, here are the methods they may employ to get access to or disrupt availability. (List is in order from lowest to highest tech.)

• Bribe someone with access to the hardware
• Gain physical access and use it for a physical exploit
• Social engineer someone into performing an action on their behalf
• Gain access to credentials
• SQL Injection
• Exploit an application with remote code that is internet facing
• Exploit an underlying component of the application stack or OS

An attacker needs to weigh the likelihood of success, ease of execution, and likelihood of being discovered to determine which approach to try. Typically, the most common approach is to try the lowest likelihood of being discovered and the easiest to execute first, then if that fails, try the next until all options have been exhausted.

As a colleague who has an interesting history used to say: “It’s not whether we could succeed, it was a matter of how much time and money we wanted to spend to succeed.”

Thinking Like a Defender – Securing the Database

Let’s switch to a defense perspective. We need to raise the bar for attacks high enough so that the time, money, and knowledge required is higher than what can be obtained without intensive efforts.

Reviewing the above, we can think of the controls relevant to protecting data in a RDBMS into seven categories: Physical security, access control, policies and procedures, application security, network security, resilience and backup, and workload / cloud security.

Let’s look at these more closely.

Physical Security

In this example, we are focusing on AWS / Cloud deployed RDMS. Physical security is maintained by AWS as part of the shared responsibility model. Of course, if your organization is one that is targeted by the brightest and best nation-sponsored hackers, auditing and working with AWS to ensure physical security meets your standards should be considered. Most organizations can point to the AWS public documentation on physical security.

If you’re still self-hosting, make sure your servers are in a well-secured location.

Access Control

Implement the principle of least privilege and use the following technologies in AWS:

• IAM (Identity and Access Management) is a crucial part of securing your relational database. It involves setting up policies to ensure only authorized users have access to the data, thus providing a robust system to protect sensitive information.
• Secrets Manager is another important tool for access control. It securely manages sensitive information such as database credentials, making sure they are not exposed to application code or logs, thereby reducing the surface area for potential attacks.

Policies and Procedures

Defining clear and comprehensive policies and procedures is an essential step in database security. This encompasses guidelines for data access, breach response, regular audits, and more, providing a framework for secure operations.

Application Security

• Implement secure coding practices, including using secure frameworks, proper input validation, and output encoding. By adhering to these practices, developers can significantly reduce application vulnerabilities that can lead to database breaches.
• During Q/A pre-release, ensure application vulnerability checks are part of your CI/CD pipeline and involve identifying and rectifying weak points in your application that could be exploited to gain unauthorized access to your database.
• The OWASP SQL injection prevention documentation is an invaluable resource that provides guidance on preventing SQL injections, one of the most common and damaging types of attacks on databases. The guide is viewable here and covers the following controls:
  • Use of Prepared Statements (with Parameterized Queries)
  • Use of Properly Constructed Stored Procedures
  • Allow-list Input Validation
  • Escaping All User-Supplied Input
  • Enforcing Least Privilege
  • Performing Allow-list Input Validation as a Secondary Defense

Network Security

• Utilize a WAF (Web Application Firewall) to provide a shield against web-based attacks by filtering, monitoring, and blocking malicious HTTP traffic targeting your database.
• Ensure you’re leveraging AWS VPCs (Virtual Private Clouds) to provide an isolated virtual network where you can control your own virtual networking environment, including IP address range, subnets, and configuration of route tables and network gateways.
• In addition, AWS Internet Gateway and AWS NAT Gateway are services that provide connectivity between your VPCs and the internet, with NAT Gateway providing additional security by not allowing inbound traffic.

Resiliency, Backups, and Recoverability

• Designing a resilient application architecture helps ensure that your application can recover quickly from any failures, providing constant availability to your users.
• Determine what high availability and recovery strategies are feasible, such as replication and clustering, to ensure your database is always accessible, even in the event of some types of attacks.
• Ensure at minimum you leverage out-of-band data backups. Creating backups of your data that are stored separately from your main database ensures that you can restore your data even in the case of severe incidents. This is where Clumio can help! Learn how Clumio helps you automate backup and simplify recovery for SQL Server on EC2, RDS, and DynamoDB.

Workload / Cloud Security

• Implement Vulnerability Management for cloud assets. This involves identifying, evaluating, treating, and reporting on security vulnerabilities in systems and the software that runs on them.
• Build, and request from vendors, an SBOM (Software Bill of Materials) which provides transparency about components and dependencies, helping to manage security risks associated with open source components.
• Make sure all dev teams practice library management. This involves keeping track of all the libraries used in your application, ensuring they are up-to-date and free of known vulnerabilities.
• Ensure your encryption is used in transit and at rest. Use AWS KMS (Key Management Service) to create and manage cryptographic keys that are used to encrypt your data.
• Ensure you are logging SQL transactions and OS logs. AWS CloudWatch Logs provide valuable insights on operational health, application performance, and security by collecting and storing logs from your AWS resources.

Summary

No matter how exciting the latest data storage methods are, RDBMS is here to stay. The resurgence of technologies like Fortran is testament enough that time-tested methods continue to maintain relevance in our evolving technological ecosystem.

Given that data stored in RDBMS is frequently critical, and subject to various privacy laws, it’s paramount that we prioritize resilient and secure applications built on relational databases. Here are some guiding principles to ensure success in your RDBMS security:

• Embrace the mindset of a hacker. Ask yourself, how would someone attempt to breach your data defenses?
• Never underestimate the importance of workload management and application security.
• SQL injections remain prevalent. Ensure you are not an easy target.
• Never overlook the importance of backups, particularly in cloud environments – it’s alarmingly easy to forget.

If you want more information, or need to backup your AWS RDBMS, give me a shout. I’m happy to chat or connect you with the right experts, regardless of where you need to enhance your security posture.

The post A Short but Comprehensive Guide to Database Security appeared first on Clumio.