According to IBM’s 2014 Cyber Security Intelligence Index, 95% of all security incidents involve human error.
At Evident.io our own independent analysis shows a wide variety of security control mechanisms Amazon Web Services (AWS) makes available to its customers that are not used consistently due to human error, creating unnecessary security exposures while operating workloads in cloud at an acceptable pace and risk level.
At Evident.io we continuously aggregate, anonymize, and analyze AWS configuration data collected by the platform, and what we have found may surprise you.
From our analysis, I’ve highlighted the five of the most common AWS security risks detected by the Evident Security Platform in January 2015 and share simple steps you can follow to address them.
1) 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.
2) 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.
3) 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.
4) 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.
5) 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.