Hello everyone! In many ways, it feels like “forever” since I last wrote anything. So much has happened since the last post but between surgeries, back problems, customer projects, and some PTO, I felt an urge to sit down and see if I could put a few sentences together and jump back into this multipart AWS Security Incident Root Causes series.
The six most common AWS security incident root causes are:
- Unintended disclosure of security credentials and secrets
- Customer does not ensure the complete accuracy of their AWS account information
- Insecure AWS resource configuration
- Inactive response to GuardDuty and other detective controls and alerts
- Lack of continuous vulnerability management
- Unmanaged application software security
In part 1, we looked at #1 and #2. In this post, we’ll examine #3 and #4.
#3 – Insecure AWS resource configuration
Insecure AWS resource configuration is the 3rd item on the AWS security incident root cause list. At this point, we’re not talking about security holes within EC2 instances necessarily though that will come later, but we’re talking about things like:
- Incorrectly configured resource policies, Amazon S3 buckets/bucket policies, etc.
- Incorrectly configured security groups, especially open security groups that allow everything to and from 0.0.0.0/0. Yes, that will get your application working, but it can also open you up to a world of trouble.
- Assigning public IP addresses to instances or resources that should only have private IP addresses. If you use the “default AWS VPC”, the auto-assign public IPv4 address option is enabled for all subnets as shown below:
This can lead to:
- Unauthorized data or system access / compromised customer data
Detection and Prevention:
- Double-check the Auto-assign public IPv4 address setting on your subnets and verify that only public subnets have this option enabled.
- Use AWS Organization Security Control Policies (SCPs) to restrict critical changes
- Encrypt you EBS volumes with a KMS key and use key policies as an access control mechanism
- If public access is not required for an S3 bucket, block public access. Additionally, ensure S3 bucket policies are set according to your organizations security standards
- Use MFA for AWS account access
- Act on AWS Security Hub and AWS Config rule status messages/notifications
#4 – Inactive response to GuardDuty and other security controls and alerts
In a previous series, I wrote about the importance of enabling Security Hub, GuardDuty, and IAM Access Analyzer as you build your organization. I still stand by that, still encourage you to it, and congratulate you if you have done that. But now, you’ve got AWS alerts and notifications to consider in addition to the 100s or 1000s or 10000s of alerts you already monitor over the course of a given day. All of these alerts can cause a security team to feel overwhelmed and overloaded, leading to “analysis paralysis” or “alert tyranny“, where the sheer volume of security alerts is so overwhelming that breaches go unnoticed or undetected.
This can lead to:
The full measure of this topic is too big to address with a few bullet points but for this post, we’re confining our scope to AWS resources/services. If no action is taken on GuardDuty alerts or Security Hub findings, your ability to detect, respond to, and recover from security breaches will be affected.
- Detection and Prevention:
- Work on your threat models and tailor AWS security baselines for your organization. Do you ingest into Splunk?
- Define a plan and know what to do with your alerts.
- Integrate Security Hub into your AWS organization and enable the Security Hub security standards
Post 2 Wrap-up
That will wrap up post #2. On the next post, we’ll cover items #5 and #6, Lack of continuous vulnerability management and Unmanaged application software security.
In the interim, here’s a link to the AWS Best Practices for Security, Identity, & Compliance page. Perhaps the Detection & Incident Response section would be an ideal place to start.
