If This Then Hack : An Intro to DIY Cloud Security Automation with Python

This year at BSides SF 2020, I got the opportunity to put together a workshop with our a member of our automation team, Moses Schwartz. There are many options available on the market currently for security orchestration, automation, and response (SOAR), which solve for end to end automation for security incidents being placed into your pipeline. Specifically, we needed cloud security incident remediation and integration into our SIEM and ticketing pipelines. Upon a lot of research, we determined that with a bit of Python, Terraform, and AWS Lambda, a security team could easily spin up their own “DIY” SOAR platform with these technologies that were readily at hand. Our goal was to provide a real working example of an end to end detection system that could identify, detect, remediate, and also document what happened.

Our Github repo https://github.com/ifthisthenhack/bsides walks through the specific details of how we go about deploying the entire environment. The diagram below shows at a high level the different components that would be used to configure this environment.

• EC2: Running Splunk and testing our automation
• Splunk: Our SIEM, ingesting CloudTrail logs and triggering automation by sending alerts to SNS
• CloudTrail: Native AWS CloudTrail logs that will pipe into Splunk
• Lambda: The remediation and ticketing code that will power our automation
• Baseline Enforcing: Once all of our mechanisms are in place, we can now go ahead and act on any of the prescribed detections we codify in either our Splunk detection or Lambdas themselves
• Ticketing System Integration: The Lambda code included in the workshop will be able to communicate with the Jira API, this can be altered to communicate with any system of your choice

Our automated detection workshop will walk through a simple security incident of an EC2 instance being exposed to the internet with vulnerable security groups. In addition, this can be used to solve for the following types of security violations in your cloud environment:

• Unauthorized API calls coming from an unknown IP or regions that should not be used
• Custom detections that you can fire from Lambdas, using any of the Boto3 APIs you’d like
• Checking to make sure your overall configuration stays secure, for example if someone turns off CloudTrail you can have this create a SIEM event and also notify your ticketing system

Terraform is used to spin up the infrastructure required inside of the AWS account including the following:

• An S3 bucket for the CloudTrail logs to be stored
• An SNS queue for CloudTrail to update for Splunk to know when to pick up more logs
• An SQS queue to help coordinate logs to Splunk
• A Splunk server EC2 that will have our logs forwarded from CloudTrail
• Lambdas with the appropriate IAM permissions to remediate and communicate to other resources such as SNS

We recommend following the tutorial in the Github link mentioned previously in this article in a sandbox account that is not related to any of your production workloads. Once you complete the workshop itself, you can run a terraform destroy command to remove all of the infrastructure and IAM policies that were created as part of the build. Currently, the workshop that we have created is open source and we encourage folks to fork and add things that they might see as helpful for others. Feel free to check it and let us know if you have any questions, you can reach us via LinkedIn or Twitter below:

Ashish Patel — @_ashishpatel on Twitter

Moses Schwartz — @mosesschwartz on Twitter