Locking down an AWS environment isn’t really that if you know what threats you’re protecting against. You have services such as the Web Application Firewall, Security Groups, Network Access Control Lists, Bucket Policies and the list goes on. But many times you encounter threats from malicious attackers just trying to probe which vulnerabilities might exist in your cloud. AWS has built a service, called Amazon GuardDuty, to help monitor and protect your environment that is based on AWS machine learning tools and threat intelligence feeds. GuardDuty currently reads VPC Flow Logs (used for network traffic analysis) and CloudTrail Logs (used for control plane access analysis) along with DNS log data to protect an AWS environment. GuardDuty will use threat intelligence feeds to alert you when your workloads may be communicating with known to be malicious IP Addresses and can alert you when privileged escalation occurs as part of its machine learning about suspicious patterns.

At this point you’re probably thinking that Amazon GuardDuty sounds like a pretty useful tool but have two big questions: How much does it cost? How difficult is it to use?

Pricing

Amazon GuardDuty is a fairly new service and that comes with some benefits. Primarily, this gives you a 30 day free trial on your usage of GuardDuty on a new account. This gives you an opportunity to kick the tires before you decide to start paying for it for real. One of the things I really like about this trial is that the console will show you exactly where you are at during the trial period and how much it would cost if you weren’t in a trial period.

OK, so what are the prices after the trial period ends? Well just like most services it varies based on your region. If you’re in the us-east-1 region you can expect to pay about 1$ per GB of VPC Flow logs that are analyzed up to 500 GB. After that the price falls to $.50 per GB for the next 2000 GB and then the price falls again to $.25 from there after. Like most services the prices drop based on the volume. For CloudTrail log analysis you’ll expect to pay $4.00 for 1 Million CloudTrail requests.

As you can see the pricing is pretty reasonable. In a small environment or lab, you’ll probably expect to pay a couple bucks per month for the service while a larger environment obviously will pay more, but probably worth it for the added security it would bring to a production workload.

Setup GuardDuty

OK, so you’re sold on how Guard Duty works, and cool with the pricing. But machine learning and thread intelligence sounds tricky to manage. How hard is it to setup? First, lets take a look at setting this up through the console.

Go to the Amazon GuardDuty service from your list and you’ll get the familiar “Get started” screen since you’ve never set it up before. Click the “Get started” button.

On the first screen, you can view the role permissions, but if you’re good with those click the “Enable GuardDuty” button at the bottom right hand corder of the screen.

Well, that’s it. You’ve enabled GuardDuty and it can help protect you now. This does assume that you’ve setup VPC Flow logs and CloudTrail logs for your environment already but CloudTrail for example is now enabled by default. You did it!

From here, you can look at any findings that GuardDuty came back with. Initially, you won’t have any, but as time goes on GuardDuty will list potential issues in this screen so that you may take actions on them.

Additional Configurations

So if you want to do some more optional configurations you can look at the GuardDuty portal and configure some of your own things. First, if we look at the lists menu within GuardDuty, you can add a trusted IP or a threat list for unwanted traffic. Maybe you want to make sure to whitelist your corporate networks, or add known bot networks to a threat list for notification.

If you have a multiple account environment, you can setup GuardDuty to use Master and Member account relationships. For instance maybe you have an AWS Security account used for logging, patching, authorization and other security related solutions. Maybe this account gets setup as a Master GuardDuty account and your other accounts are Member accounts. This lets those Member accounts send their GuardDuty data to a single account where it can be analyzed across all your environments.

If your just dying to learn what kind of things might show up in your findings window, you can force sample findings to show up. This will put 1 entry for each type of finding in your findings pane with a [SAMPLE] tag so you know it isn’t real.

Once you’ve added the sample findings, you can click into each of them to get additional details such as the Portscan entry below.

Alerting and Auto Remediation

GuardDuty is pretty cool, but most people don’t want to continuously check on those findings. Luckily, CloudWatch Event rules can be integrated to take action based on a new finding. From the CloudWatch portal go to Events –> Rules and add a new source of GuardDuty and an Event Type of GuardDuty Finding. From there you can specify a target such as an SNS topic for email alerts, or a Lambda Function so that you can have a script auto-remediate your environment based on a finding that occurs.

Setup with CloudFormation

The GuardDuty setup with CloudFormation is also really simple. Below is an example of setting up GuardDuty with a new account and it also creates an SNS Topic and a subscription to that topic so that new findings are automatically triggering email notifications.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "GuardDuty with CloudWatch Event Rule and SNS Topic",


    "Parameters": {

        "Environment": {
            "Type": "String"
        },

        "EmailAddress" : {
          "Type": "String"
        }

    },

    "Resources": {

      "mydetector": {
        "Type": "AWS::GuardDuty::Detector",
        "Properties": {
          "Enable": true
        }
      },

      "GDSNSTopic":{
        "Type":"AWS::SNS::Topic",
              "Properties" : {
              "DisplayName" : {"Fn::Join": [ "-", ["GuardDuty", { "Ref": "Environment"}, "SNSTopic"]] },
              "TopicName": {"Fn::Join": [ "-", ["GuardDuty", { "Ref": "Environment"}, "SNSTopic"]] }
          }
      },

      "GDCWEvent": {
        "Type": "AWS::Events::Rule",
        "Properties": {
          "Description": "GuardDuty Event Rule",
          "EventPattern":
          {
            "source": [
              "aws.guardduty"
            ],
            "detail-type": [
              "GuardDuty Finding"
            ]
          },
          "State": "ENABLED",
          "Targets": [{
            "Arn": { "Ref" : "GDSNSTopic"},
            "Id": "TargetGuardDutySNSTopic"
          }]
        }
      },

      "GuardDutySubscription" : {
        "Type" : "AWS::SNS::Subscription",
        "Properties" : {
          "Endpoint" : { "Ref" : "EmailAddress" },
          "Protocol" : "email",
          "TopicArn" : {"Ref" : "GDSNSTopic"}
        }
      }
    }
}

Summary

Amazon GuardDuty is a pretty useful service to help to automatically find potential security threats within your AWS accounts. The price isn’t unreasonable and the configuration is incredibly simple for a powerful tool such as machine learning. Try it out for yourself, at least for 30 days of a free trial.