Security Automation at Dehaat — Part -1
In this three part series of Security Automation at Dehaat ,we would discussing about some of the automation ideas we have implemented to solve our day to day security problems . In this article we would be discussing about how we monitor the findings generated by AWS GuardDuty and notify these findings via slack.
Let’s begin with the boring part — the definitions, so what is GuardDuty?
GuardDuty is a threat detection service offered by AWS that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation.
To put it in a hard way, GuardDuty monitors logs like VPC flow logs, DNS logs, Cloudtrail event logs, and S3 event data and uses some kind of anomaly detection and machine learning algorithms to identify any malicious traffic. In case if it finds an anomaly, guardDuty creates something called a finding, this finding would contain different details such as :
- Resource Affected
- The Action which caused the trigger
- The threat Actor details.
Problem Statement → Devise an alerting mechanism for the findings generated by GuardDuty , which sends these alerts to slack .
We can approach the above problem statement in many ways, let’s explore how we could have solved this issue with the help of Multiple AWS services.
Approach -1
Ingredients Required
- AWS Event Bridge
- AWS Lambda
The above approach, uses AWS Event Bridge, to monitor guard duty events. We can create an event rule that listens for any guard duty event, in this case, we are interested in the findings. Event bridge already has a predefined event for guardDuty findings and we can utilize that event.
The next step here is to tell the action for the event, here we require the event to be sent as an alert to slack, but there is no direct integration of slack. So we need to create an AWS lambda function that uses this event as a trigger to send alerts to slack.
This approach can be easily set up, with a few clicks and some bit of code for the lambda function, but would this be a cost-effective way? No, we are using multiple AWS services here, there's a cost to it and remember GuardDuty itself comes with a hefty pricing.
That's why we wanted to follow a different approach that can help us to reduce the usage of multiple AWS services and also at the same time be effective.
Approach -2
Ingredients Required
- Boto3
- Slack API
- EC2 -( Assuming Every Security Team would have a dedicated instance )
Boto3 is an AWS SDK for Python, it allows you to directly create, update, and delete AWS resources from your Python scripts. We will be using the Boto3 GuardDuty client to fetch these alerts then parse the required details and send it to slack using the Slack API.
More Context to the above approach
- Python Script that uses Boto3 to fetch GuardDuty Findings details for the last 10 min.
- Fetched findings details are in JSON format and would require parsing the required data.
- The data parsed is sent to slack as a message using the slack API, which requires you to create a slack app and install it in the required channel for which the alerts are to be sent.
- The python script is then added to a cronjob that executes the script every 10 min. The cronjob runs in the EC2 instance.
The script
Link : https://github.com/Dehaat/devsecops/blob/main/AWS-Automation-Scripts/GuardDuty2slack.py
There are three main functions that are responsible for getting the guardDuty alerts from AWS:
- def get_detectorids()
- def get_findingids()
- def fetch_guard_duty_findings()
These three main functions use three different methods from the Boto3 GuardDuty client.
Detector IDs
When enabling guard duty, it automatically creates a detector id for the region you want to. You can have only one detector for one account per region. The bellow code snippet shows how you can fetch the detector from AWS using the boto3 method list_detectors().
Findings IDs
Every finding is indexed with an id called the findings id, in order to extract findings details we would require to fetch the findings id first. The below code snippet uses the list_findings method from boto3, which takes two arguments one is the DetectorId which we fetched using the last function and FindingCreteria which acts as a filter. Here we are interested in fetching only the findings generated in the last 10 mins, so we use the creteriaUpdatedTime that helps to achieve what we wanted. This function returns a list containing all the findings id.
Get Finding Details
Once we have the findings is now we can use the get_findings() method
from boto3 to fetch all the finding details. In this code snippet below we have defined a function called fetch_guard_duty_findings() which calls all the previous functions and then stores the finding details in a list.
The returned finding detail is in JSON format, from which we extract the required details to craft our slack message and then use the slack API to send the finding details.
{ "Findings": [{
"Title":"Unprotected port on EC2 instance",
"Type":"Recon:EC2/PortProbeUnprotectedPort",
"Region":"us-east-i",
"Partition":"aws",
"Arn":"arn:aws:guardduty:us-east-1:1234567",
"UpdatedAt":"2017-12-12T19:18:55.3297",
"SchemaVersion":"2.0",
"Severity": 2.0,
"Id":"bbbbccccddddeeee1234567890123456",
"CreatedAt":"2017-12-12T19:18:55.3297",
"AccountId":"123456789012"}]
}The below image is an example of the guardDuty alert generated via our script and then sent to the slack channel where the slack app GuardDuty-Alerts is installed.
In the next part of the Security Automation at Dehaat series, we would be looking into how we can automate the monitoring of Route-53 changes.
