stackArmor ThreatAlertTM Top 4 AWS Security Group Misconfigurations
AWS Security Groups are foundational to security providing baseline building blocks in any AWS cloud deployment. Security Groups are cloud firewalls designed to protect applications and data. Unfortunately, the perception that configuring and managing these building blocks is simple can lead to ignoring key best practices. stackArmor AWS certified Solution Architects and Security engineers have developed a set of best practices over the years and codified them into business rules in our ThreatAlertTM service. The stackArmor ThreatAlertTM Threat Index provides an aggregated view across customers, industries and deployments of common misconfigurations. An overwhelming 63% of vulnerabilities or findings were related to Security Group related issues.
The most common issues found with AWS Security Groups are:
- VPC default security groups: VPCs are created with a default security group that begins with wide-open ingress and egress rules. It is a security best practice to avoid using these default groups, and while many times they aren’t used, they are left alone as is. The best route is to delete the default security group and use custom security groups instead; or at the very least remove the ingress and egress rules of the existing default security group.
- Port 22: An important port for entry into servers, environments etc., but all too often Port 22 is configured to be left open to the world, which isn’t good externally as well as internally. Even for a required entryway such as an OpenVPN server, many times the allowed IP addresses don’t need to be 0.0.0.0/0 and can be narrowed down to a whitelist of addresses and/or IP ranges to increase security.
- Any Port: While Port 22 is the main culprit by far, any port left wide open to all IP addresses or too large a range of addresses increases risk and should be reviewed for hardening. In addition, many times TCP (and occasionally UDP) are left open to all ports and all IP addresses. Even if said security groups are internal, it is a best practice to keep rules narrowed to only the required ports/addresses and/or other security groups.
- Lastly, while it’s not as critical as ingress, more thought should be put into replacing the default wide-open egress rule for a security group to just what’s required.
All of this can seem a little confusing and can be a distraction to the everyday functioning of a company. Over time and with growth it’s easy for these security groups to get lost in the management mix, especially in a dynamic environment with rapid code deployment and automation using CD/CD or DevOps.
It is absolutely critical to monitor and manage such misconfigurations. The stackArmor ThreatAlertTM service provides a powerful AI Ops engine that is constantly finding and reporting issues in the environment. One of the main misconfigurations the service monitors for are wide open rules in security groups. The service alerts the security analyst when ports are opened up too wide, allowing the analysts to notify the business and work with them to remediate the issue (while automatic remediation can be done with the ThreatAlertTM service, the majority of the time stackArmor has found that it’s more practical to be alerted to the issue, notify the business and then work with them as there are times when the opening is legitimate).
This isn’t to say that all wide-open rules are invalid. The stackArmor ThreatAlertTM Cloud Integrity Scanner is very strict and reports on all configurations. In some cases, there is a valid reason to have a specific protocol/port open to all IP addresses such as http/80 or https/443. In these cases, it is important to log and record this explicit rule for reporting and historical reference. Such auditing and logging of configuration management information is a key requirement for compliance standards such as FedRAMP, NIST, HIPAA and others.
