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
https://sysdig.com/blog/aws-rds-security-events-sysdig/

00:00 Intro

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

04:22 Conclusion

MB01ILLZYRX33IA