According to IBM’s Cyber Security Intelligence Index, 95% of all security incidents involve human error. That’s beyond significant, and when rapidly deploying multiple iterations in a DevOps shop, that means there are lots of opportunities to fail.
Our own independent analysis based on customer configuration data shows that security control mechanisms Amazon Web Services (AWS) makes available to its customers are not always being used consistently due to human error, creating unnecessary security exposures while operating workloads in cloud.
In this article, we’ve highlighted the five of the most common AWS security risks detected in the first half of 2015, and share simple steps you can follow to address them.
EBS volumes are missing optional EBS volume encryption…
EBS volume encryption uses AES-256 and is a convenient mechanism for meeting data-at-rest encryption compliance mandates. An unencrypted EBS volume cannot be converted to an encrypted volume after creation. It is a setting that must be applied on creation of an EBS volume.
EBS volumes contain no snapshots less than two weeks old…
Snapshots are a low cost way to recover EBS volumes and they can be made while a system is online. We have seen a number of occasions where clients have benefited from snapshots in IR scenarios by enabling them to forensically analyze systems that had been compromised from recent snapshots in virtual private cloud sandboxes.
Unused EC2 Security Groups…
Keeping your EC2 security groups clean eliminates the risk that an unauthorized security group policy will be used by mistake to open attack surface. Often clients have had relatively new AWS users mistakenly launch EC2 instances using insecure security groups that lead to incidents. Practice good security hygiene and remove your unused EC2 security groups.
Unused or unmaintained ELB Security Groups…
Keeping your ELB security groups clean eliminates the risk that an unauthorized security group policy will be used by mistake to open attack surface. In large multi-tier architectures, ELBs frontend fleets of backend systems, and ELBs have security groups that should use authorized security group policy. Practice good security hygiene and remove unused ELB security groups.
Global permissions to access TCP or UDP ports in a security group that is attached to an active instance/ELB…
Restrict access to known static IP addresses or CIDR ranges within your control. Many clients have experienced scenarios where they found themselves conducting incident response efforts due to unauthorized EC2 instances that were launched using insecure globally accessible security group policies. Monitoring active security groups enables clients to shorten time to detection and time to remediation of firewall related vulnerabilities and enables clients to minimize attack surface.
About the Author/Justin Lundy
Justin Lundy, CIO & CTO, co-founded Evident.io after leading Adobe’s Cloud Security efforts to identify, implement, and manage security controls and strategies during rapid adoption of the cloud at scale. He has spent more than a decade in the infosec industry, and is a subject-matter expert in multiple domains. Justin previously defended the castle at Adobe, MTV/Viacom, Sun, and CA.
