Hunting AWS RDS security events with Sysdig
The AWS RDS service itself falls on the AWS side of the Shared Responsibility model, but the day-to-day management of the RDS security instances falls on your side. When it comes to shared responsibility, your obligation depends on the AWS services that you deploy, and also other factors including (but not limited to) the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
Deployment mistakes or other changes made to an RDS configuration can result in major security risks, including data exfiltration and other critical consequences. But finding the high-risk events can be a bit like finding a needle in a haystack without the right tools.
In this blog, we dig deep into:
- A sample high-risk RDS event, and see how post-deployment drift can occur even if initial configurations follow best practices.
- How attackers can use any number of scanning services and tools to exploit publicly accessible RDS instances.
- Why it is critical to be alerted as soon as an RDS instance is made public, and we will focus on the actionable data needed to address the security gap.
- Hunting for these alerts using native tools, and comparing this to how Sysdig Secure tracks down and reports on these high-risk security events.
Visit our blog to better understand the possible attacks and how its exploitation can be detected and mitigated.
Blog: Hunting AWS RDS security events with Sysdig
00:10 Best practices
00:40 Changing an RDS instance to public
01:00 Hunting for the event using native services
01:47 Hunting for the event using Sysdig Secure
02:33 Using existing policies and defining new ones
03:41 Testing the new rule