AWS Logging and Analysis - Part 8.1 - Intro to AWS GuardDuty and GuardDuty Findings

Hi folks!!!

Its been a long time. I haven't posted anything here. A little busy, I was learning a lot of new things here and there about technology and trends in IT.

In this post, We will be discussing about Amazon GuardDuty for continuous security monitoring of AWS resources and workloads.

We all are aware of AWS CloudTrail. For those who don't know about CloudTrail, I would like to explain in short. CloudTrail is an auditing service in AWS which records all the API calls by default. These records, or more appropriately, logs generated by different AWS resources are in millions or trillions for large applications. This makes it a not so easy task to analyze logs for unauthorized activity, unusual infrastructure deployments, or unauthorized access to your accounts. For more information, do visit my previous posts in this series.

Amazon GuardDuty is a solution to this problem which provides a continuous security monitoring service across all AWS resources. Amazon GuardDuty analyzes and processes data from log sources such as VPC Flow Logs, AWS CloudTrail event logs and DNS logs. Amazon GuardDuty does it all using machine learning algorithms and anomaly detection. All we have to do is, just ENABLE it.

Any unexpected malicious activity in AWS account, activates GuardDuty to generate GuardDutyFindings on the Findings page accessible via Console or we can analyze them via CLI/API as well.

Lets enable AWS GuardDuty for further analysis.

Note: The agenda of this article is not to cover complete GuardDuty service rather to see how can we gather/collect GuardDutyFindings for logging and security incidents.

1. Click on 'Services' DropDown and select 'GuardDuty'. A new window will be opened. Click on 'Get Started'.

2. We can set the GuardDuty ServiceRole Permissions for looking into the AWS Resources. By default, we can see EC2:DescribeInstances and  EC2:DescribeImages. Further, note that Trust relationship of sts:AssumeRole is provided to GuardDuty.

 3. Now, Click on 'Enable GuardDuty' and you can see different options at left pane as Findings, Settings, etc. From here, GuardDuty is enabled. But, initially the panel will be empty and as the workloads run, we can see the Findings.

 4. To capture GuardDuty Findings, we first need to generate some findings and AWS has made some sample GuardDuty Findings for our convenience. Just go to settings, and click on 'Generate Sample Findings'

5. Around 42 sample findings will get generated in this single click. Post that, we can analyse the attributes of sample findings.

6. A reconnaissance event for an IAM User. It has a unique Finding identifier with attributes like severity, regions, cause, accountID, resourceID, etc. This all information has immense importance and needs to be stored at the time of any security incident.

7. Create a SNS Topic - GuardDutyFinding to notify the security team in case of security incident.

8. Now, Configure a CloudWatch Rule which directly sends the JSON payload of crucial security incident to the SNS topic configured. Select the event pattern for GuardDuty service as provided in the image below.

9. Once the rule is configure successfully. Go to the GuardDuty Settings to generate sample findings again. And this will hit the SNS to send the JSON payload to your subscribed mail.

This is how we can send a security notification for GuardDutyFindings via SNS. We can also create  a Lambda Target for CloudWatch Rule to further refine the AWS Config actions as done in previous articles. Most companies will log these events in a separate CloudWatch Logs LogGroup to connect with QRadar, Splunk, etc. for SIEM Analysis.

Note: Please disable GuardDuty if enabled following this article. Post 30 days trial, it will start incurring charges depending upon the region.