With this post, we’ll conclude this series covering the most common AWS Security Event Root Causes. To recap, 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
Here, we’ll look at #’s 5 and 6.
#5 – Lack of continuous vulnerability management
This root cause is focused primarily on the security of your operating systems and any relevant services and dependencies. The encouragement is to take steps to ensure that ports and protocols are not open to discovery and exploitation.
- Do you know what’s installed on your OS images?
- Is your server OS hardened?
- Do you know when your EC2 image/AMI was last updated?
- Could you be deploying instances with security vulnerabilities?
- How many vulnerabilities may exist in your environment?
- Maybe you routinely apply OS updates but what about any relevant applications?
- Are you protected against zero day exploits?
The risk:
- If your AWS resources are not checked for vulnerabilities, there may exist open ports and protocols which could be discovered and exploited.
Prevention:
- Use defense-in-depth strategies to reduce exploitations
- Use vulnerability scanners, such as Amazon Inspector, to assess your environment for deviations from best practices. Once Inspector performs an assessment, it will provide a detailed and prioritized list of security findings based on their severity level
- Establish a trusted method for creating base images and delivering applications
#6 – Unmanaged application software security
This common security event root cause is a lower-level extension of the previous one. We just looked at OS and application level patching and hardening but here the focus is on coding practices and application protection (WAF, firewalls, etc.). When providing services for public consumption, do you simply put EC2 instances on public subnets or do you front-end private instances with a public-facing load balancer which is integrated with AWS WAF? Do you do all you can do to limit Denial of service (DoS) attacks by building security into your code and architecture?
Prevention:
- Implement OWASP Top 10 controls for secure coding practices
- Deploy analysis tools to detect common vulnerabilities
- Use defense-in-depth and application firewalls
- Use endpoint security tools that can detect nefarious execution
- Create a Security “Red Team”
- Red teams are experienced professionals trained to think like attackers who continually probe applications to identify vulnerabilities designed to improve the security posture of an organization.
A Call to Action
To wrap up the root cause events presentation, AWS gave 5 “Calls to Action” for their customers and partners:
- Ensure you have a defined incident response plan and shared responsibilities (people, process, technology) for cloud.
- Use email distribution lists for AWS account contact information to ensure multiple people have the ability to respond to events.
- Ensure enablement of AWS GuardDuty, Security Hub, CloudTrail, and audit logs for detection of security events.
- Enable tools and training to ensure your teams can query logs and respond as necessary.
- Routinely train and simulate cloud security events with your customers to iterate and improve detection and response times.
AWS Security Incident Response Links
Here are some additional links you may find useful as you dig into AWS security:
