I wanted to start blogging for a while now, this is meant to be a space where I can freely talk about my main areas of interest, namely -as you surely have guessed by the domain name- SIEM Detection, Cloud Security (particularly AWS) and Security Orchestration, Automation and Response.
I will strive to take a vendor-neutral approach whenever possible, there are just too many tools and vendors out there, both commercial and open-source, and you might be stuck with one of them for whatever reasons.
To get started, I'd like to introduce you to GDPatrol, a tool I just created:
GDPatrol is a Security Orchestration, Automation and Response (SOAR) framework based off AWS GuardDuty.
For those of you who might be unfamiliar with GuardDuty, it's essentially the simplest way to set up threat detection in AWS. You can get started with a simple "Enable GuardDuty" click in your region, although it's recommended to enable it even in the regions you're not currently using since it's free and attackers with stolen credentials might attempt to create resources in those regions first.
Once enabled, GuardDuty will start correlating your CloudTrail logs, VPC Flow logs and DNS logs to generate findings like this one:
AWS briefly mentions the fact that the findings can be remediated using a CloudWatch Event Rule and AWS Lambda, but how to achieve it is not documented too well in my opinion; I also had the impression that they had another use case in mind where people would go to create a Lambda just to address a really specific threat type.
Overall, it just didn't seem to scale too well, whereas other SOARs like Phantom and Demisto were either lacking a GuardDuty integration (Phantom) or didn't have any playbook available for it (Demisto).
The project attempts to fill this gap by providing a simple way to configure the playbooks: just modify the actions and the reliability for a particular finding type in the config.json file and it will change the execution behavior.
Note: The actions are only executed if the sum of the reliability and the severity specified in the Finding JSON is higher than 10. This means that, since by default all findings types have a reliability of 5, only findings with a severity of 6 or higher will trigger the actions execution.
Once a playbook gets executed, you will be able to review the logs produced by the Lambda in a separate CloudWatch log group, so that you can review which actions were executed and/or send them to your log management solution of choice:
Note that GuardDuty correlation is not real-time (and neither is the CloudWatch Event Rule, although the delay in this case is just a matter of a few minutes): AWS might take even hours to generate the findings and it could initially generate a lot of false positives, although I think that once GuardDuty estabilishes the baseline of your network the quality of the findings will drastically improve.
Of course this tool is not meant to be the final solution to all your cloud security problems but you might find it useful as a last resort when everything else failed, to disable a compromised account that is deploying cryptominers into your environment using leaked API keys or prevent a data exfiltration ongoing by quarantining an EC2 instance.
I put a lot of effort in making the deployment process as simple as possible, just clone the repository and run the deploy.py script and everything else will be taken care of.
Please let me know your feedback or if you find any bugs, thank you!
Subscribe to SIEM Detection
Get the latest posts delivered right to your inbox