In this article we will imagine that you received a wakeup call at 2 am from the “Chief” to inform you that your company is about to be in the headline news in the next coming hours and he needs your help.
Some pieces of information are given to you as you continue to wake up. They are:
- It is suspected private information was leaked and made accessible to the world. It is believed that thousands of customer credit card numbers have been stolen.
- There is a possibility that someone internally changed the configuration in some ports in the production environment during some testing, but that is not confirmed yet.
Diagram 1: AWS-SG:
As time keeps running you realize that this incident can provide a big opportunity to test your baseline security control runbook.
You start by analyzing all the unusual activities in your AWS environments. You check the following log reports:
- CloudTrail logs
- DNS logs
- VPC Flow logs
- CloudWatch logs
- SNS topics Secondly, you check your Terraform state file to see what changes have been made recently.
Terraform to the rescue!
As we all know from my previous articles Terraform allows us to describe, create, modify and delete our infrastructure as code (IaC).
Having this in mind you finally discover the source of the problem. Whoever was doing the test in the wrong environment changed some AWS security group (SG) port configurations accidentally.
The question now is how do you validate your AWS Security Group rules using Terraform to avoid this type of issue in the future?
Before we dig deeper let’s learn some statements about AWS-SG
- They can explicitly allow
- They are attached to ENI’s
- They are stateful
- Their rules can be added and removed at any time
more information here
"A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. When you launch an instance in a VPC, you can assign up to five security groups to the instance."
The official AWS documentation
Conclusion
Now that we know the issue it is time to come to solution. Some possible ways to protect your projects in this type of situation are:
- Provide IAM least privilege access *
- Give hints to your team members using Terraform custom variable validation
- Use a Terraform tfvars file to save your sensitive information
In this post I will show you how this works.
First create a variable.tf file and create custom variable validation as shown below
Custom variable validation and result example.
As you can see if someone try to use the wrong configuration, they will receive an error message.
Remember to continue improving your security daily to reduce real risk. I know this is only a simulation and incidents like this do not happen often in real life but better to be prepared or know where to start troubleshooting 😊
Functions, arguments and expressions of Terraform that were used in the above project:
providers
variables
modules
resources
types and values
Find the Terraform repo and directions for this project here
I would like to give a big shout out to my mentor Derek Morgan. Thank you for all of your support all these months and for the amazing course "More Than Certified in Terraform" the best course out there. Link to the course here. If you want to connect with him and ask questions about his course, contact him via LinkedIn Derek Morgan or you can join the Discord channel here.
Top comments (0)