With cloud, security has shifted to the configuration--and misconfiguration—of cloud resources. Developers are moving fast, making their own infrastructure decisions, and changing them constantly. The self-service freedom of cloud is a boon for innovation velocity, but mistakes can create infrastructure vulnerabilities that modern cloud threats seek to exploit.
Why the Security of AWS Security Groups is Critical
There’s arguably no cloud resource that experiences misconfiguration more than security groups (e.g., AWS Security Groups; Azure Network Security Groups), which are the cloud equivalent of firewalls. The combination of frequency of misconfiguration and the potential risk that such misconfiguration events bring make security groups a priority for security and compliance teams.
Security group misconfiguration typically occurs due to overly permissive settings (which can be easier to configure than spending time on more granular configurations) and configuration drift from what was originally provisioned. The latter often occurs when a developer adds a new rule in order to gain access to an instance to get logs or troubleshoot an issue, but forgets to remove the rule when they’re finished, leaving the door open to bad actors.
Today, we’re going to take a look at how Fugue Risk Manager uses self-healing infrastructure to correct an AWS Security Group misconfiguration back to the provisioned baseline without human intervention or the need to write code or maintain automation scripts.
Establishing a Good Baseline for AWS Security Groups
Once you’ve configured Fugue Risk Manager to be able to scan and perform self-healing on the security group resources, you can take a look at your existing security and compliance posture.
We’ll now scan your AWS Security Group against the AWS CIS Benchmark to identify any policy violations. (You can also do this against Fugue’s out-of-the-box policy frameworks for HIPAA, GDPR, NIST 800-53, and PCI.)
In this instance, Fugue identified that SSH port 22 is open to the world, which violates AWS CIS Benchmark rule 4.1. We’ll use the AWS Console to close port 22 and bring our security group into compliance. You might choose your provisioning tool, such as AWS CloudFormation or Terraform, to correct this misconfiguration.
Now that we have our security group configured the way we want, let’s establish a baseline by clicking "Establish Baseline.
Fugue now knows this is the golden image for your security group configuration and will detect any drift from the baseline. There’s no need to create a blacklist of things you don’t want to happen to your security group.
Eliminating AWS Security Group Misconfiguration with Self-Healing Infrastructure
For some cloud resources, detecting drift from a baseline is enough. But for security groups that are associated with critical data resources, automated remediation of misconfiguration is mandatory. We don’t want to risk a long Mean Time to Remediation (MTTR) that leaves an infrastructure vulnerability in place for hours or days.
The method by which Fugue delivers self-healing infrastructure to correct for misconfiguration is baseline enforcement. Fugue knows how your infrastructure should be, and can revert misconfiguration back to the baseline for you, without requiring any coding or automation scripts.
All you need to do is click "Enable Baseline Enforcement." Now, rather than simply tell you when your security group configuration has drifted, Fugue will put it back to your established baseline configuration. There is no need to write remediation scripts for each potential scenario--Fugue can autonomously revert the security groups (and dozens of other resources) to the known-good baseline, just by clicking one button.
Now that Fugue has protected your AWS Security Group from misconfiguration, the risk of a data breach is drastically reduced and we’re not wasting time reviewing alerts, manually remediating issues, or writing and maintaining automated remediation scripts.
Testing Your Self-Healing AWS Security Group
To see Fugue’s self-healing infrastructure at work, all we need to do is create a misconfiguration within your AWS Security Group.
NOTE: Do not test cloud misconfiguration security on a production environment at first. We recommend testing Fugue’s self-healing response to misconfiguration in a test or staging account to get started. Since it’s easy to create a new Fugue environment to include your security group in a non-production environment, testing it takes only about 15 minutes.
Use Fugue to establish and enforce a baseline for an AWS Security Group in a non-production AWS environment. Ensure the security group includes legitimate HTTP and HTTPS ingress rules.
Go to the AWS Console, bring up the AWS Security Group, and add a rule. We like “open SSH port 22 to the world.”
For fun, go ahead and delete the legitimate HTTP and HTTPS ingress rules. With self-healing, you don’t need to predict everything that can go wrong!
Wait ten minutes, go to your AWS Console, and hit refresh on your browser…
You can also view a webinar we conducted in which we introduced misconfiguration for AWS Security Groups and other AWS resources to demonstrate self-healing infrastructure.
One More Thing...
If your organization is operating at scale in the cloud, Fugue can help by locking down the security of your critical cloud resources and give you full compliance visibility and reporting across your entire cloud footprint.
In less than an hour, you’ll have a full compliance audit of your cloud environment against standards like HIPAA, GDPR, PCI, NIST 800-53, and the AWS CIS Benchmark. And you can quickly and easily establish a known-good baseline for critical resources, detect misconfiguration, and use self-healing infrastructure to remediate it back to your baseline automatically.
Thanks to Becki Lee and Josh Stella for contributions to this post.