Guard on Duty

Some Fun Now

Now that you have enabled GuardDuty and created some threat lists (Figure 3), you can start building instances as a playground. To get some attention from the bad guys out there, I'll start with an Amazon Linux EC2 instance with its security group configured to allow SSH to 0.0.0.0/0.

Figure 3: Activated threat lists.

If you do not want to wait until a bad guy hits your endpoint, you can add your home public IP into one of the threat lists to generate findings quickly. After waiting for around 20 minutes, I got a hit from a malicious IP; looks like people from the Internet are scanning open ports and trying to get into any network. For now, it is nice to see how GuardDuty triggers a finding (Figure 4). This specific "finding type" is UnauthorizedAccess:EC2/MaliciousIPCaller.Custom , but I'll give more details later on the distinct types available.

Figure 4: A malicious IP from the list named IPs.txt.

Another way to speed the trigger of a finding is by creating a CloudTrail trail from the console and then stop it. GuardDuty will generate a finding type Stealth:IAMUser/CloudTrailLoggingDisabled .

It would be interesting to see whether GuardDuty is able to identify a Kali Linux instance, which is a popular penetration testing tool used by security professionals to perform security checks and attackers to wreak some malicious havoc. I launched a Kali instance from AWS Marketplace, and soon I got another finding; this time it is PenTest:IAMUser/KaliLinux (Figure 5).

Figure 5: Kali Linux finding.

Other types of findings can include port scan activities and geolocation (when an IAM user that normally logs in from one place suddenly logs in from another country), for which you can see machine learning in action. Algorithms that detect those behaviors include inspecting signal patterns for heuristics and profiling common behaviors to look for some deviations.

The previous examples have revealed a couple of finding types, but many more fall under the categories shown in Table 1.

Notification and Security Alerts

As you progress with GuardDuty and play with its graphical interface to get more familiar with all the features, you might think the tool would not scale well for a medium or enterprise company if you do not completely integrate with other tools. For instance, you would like to have GuardDuty send logs to a SIEM system for centralization and correlation with other data sources; also, you want to be informed about any malicious activity, or you need to create some actions that trigger on findings. Once the data is ingested by your SIEM tool, you can start creating security alerts and dashboards. You have the option to select findings by severity, category, target account, instance ID, or any other interesting field.

If your company does not have the budget to maintain a tool like a SIEM system, you can always use email as the preferred method to send notifications whenever GuardDuty finds something. For this use case, you might employ a straightforward method that uses AWS CloudWatch Events or Amazon EventBridge with the combination of a Simple Notification Service (SNS) topic to send the notifications to an email inbox. I'll look at both methods.

If you want to implement something simple and economical, you must log in to your AWS account, navigate to the Amazon SNS console, and choose Topics . In the Create topic section, enter a name and a description and click Create subscription . For Protocol , select Email , and in the Endpoint textbox, enter the email address that you want to receive the notifications. You must confirm the subscription by email.

Next, navigate to Amazon EventBridge, click Rules | Create rule and again enter a name and description. In the Define pattern section, choose Event pattern and select Pre-defined pattern by service and AWS as the Service provider . For Service name , type GuardDuty and select GuardDuty Finding as the Event type (Figure 6). The goal is to have any detected findings send notifications to the inbox of the email address specified earlier. You could customize to specific findings, but in this exercise, I notify for all.

Figure 6: Amazon EventBridge configuration.

After saving the event pattern, the last thing you need to do is select the Target , which is the SNS topic created earlier. In the Configure input options, select all matched events. If you want to be more selective, you must choose to create an input transformer of the data, so only the fields entered would be sent by email.

Everything is ready to receive a notification with findings, but this could sound a little basic, so those companies that have the luck to own their own SIEM system have a number of possibilities to do more complex stuff with this data.

Ingesting GuardDuty Logs

Many SIEM systems, either commercial or open source, are in the market. I'll focus on Sumo Logic, but the same would apply to others like Splunk, QRadar, ArcSight, Elasticsearch, and many others. The concept for any SIEM system is always the same: Provide at a glance a collection of events and logs, normalize the events for field mappings, convert the logs into user-friendly data, correlate with different sources (e.g., firewall data, etc.), report and alert, and last but not least, log management functions.

First, you have to get the data into Sumo Logic, and for that, you follow a similar approach as for the email notifications; however, this time you'll use the AWS Lambda service, which is a serverless application.

In Sumo Logic, you first need to create a Hosted Collector for the HTTP source, which will be the endpoint to which you send those logs. In Splunk, it is called an HTTP Collector. Once it is created, you must copy the endpoint URL provided, because you will need it for the next step. GuardDuty log format requires you to change the format for the timestamp (Figure 7).

Figure 7: Parsing of Sumo Logic timestamp.

The next step is to go to the AWS Serverless Application Repository, search for sumologic-guardduty-events-processor in the Applications searchbar, and select it in the left panel. Scroll down a bit until you see Application settings ; paste the HTTP endpoint you copied earlier when you created the Sumo HTTP collector and click the Deploy button at the bottom of the screen.