The Pitfalls of DIY Security for Your AWS RDS Databases

AWS RDS enables easy DIY database provisioning

The trend toward using Database as a Service (DBaaS) is unmistakable. Organizations are leveraging DBaaS flexibility to bring new products and services to market faster, or to save time and money by reducing the cost and complexity of their database operations.

Amazon Web Services (AWS) is a popular choice for DBaaS because it makes it so easy and inexpensive to spin up new databases. The AWS RDS platform handles all the important details, installation, and configuration automatically. Business and DevOps teams don’t need to wait for IT to install and configure a new database – they can take a “do it yourself” (DIY) approach with no special expertise.

Can DBaaS security also be DIY?

It’s easy to make the mistake of assuming that since AWS RDS makes provisioning databases so easy, the platform must provide an equally simple way to apply security and compliance policies to those databases.

After all, the AWS platform itself is very secure. Plus, there are several other add-on tools and services available that can augment security. In theory, these tools and services could be used to assemble a security solution for DBaaS.

Before we can fully answer the question, we need to talk about what capabilities an AWS RDS database security solution requires.

Security and compliance gaps

The AWS platform itself is very secure by default, but your data is not – Amazon makes it clear that it’s your responsibility to figure that part out.

Database types offered within AWS RDS (such as MySQL, PostgreSQL, Microsoft SQL, Oracle, MariaDB and Amazon Aurora) include some important security measures, including defined users and access rights, data encryption and database snapshots. Note that these security features are not all enabled by default, so organizations must ensure they’re properly configured, used and managed. These capabilities (when enabled) are essential but not sufficient to ensure security and compliance best practices.

As we’ve covered in a previous blog, some important security and compliance challenges remain, and it’s left to the organization to resolve them. They include:

• Visibility – maintaining awareness of all the databases (in all your organization’s AWS accounts), and knowing which ones contain sensitive, compliance-relevant data
• Monitoring – keeping watch on all your databases (and more importantly the actual sensitive data within each one) and maintaining awareness of any actions that might impact security or compliance
• Accountability – being able to track and report the 5 W’s for all your information – what you have, where it is, who accessed it, when it occurred, and why it happened

DIY database security solutions fall short

Some organizations we’ve talked to have tried to use the DIY approach. They tried to cobble together a security system using a patchwork of tools provided by AWS and others to deliver a solution meant to close the gaps mentioned above.

For example, one approach to partially addressing the challenge would be to direct all database log activity to AWS CloudWatch and then program AWS Lambda to analyze the events and initiate followup actions. Another partial solution would be to send all database event data to a SIEM solution and configure specific event filters and workflows to manage the incidents.

There are two very important elements missing from any of these approaches.

• Inability to keep up. DIY systems must be manually adjusted and re-configured to account for each new database provisioned. In real-world environments where dozens or hundreds of databases are continually provisioned, changed, moved and deleted, using multiple AWS accounts, the human element will always lag behind the pace of change, creating unnecessary risks with unprotected data.
• Interface overwhelm. DIY solutions make it hard to work with your entire data estate because by definition they lack a single unified view. Different tools and interfaces are used to see database inventory, observe security status, respond to incidents, run reports, and so forth. This results in slow response times and missed risks, not to mention a lot of extra training and effort for the overworked security staff.

DIY database security projects are risky and hard

In practice, organizations that attempted DIY security projects dramatically underestimated the cost and commitment required, and in many cases abandoned the effort entirely. Here are some of the specific reasons:

• Lack of expertise. Implementation teams weren’t experts on the technology components or the breadth of security requirements.
• Bigger effort than expected. Many organizations experienced project “scope creep” as they discovered additional requirements or realized the problem was more complex than anticipated.
• Hidden costs. The technology components employed had a surprisingly hefty price tag, not to mention the additional costs of expert programmers and operators.
• Not a one-time project. Continual maintenance and modernization efforts were needed to fix issues and keep up with evolving technology.
• Not a side gig. It turned out to be too big an effort to be assigned as a part-time project to a team that already had other responsibilities.

To summarize, what they thought would be a reasonable effort turned out to be a massive, ongoing project. Most of them underestimated the cost and effort required, and simply didn’t have the time, skillset or ongoing commitment level needed to succeed.

Will a DIY approach actually perform when you need it?

Of course, the most important question is whether it works as planned. It’s one thing to construct a solution that seems to function. It’s an entirely different matter to depend on it when a serious security incident occurs.

Perhaps the best metric to measure success is money. A breach costs a substantial amount of money in terms of effort required to investigate it, penalties and fines for compromised information, and lost revenue from a damaged business reputation. In 2020, the average data breach in the U.S. cost $8.19 million and took 280 days to resolve.

Security teams need to see the big picture to quickly understand and respond to security incidents. DIY database security solutions can make it difficult or even impossible to get all the information needed in a timely way. There may be databases full of sensitive information they are not even aware of. They have to look at several different tools to understand what happened, to which data, by whom, and when it occurred. The longer it takes for organizations to find and resolve critical incidents, the more it costs. Anything that reduces the time required would present a very big return on investment.

How can Imperva Cloud Data Security help?

If your organization is considering a DIY approach to DBaaS security, we’d love to talk with you first. Imperva’s Cloud Data Security (CDS) solution delivers the comprehensive security you’re looking for, in a simple, inexpensive SaaS solution. This is not a side project for us.

In minutes, CDS reveals the location and security status of all your data and begins alerting you when any violations of your security policies occur. At any time, you can run comprehensive reports to support security reviews or compliance audits. CDS will also help you identify security issues you didn’t even know existed, by developing a baseline understanding of typical user behavior, and notifying you when it detects atypical or unusual activity.

Simply put, CDS lets you find and resolve security issues in your AWS RDS databases before they become compliance failures or data breach incidents.

Try it out

See for yourself how CDS can help address your AWS DBaaS security needs much more simply and affordably than a DIY approach. Check it out in the AWS Marketplace or explore it with a free 30-day trial.

More information about CDS
Imperva helps you secure AWS databases in minutes
Blog: Is Your AWS Data Secure and Compliant? Cloud Database Visibility in Minutes
Five Steps to Ensuring Secure and Compliant AWS RDS
Imperva Cloud Data Security Data Sheet