Best Practices for Amazon GuardDuty | Dash Solutions

Amazon GuardDuty is a threat detection service provided by Amazon Web Services (AWS). Threat detection is a cybersecurity practice that continuously monitors a system for malicious activities and generates alerts and security events. With GuardDuty, teams can monitor AWS resources and receive alerts and notifications around potential threats. Security teams respond to these notifications and take preventive actions to protect your infrastructure and AWS cloud resources. This article describes a set of best practices that will help you to develop a robust threat detection solution using GuardDuty.

How GuardDuty Works

Before diving into the best practices, we must understand how GuardDuty works and detects threats.

A threat detection service depends on logs and traces for monitoring a system. For GuardDuty, logs and events are provided by AWS CloudTrail, VPC Flow Logs, and DNS Logs. CloudTrail records all actions performed on your AWS resources either via CLI, GUI console, or the AWS API. VPC Flow Logs captures and records information about the IP traffic traversing through network interfaces. AWS Route 53 which is the DNS service from AWS, generates DNS Logs when your EC2 instances use Route 53 for name resolution.

GuardDuty implements a complex internal ruleset to analyze these logs and traces to identify threats. As an AWS user, you do not need to be concerned about these internal rules as AWS fully takes care of that complexity. However, when relying on GuardDuty, your team must consider certain configuration and operational settings. We are going to discuss these considerations in the best practices below.

#1: Ensure Full Detection Coverage

As we already mentioned, GuardDuty uses logs from AWS CloudTrail, VPC Flow Logs, and DNS Logs to detect threats.

When you enable GuardDuty, it automatically starts analyzing data from all of these data sources. Amazon GuardDuty pulls independent streams of data directly from these services, allowing your team to get up and running quickly.

CloudTrail is automatically enabled when you create an account in AWS and will log all management events which are also known as control-plane events. CloudTrail will log operational activities on your AWS resources such as creating a new EC2 instance, attaching a new policy to a user, or creating a new subnet, etc. Logs of these operations will be automatically available to GuardDuty without additional configurations in CloudTrail.

However, VPC Flow Logs which monitor IP packets transferred between EC2 instances can be enabled for a VPC, a subnet, or each network interface in a subnet. If VPC Flow Logs are configured for only a subset of your network interfaces, GuardDuty will not get full visibility of your VPC traffic. Your team must ensure that VPC Flow Logs are enabled for all regions and required interfaces that you plan to monitor for threats. Dash ComplyOps can help your team configure security settings and monitor cloud configuration including logging and intrusion detection settings.

AWS Route 53 logs are generated whenever an EC2 instance queries Route 53 service for name resolution. If you configure Google DNS or any other external DNS server address as the nameserver in an EC2 instance, the DNS queries form that EC2 instances will not be logged in Route 53. So, GuardDuty will not be able to analyze DNS queries from that instance. Your team may consider using AWS Route 53 with EC2 instances for name resolution and further events in GuardDuty.

#2: Enable CloudTrail S3 Data Event Monitoring

In addition to the management events described above, CloudTrail is able to collect events for S3, are known as S3 data events.

CloudTrail automatically accounts for management events in S3 including operations on S3 buckets such as `ListBuckets` or `DeleteBuckets`. But, operations such as `GetObject`, `ListObjects`, and `DeleteObject`, which are performed on objects stored inside buckets are may be enabled through CloudTrail S3 data events.

When you enable GuardDuty it will start monitoring CloudTrail management events, but monitoring of CloudTrail S3 data events will not be enabled by default. You must manually configure CloudTrail S3 data events as a data source in GuardDuty. This can be configured from the GuardDuty console or the API. After this setting is configured, GuardDuty will start monitoring S3 data events for potential threats.

#3: Enable GuardDuty For All Regions

While your team may be running your workloads in only in a limited number of AWS regions, you must enable GuardDuty for all regions, for complete threat visibility.

When GuardDuty is enabled for all regions, it can detect unintended activities in unused regions also. As an example, a malicious user may deploy a new EC2 instance in a region that you have never used. GuardDuty can detect and alert you for such incidents when it is enabled for all regions.

#4: Secure Access To GuardDuty With IAM

Amazon GuardDuty, like all other AWS services, integrates with AWS IAM for authentication and authorization. Since GuardDuty is important for the security of your resources, you must ensure that access to GuardDuty is restricted to specific users only. Also, you must grant separate permission to users and administrators of the GuardDuty service.

Organizations must determine which services and resources are required by the users who are using GuardDuty and grant them access according to their job role. Security teams may consider defining a team member to operate as the GuardDuty administrator to manage and resolve GuardDuty findings within your organization.

#5: Grant Least Privileges

Granting least privileges ensures that a user has only enough permissions to execute the tasks he or she is required to do. It can prevent human errors and also limits what an attacker can do, in case the user account is compromised.

GuardDuty supports AWS IAM identity-based policies. Identity-based policies are attached to an IAM identity such as a user or a group. These policies grant permission to users to perform certain actions on an AWS resource.

By default, your IAM users will not have any permission to manage GuardDuty resources. When starting with GuardDuty you must grant permissions starting with least privileges. Then, you can incrementally grant privileges as and when required by attaching more policies.

#6: Analyze GuardDuty Activities With CloudTrail

As much as GuardDuty helps detect threats, you must ensure that no users are tampering with GuardDuty either unintentionally or maliciously. You can do this by monitoring the CloudTrail events about GuardDuty.

As described previously, CloudTrail logs all operational activities on AWS resources. By default, these logs are stored for 90 days and you can view them in the CloudTrail console. You can do further analysis of these logs by creating trails within CloudTrail. Creating a trail lets you send events to CloudWatch for monitoring and running queries on logs with other services such as AWS Athena.

So as a best practice you must create a trail for GuardDuty in CloudTrail and closely monitor all user activities on GuardDuty.

#7: Automate Risk Mitigation With CloudWatch and Lambda

GuardDuty generates a finding when it detects a threat. A finding is a potential issue that may demand certain actions to mitigate the risks. You can view the findings in the GuardDuty console and then can take action for each finding.

However, as your team manages large cloud environments with more resources, manually analyzing and addressing findings in GuardDuty can become more difficult. Your security team may consider looking for opportunities to automate risk mitigation. Integrating GuardDuty with AWS CloudWatch Events and Lambda provides team with a great way to automate this process.

GuardDuty can generate CloudWatch Events for each finding. Your team can create rules/filters in CloudWatch to trigger AWS Lambda functions for different types of events. By connecting CloudWatch Events from GuardDuty to Lambda functions, your team can write code to automatically take corrective actions for each type of GuardDuty finding.

As an example, if a finding indicates that an EC2 instance is communicating with a suspected IP address, a Lambda function can be triggered to stop the instance and generate an alert for further analysis. Security teams should consider automating GuardDuty events for relevant event types.

#8: Integrate GuardDuty with AWS Security Hub

In addition to GuardDuty, AWS has other cybersecurity services such as AWS Config, Amazon Macie, Amazon Inspector, AWS Firewall Manager, etc. AWS Security Hub can integrate with all these services including GuardDuty to provide you with a comprehensive view of your security status.

AWS Security Hub can also aggregate security findings from various services including GuardDuty. By integrating GuardDuty with Security Hub, you get to observe your security findings in a more holistic manner than monitoring individual services separately.

#9: Use Suppression Rules To Archive Unnecessary Findings

After enabling GuardDuty, you can view findings in the GuardDuty console. Some of these findings could be false positives where they do not represent actual threats. To clear out any clutter, you can use suppression rules so that certain findings are not displayed in the console.

Suppression rules allow you to filter findings by finding type, specific AWS resource, or more granular criteria such as IP address, ports, etc. Once you create a suppression rule, the finding will not be displayed on the GuardDuty console. This finding is archived and stored in GuardDuty for 90 days.

It is recommended to create suppression rules incrementally instead of creating them upfront. You should monitor your findings and create rules to suppress specific findings that add noise to your security process. This will ensure that you do not suppress real threats with suppression rules.

#10: Configure A Trusted IP List

A trusted IP list is a list of IP addresses or subnets you can define in GuardDuty so that GuardDuty does not generate findings for trusted IPs. This can be useful in a hybrid cloud architecture where your EC2 instances are frequently communicating with certain on-premise resources. You can trust these on-premise IP addresses, by defining a trusted IP list in GuardDuty. Creating a trusted IP list can help your team reduce some noise and false positives created in GuardDuty findings.

Conclusion

Threat detection is an important aspect of cybersecurity. The best practices described above will help you build a robust threat detection solution with GuardDuty for your resources in AWS.

Teams managing AWS infrastructure may turn to a solution such as Dash ComplyOps to simplify security and compliance operations. Dash provides teams with a robust solution for configuring best security practices and enforcing compliance standards such as HIPAA and SOC 2 across AWS environments.