Cloud environments, particularly infrastructure as a service, can be challenging to secure -- especially from a...
monitoring point of view.
There are a few reasons why this is true. First, as enterprises share responsibility for operational security oversight with a service provider, many of the technical controls that already help monitor and defend devices in an on-premises environment may not have full -- or any -- visibility into cloud environments. As anyone who has tried to do it can tell you, tying something like a legacy SIEM, for example, to a commodity public cloud environment can be kludgy at best and impracticable at worst.
The second reason why cloud monitoring can be challenging is that the techniques enterprise IT uses to bolster monitoring sometimes operate differently in the cloud. For example, many shops have invested in a threat intelligence capability to help keep abreast of attacker motivations and tradecraft. The cloud can change how they might attack.
For example, consider an attack technique like Flip Feng Shui -- it's potentially devastating for a multi-tenant, infrastructure-as-a-service environment, but much less of a big deal for something like an on-premises hypervisor in a virtual data center.
This is important because, even when security teams can monitor cloud assets -- which itself is not a given -- what they look for sometimes varies in ways that can make monitoring more complicated and attacks harder to detect.
What is Amazon GuardDuty?
In response to this challenge, cloud service providers have been expanding the functionality they provide to help customers monitor for and remediate attacks, and to ensure the continued appropriate operation of workloads in the cloud. One such service, announced by Amazon at re:Invent in 2017, is Amazon GuardDuty.
Amazon GuardDuty is a threat detection and monitoring tool for Amazon Web Services (AWS). It analyzes -- and warns enterprises about -- events that could impact services running in the AWS environment. It does this by analyzing observed behavior against both Amazon-developed and third-party best of breed threat intelligence data, in combination with machine learning-enabled observation of events in aggregate that looks for possible attack scenarios or indicators of compromise.
Consider what happens when an instance hosted by AWS is observed conducting an attack against another party, or when a host exchanges data with a known bad actor -- like a malware server or botnet -- over a suspicious command-and-control channel. Amazon GuardDuty is designed to recognize scenarios like these as suspicious, flag the events as such, alert an administrator and -- assuming is it configured to do so -- channel those issues into automated remediation tools, workflow tools or other back-end systems that support security within the organization.
It does this without consuming additional customer-visible resources. Meaning the user doesn't have to specifically configure various data sources -- such as AWS CloudTrail, Amazon Virtual Private Cloud Flow Logs and AWS' Domain Name System -- to see the benefits.
Likewise, while Amazon GuardDuty is, itself, a costed service -- something that enterprises pay for based on the volume of usage -- it can offer some economic advantages compared to alternatives that rely on on-host software, like an agent or virtual tap that utilizes CPU and storage resources. This pricing enables the customer to better understand the cost of the service ahead of time compared to alternatives, and to budget accordingly.
Integration into a security program
This functionality makes Amazon GuardDuty a potentially valuable tool for cloud customers. It is by no means a panacea on its own, but it nevertheless can be a useful instrument when used in combination with other detective controls and processes that might already be in place.
For the astute practitioner, the question becomes how to best integrate this functionality to receive the full benefit. Doing that isn't rocket science, but it does involve a bit of legwork.
Amazon GuardDuty can be integrated with other tools that might already drive the workflow: SIEM tools, workflow management tools, remediation tools, etc. This is perhaps a more critical feature than it might seem on the surface in terms of practical usage. Why? Because individuals who log in to the AWS console are rarely those with operational security oversight.
Consider how many different cloud environments might be in play; chances are good that the users logging into these on an environment-by-environment basis aren't the same users who will find the data most valuable. Therefore, integrating the information coming out of GuardDuty with the workflow and processes the users already follow makes it easier for them to consume, and it doesn't require re-engineering existing processes.
It's important to recognize that just turning on Amazon GuardDuty won't immediately absolve enterprises of the need to monitor logs and other information coming out of AWS. The service does pull from data sources like CloudTrail and other monitoring channels, but those who want or need the CloudTrail data still need to build a plan for consuming that, and that plan should exist independently of the information gathered from GuardDuty.
The last thing to keep in mind is that, while GuardDuty does enable enterprises to use their own threat intelligence data, such as IP blacklists, the service does not enable enterprises to write their own rules, regular expressions, or other purpose-built custom analysis functionality as a dedicated on-premises solution or virtual appliance would. If you are looking for a particular attack pattern that is specific to your organization's assets, this feature may not help.
As you might expect of any cloud service, though, the barrier to entry is fairly low. Not only is there a trial period to let you kick the tires, but you can also populate the console with pregenerated events to observe the types of alerts that it will generate and familiarize yourself with the service.
At the end of the day, Amazon GuardDuty can have a place in an organization's security program. For a large organization, it is a natural supplement to existing monitoring controls -- particularly when integrated into existing remediation and incident escalation processes. For a smaller organization, the advantages may be more pronounced as it incorporates threat intelligence information that a smaller shop might not have ready access to.
Because it can be enabled rapidly and pricing is based on the volume of information processed, this can be a big step up for the smallest and leanest organizations that might struggle to achieve similar outcomes without it.