Organizations, no matter the size, should implement infrastructure for preventing, detecting, and responding to security incidents. In this article, I focus mainly on detection with an AWS-native tool called GuardDuty [1], which sends its findings to a security information and event management (SIEM) system to generate and correlate security alerts to which analysts can react.

Cloud Dangers

One of the principal concerns many companies still have when migrating their assets to the cloud is security and compliance, even though cloud services now take this topic seriously. Cloud vendors have done a brilliant job marketing their security technology as the best and most sophisticated; however, data breaches happen frequently, and bad actors are targeting those large cloud providers.

Securing an on-premises data center is slightly different from securing your assets in the cloud. What is the definition of the cloud? Many would say someone else's computers, but in reality, it is so much more complex than that, although it is true that pure cloud computing involves leasing infrastructure resources from a service provider.

Both models have advantages and disadvantages and likely neither is perfect, so you must carefully choose which model you use depending on the level of security you need for your business. No matter how "big" the cloud provider, the shared responsibility model would be similar.

According to Amazon Web Services (AWS), they are responsible for protecting the underlying infrastructure that runs all of the services offered. This infrastructure comprises the hardware, software, networking, and facilities that run AWS Cloud services, including physical controls. Customers are responsible for the rest of the security controls. For example, the famous Capital One hack happened because of a misconfiguration of the web application and not the underlying cloud-based infrastructure. Other data breaches have occurred because a Security Group was not configured properly.

As a data or application owner, you must protect your company assets, because no one will care more than you or do the job better. Keep in mind the on-premises model – for which you need to take care of the firewall, anti-malware and antivirus defenses, security logs, and other fancy tools – for proper configuration when leveraging cloud-native tools.

GuardDuty

The substantial thing about GuardDuty is that you can have a decent intrusion detection system up and running in less than 15 minutes. In this article, I walk you through enabling the tool, configuring notifications and security alerts, and showing you different ways to bypass detection. Later, I'll also demonstrate how to create threat intelligence, but first, I'll look at what GuardDuty is and what it can do for you.

GuardDuty is an AWS managed service that uses machine learning capabilities to detect unauthorized and unexpected activity in your AWS environment (Figure 1). It detects anomalous behavior, extracts some fields, and finally discards them by analyzing the following logs:

• CloudTrail event logs: Of the two types – management and data events – GuardDuty analyzes only management logs, which are essentially API calls for your account, either through the AWS Management Console, the AWS SDKs, or the AWS command-line interface.
• VPC Flow Logs: These network logs provide visibility into all traffic going to and from Amazon EC2 and are configurable at the virtual private cloud (VPC), subnet, or network interface level. Metadata includes some interesting fields, like source IP, destination port, destination IP, account ID, protocol, and so on.
• DNS logs: An EC2 instance will use a default DNS resolver, for which Amazon has reserved an IP address that ends in 2 (e.g., 192.168.1.2 or 172.16.1.2). However, if you change the default configuration and add a third-party DNS server (e.g., Google, 8.8.8.8), GuardDuty cannot analyze the DNS logs.

Figure 1: GuardDuty monitoring solution at a glance.

Apart from enabling those logs, no other configuration needs to be performed on the GuardDuty side; it will just analyze the logs and trigger findings.

One great and very useful feature is the ability to upload your own threat list. I'll show you how to configure a malicious IP threat list later, but first you have to enable GuardDuty.

Enabling GuardDuty

When you log in on the AWS console and type the magic word GuardDuty in the search bar, you land on the Get Started page.

Note that when you enable GuardDuty for the first time in your account, you have a 30-day free trial, so it is an excellent time to play with the tool and become familiar with the look and feel. The pricing model is based on the quantity of CloudTrail events analyzed and the volume of VPC Flow Logs and DNS logs (per gigabyte). However turning on logging for those services is not required for GuardDuty to work. Please consult the most up-to-date information about volume discounts on the AWS GuardDuty website [2].

You must enable logging in all supported regions on your account. Yes, I know that hurts, but if something happens in a region that is not enabled, you miss the incident detection.

If you are working with AWS Organizations, you can nominate one account as the organization's delegated administrator for GuardDuty, so it becomes the primary (master) account automatically. With the primary account, you enable GuardDuty for any account in the organization and then add that account as a member account.

If you work with several accounts but do not use AWS Organizations, you still have to assign a primary account and then send invitations to member accounts. You just need to know the email address of the root target account and the account ID. Later, you can always add the primary account to the organization, allowing you to take full advantage of the added functionality of managing your GuardDuty accounts with AWS Organizations.

If your Identity and Access Management (IAM) user has administrative permissions into the account, click the orange Enable GuardDuty button. If that is not the case, and you would like to configure more granular permissions, you can always attach a policy (Figure 2) to an IAM user, group, or role. Take into account that GuardDuty will auto-assign itself the role AWSServiceRoleForAmazonGuardDuty to analyze the logs and generate findings.

Figure 2: This policy document grants permissions to enable GuardDuty.

If some instances expose ports like 22 or 3389 to the world (0.0.0.0/0), you should soon see some findings of malicious IPs trying to get into your systems. GuardDuty threat intelligence findings are based on feeds from third-party vendors CrowdStrike and Proofpoint, but you can add your own custom threat intel feeds, as well.

Currently, GuardDuty only supports IP-based threat lists. Two of my favorites are Tor exit nodes [3] and Open Threat Exchange (OTX) community feeds from AlienVault [4], but you may find some others by just doing some research. The lists are dynamic, so if you want GuardDuty to refresh automatically, you must create some automation scripts or lambda function to grab the source and copy to an S3 bucket with a TXT, CSV, or XML extension.

Formats supported by GuardDuty are STIX (XML) and CSV. If you join the community, you can download pulses that include indicators of compromise (IOCs) in IPv4 address range format, file hashes, file names, and malicious URLs. If you create a threat list in plaintext, IP, or classless interdomain routing (CIDR) format, ranges must be presented one per line, and you have to select Plaintext as the format. It is important to know that all these files need to be in an S3 bucket to which GuardDuty has access, but the good news is that a policy for permissions into S3 is granted automatically once you create a new threat list.

On the main GuardDuty console in the navigation pane under Settings , choose Lists and add a threat list. You can create a maximum of six lists per AWS account per region. Once you successfully upload the list, you must activate it by selecting the checkbox next to it. Now you are ready to have some fun.