AWS GuardDuty is on duty

Happy Monday everyone! Today I'd like to talk about AWS GuardDuty, a security monitoring service Amazon recently announced - last November to be specific.

Cybersecurity and security threats in general are main focus areas and/or concerns C-level executives have on their agenda. It's no surprise: companies get compromised day after day and with it comes the "wrong type" of media attention. Loss of customer data, sensitive customer data, account credentials, you name it! As always with cybersecurity you need the right people, processes and technology in place. AWS GuardDuty could help you with the latter to a certain extent...

AWS GuardDuty at your service

If you are using AWS I've got great news for you. Amazon has announced GuardDuty, a security monitoring and threat detection service for your AWS accounts and workloads. This service is an extension of the ever-growing services portfolio Amazon has to offer. It monitors your VPC Flow Logs, AWS CloudTrail events and DNS using external threat intelligence feeds - all built in and ready to alert you if something is not quite right...If you are paying for security threat intelligence feeds you can import those into GuardDuty which is quite nice.

All the threat monitoring logic (the "secret sauce") of identifying threats is managed by AWS automagically so you don't have to do it yourself. If you are not using CloudTrail events, VPC Flow Logs (you should) you don't have to worry about making any configuration changes. When you enable GuardDuty separate and idependent monitoring and analysis streams are configured for you. Also don't worry if you are already using those services. GuardDuty won't change anything in your configurations, your event monitoring policies, permissions and S3 bucket configurations are safe. If you are concerned about GuardDuty retaining your CloudTrail logs have no fear: GuardDuty analyzes your data in near real-time and discards it afterwards, no log data is retained. You don't have to install any agents either- in summary, Amazon has made it super easy to start using GuardDuty.

To get your feet wet there is a 30 days trial period available for every new account. Pricing is based on the quantity of AWS CloudTrail Events analyzed and the volume of Amazon VPC Flow Log and DNS Log data analyzed, for details check out the AWS GuardDuty pricing page at (https://aws.amazon.com/guardduty/pricing/)

Enabling GuardDuty is quite simple. You open up GuardDuty console and click on Get Started:
AWS_GuardDuty_Getting_Started

And then you click on Enable GuardDuty
AWS_GuardDuty_Getting_Started1

Please note the AWS GuardDuty is region specific and you need to enable GuardDuty in all the regions you use...actually, here is a great tip: just enable GuardDuty for all regions. Why? Well, first of all just enabling GuardDuty is free and more importantly it will allow GuardDuty to generate alerts about unauthorized or unusual activities even in regions that you
are not actively using! More on this later...

GuardDuty is (also) not a silver bullet

As you might have guessed: GuardDuty is not a silver bullet but it's a quite effective remedy to for a few IT security "headaches" and it's a worth addition to your defense in depth strategy. GuardDuty currently identifies 8 different threat categories and 34 different type of threats altogether at the time of the writing of this article. I expect this list to grow considering Amazon's pace of innovation. Case in point, when I enabled GuardDuty on my AWS account I've got the following message:
AWS_GuardDuty_Getting_Started2

This means GuardDuty is now capable of detecting domain generation algorithms - a common technique used to generate random looking domain names used by command and control (C&C) servers for botnets, ransomware and for a whole lot of other nefarious activities. I thought I'll give you a few examples and cases where you can benefit of GuardDuty monitoring...

GuardDuty to the rescue
Are your EC2 instances communicating over unusual ports or generating unusually high and unexpected volume of network traffic? These suspicious behavours could indicate compromise - the latter can also indicate a mild heart attack when you receive the monthly AWS bill :)

Are your EC2 instances communicating with known spam servers over port 25 or with known C&C servers? These GuardDuty alerts could indicate your EC2 instances are part of a big happy family of DDoS botnets or they are in the business of the still (unfortunately) lucrative business of spamming...regardless, you should investigate...

Are your EC2 instances mining bitcoin? If you are mining for your own benefit that's slightly different but if you are mining for somebody else I suggest you take a closer look.

Are your AWS accounts and password policies in order? If you see your password policy got changed for the worst you should investigate further, you might have one of your AWS credentials compromised.

Are your EC2 instances communicating with TOR endpoints? Well, I would strongly recommend to take a closer look...

GuardDuty can also spot SSH and RDP brute force attempts, DNS exflitration activities, portscans...and I've only scratched the surface!

To make things a bit more interesting I've generated a sample data using the GuardDuty console to show you how it looks:

AWS_GuardDuty_Getting_Started4

And this is how a bitcoin mining alert looks like:

AWS_GuardDuty_Getting_Started5

Remember, you can also further leverage other AWS services that work quite well together with GuardDuty: you can configure AWS CloudWatch monitoring and alarms for a subset of GuardDuty alerts to extend your monitoring capabilities.

Keep calm and investigate

So you have started GuardDuty and now you see alerts showing up...or more like the GuardDuty console is glowing like a Christmas tree...even worse, it kind of looks like the one above :) Don't panic! From here on you can either investigate manually or if you know what you're doing you could also automate your response using AWS Lambda functions. Your mileage may vary but make sure you follow your cyber security incident response processes and procedures...do you have one?