En Garde!

GuardDuty is a sophisticated threat intelligence tool offered by AWS as a specialist service that takes care of ever-evolving infrastructure attacks [1]. In this article, I show you how to enable GuardDuty on AWS through Infrastructure as Code with HashiCorp's venerable Terraform [2] and look at the type of alerts it stands guard and looks out for. Minus a third-party application ingesting the resulting alerts into a security operations center (e.g., Splunk), I'll demonstrate an end-to-end DevSecOps solution.

Cloud technologies have brought a number of significant advances in the ways we create and maintain Internet infrastructure. Coupled with DevOps practices, which help expedite application software releases, the tools in use today are a million of your Earth miles from the tools of yesteryear.

As part of the cloud's innovation, Amazon Web Services (AWS) brought to the fore utility computing , or Pay as You Go. In addition to the speedy, dynamic creation (and destruction) of resources, flexible billing, and the Infrastructure-as-a-Service (IaaS) model from AWS, do not forget the continual blessing of new features and services by the bucket load (pun intended). Some of these cloud services fall by the wayside and are quietly deprecated, and some create a significant new revenue stream for AWS.

In the same way that data centers need security monitoring, these new-fangled cloud services still present the time-honoured issue of tracking who is attacking your online resources, with a very real need to gain an insight into the attackers' targets.

Dive, Dive, Dive

AWS describes the key features of GuardDuty as "… a threat detection service that continuously monitors for malicious or unauthorized behavior to help you protect your AWS accounts and workloads. It monitors for activity such as unusual API calls or potentially unauthorized deployments that indicate a possible account compromise".

Security professionals have long known that reconnaissance plays a vital part in an attacker's work. To my DevSecOps mind, GuardDuty offers a valuable insight into such recon activities, along with the ability to help detect compromised Elastic Compute Cloud (EC2) server instances.

Security as Code

Machine learning (and less user input) is the future of computing. AWS removes the pain of handling endless rulesets related to your security and puts its foot down firmly when it comes to GuardDuty. AWS simply denies you the ability to have any control over your rulesets. Thankfully, you don't have to worry about any admin overhead.

Because no additional logging storage conduits or service configuration is required – simply some Identity Access Management (IAM) service roles that GuardDuty happily creates for you – you also don't have to worry as much about data leak protection (DLP) if your storage/access permissions are incorrect on AWS Simple Storage Service (S3) or CloudTrail, which could result in your security metrics suffering a humiliating public leak. In other words, behind the scenes, AWS configures all the plumbing automatically for you to ensure and bolster your GuardDuty configuration. It's a genuinely simple, yet highly sophisticated service offering.

Uncle Buck

Another pleasant surprise is that GuardDuty won't break your bank: Pricing follows the familiar AWS utility computing model, as seen in Figure 1 for the US East (North Virginia) AWS region. As the figure demonstrates, much of the cost depends on how much traffic is moving between your virtual private cloud (VPC) logs and how many "events" are reported by the intelligence feeds that GuardDuty uses, which means a busy server estate pays more than a quiet one.

Figure 1: Costs in the US East (North Virginia) AWS region as an example of GuardDuty pricing [3].

A number of pieces of plumbing come into play with GuardDuty. Much of its innards are set up automatically when you switch GuardDuty on. For example, behind the scenes, AWS takes away some of your pain by giving the GuardDuty service just enough rights to query other AWS services (e.g., EC2 instances) to glean what's required to run GuardDuty properly. The IAM role allocated to this task, called AWSServiceRoleForAmazonGuardDuty (Listing 1), is automagically assigned to your account when a GuardDuty instance (or detector) is enabled [4].

01 {
02   "Version": "2012-10-17",
03   "Statement": [
04     {
05       "Effect": "Allow",
06       "Action": [
07         "guardduty:*"
08       ],
09       "Resource": "*"
10     },
11     {
12       "Effect": "Allow",
13       "Action": [
14         "iam:CreateServiceLinkedRole"
15       ],
16       "Resource": "arn:aws:iam::XXXXXXXXXXX:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty",
17       "Condition": {
18         "StringLike": {
19           "iam:AWSServiceName": "guardduty.amazonaws.com"
20         }
21       }
22     },
23     {
24       "Effect": "Allow",
25       "Action": [
26         "iam:PutRolePolicy",
27         "iam:DeleteRolePolicy"
28       ],
29       "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty"
30     }
31   ]
32 }