Many SOC's are strapped for well qualified analysts and there is an ever increasing number of detections to respond to and resolve. In my case we were onboarding new AWS responsibilities and to make up for the lack of analysts and AWS experience this playbook was created to streamline the process of responding to Guard Duty alerts by eliminating the initial mitigation as well as the set for the forensic process.
What it does
This playbook is triggered by Guard Duty alerts on network activity. It then moves to block the offending traffic and create a snapshot of the volume which can be converted and attached to a forensic workstation via an EC2 Launch Template.
How I built it
First I started with an issue, namely EC2 instances contacting hosts they shouldn't. I then drafted a playbook on paper that was workable and met our basic needs. Then I worked to transfer it to XSOAR.
Challenges I ran into
XSOAR doesn't have all the EC2 commands available yet to really make this playbook pop in my opinion. In production we ended up modifying the built-in EC2 integration to fit our needs a little more specifically and I expect most clients would probably do the same to some degree or another. As this is outside the scope of this contest I ended up working around these issues and creating a playbook that works well on it's own and meets the basic need of the automation while allowing for room to expand and customize it as necessary.
Accomplishments that I'm proud of
Taking the time out of a busy schedule to better learn the XSOAR platform and apply my AWS knowledge.
What I learned
I had never used the EC2 integration prior to this so I learned the commands which were available and how best to use them as well as how to extend the built-in integrations with custom commands.
What's next for AWS Compromised Instance Forensics
Next is to trial the custom version I have written for our production environment and hopefully get it into mainstream use along side our other playbooks.