Resources mentioned in this lecture:

Course: AWS CloudTrail: An Introduction

AWS Resource: Amazon GuardDuty Finding Types

Lecture Transcript

Hello and welcome to this lecture. Now we have an understanding of what the service is, I want to talk about the components that make up Amazon GuardDuty and its configurable options.

Firstly, let me look at the data sources that the service uses to perform its analysis. As mentioned in the previous lecture, the service uses three data sets to monitor your AWS account for threats, these being AWS CloudTrail Event Logs. These logs are generated from the output of the CloudTrail service in a JSON format and they hold all of the information and data relating to API calls that have been captured within your account. If you'd like further information on AWS CloudTrail, then please see our existing course here, which covers the service in detail.

VPC Flow Logs, these logs capture and store network traffic information flown into an out of your network interfaces from instances within your VPC. They are often used to troubleshoot networking issues for instances and can be used as a security tool by monitoring what traffic is reaching your instance.

DNS Query Logs, these logs contain queries that DNS resolvers forward to Amazon Route 53 and they can include information such as the domain and subdomain that was requested, a timestamp of the request, the DNS record type, and the DNS response code. If you're not currently running these logs or have them configured within your account, then you need not worry. When you enable Amazon GuardDuty, it will automatically make these logs available to the services itself for analysis. However, it doesn't manage these logs in anyway. If you want management of these logs, then you'll need to configure this through the relevant service dashboard or API.

Amazon GuardDuty also incorporates machine learning. This allows the service to learn and adapt to what classes as unusual behavior within your account over time to then highlight it as a potential threat. This is an ongoing process. The more you work with your account, the more Amazon GuardDuty will be able to distinguish between intended operational changes and that of malicious or unusual behavior that sits outside of your normal parameters of operation. In addition to the analysis that is undertaken against the various logs that I've already discussed. 

It's also possible to upload your own list of trusted IPs and threat list. Any IP information that is added to the trusted IP list is white listed. This simply means that GuardDuty will not generate findings based on these IP addresses. They are trusted and known IP addresses. It's worth mentioning, but you can only have one active trusted IP listed any time. You can also include your own list of threats as well based on IP information. This list will contain a known list of malicious IP address or networks, but you want to ensure Amazon GuardDuty generates findings for if any traffic is detected with this information. Unlike the trusted IP limit list of one, you are allowed six threat list to be simultaneously active within guardduty at any one time. To add either a trusted IP list or threat list is a very simple process. You simply need to provide three bits of information from within the Amazon GuardDuty dashboard. Firstly, you need to give your list a name, then provide the URL of whether source list is located on S3, and then the format of that list.

The main functions of Amazon GuardDuty is of course to detect any potential threats within your environment. When a threat is found, it is labeled as a finding within the GuardDuty dashboard, allowing you to take appropriate actions against them to resolve any security vulnerability that might exist. The content of the finding itself contains a lot of useful information and is essentially broken down into five parts. The finding summary, the resource affected, the action, actor, and additional information. Let me just run through each of these elements so you have a brief understanding of the complete finding.

The summary of the finding contains some key data, including the finding type, the severity, the region, the account ID, resource ID, time of detection, and depending on the threat detected, it can also contain information on which threat list was used to detect the finding. Much of this data is self-explanatory. However, I want to explain more about the finding type as this is a very useful piece of data when trying to ascertain what the finding relates to.

The finding type is a single phrase composed of concatenated data, which follows a specific syntax that defines a potential threat event that is detected. For example, the finding type of unauthorized access, EC2 / SSH Brute Force shows that an EC2 instance has been involved with an SSH brute force attack. This makes it very easy to quickly identify the nature of the threat from the summary screen. As I said, this finding type is defined by a set syntax, which is as follows.

Using our previous example, we an see the finding type with the above syntax. As you can see, not every finding type will contain all elements of the four syntax. For a complete list of the available finding types and what they define, see the AWS documentation here.

Resource affected, this section is dedicated to providing information and by the affected resource in the threat that has been detected. Depending on the finding type, the information in this section and all remain sections can vary.

Action. The action section provides information relating to the action that was carried out, that resulted in the threat being detected.

Actor. The actor section contains data relating to the source of the detected threat, such as geographical information, IP address, port and domain.

Additional information. Finally, the additional information section may contain information such as which threat list was used to detect the threat and if the activity was considered to be unusual compared to historical data. Each finding is associated with the severity level and score. The score value will affect the severity. As of writing this course, the severity is set as follows. High is labeled is seven to 8.9, medium is four to 6.9, and low is 0.1 to 3.9. These different severity levels allow you to quickly identify which findings you should act upon first as a priority.

Any finding that is marked as high should be investigated immediately as it assumes that a security breach has occurred and the resource in question has been compromised which poses a significant threat to your infrastructure. Remediation of this finding should be your first priority before the threat extends further within your account with additional malicious activity.

A medium severity will genuinely indicate that GuardDuty had to take the suspicious activity within your account against a specific resource. Although not as critical as high, this level of finding should still be investigated as soon as possible as it could be the beginnings of a greater threat and could soon escalate to a high if left unchecked.

Low severity findings do not require you to take any immediate action. These are threats that were detected and blocked before any issues arose within your environment. However, it is still worth looking at any low findings to see if there are improvement that can be made to prevent it from happening again.

I now want to perform a quick demonstration introducing you to the service itself. I'll show you how to enable the service, configure trusted IP and threat list, and I'll walk you through each of the screens within the Amazon GuardDuty dashboard. So let's get started.

Okay, so I'm signed into my AWS management console, and what I want to do first is go to Amazon GuardDuty and we can find that down under Security, Identity, & Compliance. And if this is the first time that you're using the service, you'll be presented with this splash screen, and it just enables you to get started and gives you a quick overview of exactly what it is. So, let's get started.

Firstly, we need to enable the service. And like I say, it's a very simple process. All we need to do is to click enable guard duty, And when we do this, as it says here, when you enable GuardDuty, you grant GuardDuty permissions to analyze AWS CloudTrail Logs, VPC Flow Logs, and DNS query logs to generate security findings. And this will set up a service role permission which has this access here, but I'll go more into permissions in a later lecture to explain these service roles et cetera.

So if I click on Enable GuardDuty. It's as simple as that. So we now have GuardDuty running within this account within this region. And at the moment, we don't have any findings which is absolutely fine. I don't really have many resources running in this account. It's just a test account. So if I just take you through the dashboard and each of the screens and we can just take a look and get a feel for the service.

So on the left-hand side, you can see we have three different headings. We have Findings, Settings, and Free trial. So let's start at Findings. In the screen, it will show any findings that have been found by Amazon GuardDuty and it will list under here as a finding and when it was last seen, etc. Like I say, at the moment, we've only just enabled the service. I don't really have any resources running, so there is no findings at the moment.  If we go into Archived, this will show a list of archived findings that you've had, again, with the same columns.

If we go down to General under Settings, here it talks about the permissions of the service role that GuardDuty uses to monitor your resources. And like I say, I'll dive deeper into permissions in a later lecture, but this is where you can just see the service role permissions that it has and the trust relationships as well. On the CloudWatch events, GuardDuty does support CloudWatch and if you click on this link here, it will tell you how to configure this.

Under Sample findings, this is quite useful. So, sample findings help you visualize and analyze the finding types that GuardDuty generates. And if we want to list a number of sample findings for us to kind of get familiar with the console and the different findings that it has. Then we can simply click on Generate sample findings. And now if we go back to our finding settings under Current, we can see that GuardDuty has enabled a number of different sample findings for us, and they're indicated here as samples. Don't worry, these aren't real findings in your account, these are all samples, and we can see that we have 33 samples.

If we look along these icons here, we can see that one of them has a high severity and 32 of them have a medium severity. And if you click on each of these, you can filter on those to identify exactly where the finding is. And if you want to remove the filters, just simply click on the X here. So if we keep going through these settings on the left. So that's Generate sample findings. Underneath this, it gives you two settings, one to enable you to suspend GuardDuty and another to disable GuardDuty.

When you suspend GuardDuty, it stops monitoring your AWS environment, and it won't generate any new findings at all. But any existing findings you have will remain in the console. If however you disable GuardDuty, then again monitoring will stop and it won't generate new findings and you'll also lose all your existing findings as well. If you want a copy of those findings before you disable it, then it's best to export that data before you do so.

Next, if we go down to Lists, now this is where we can perform list management of your trusted IP lists and also your threat list as well. Okay, so let's add a trusted IP list and a threat list whilst we're here. So if I click on Add a trusted IP list, specify the list name, let's just call this TrustedIP, enter the location, and I've called it TrustedIP.txt. So that's my bucket. And if I specify the format just as plain text. And you need to click on I agree to accept and agree to the GuardDuty service terms. And then click on Add list. There we've added the trusted IP list.

If we move down to a Threat list, we can do the same. So let's just call this ThreatList in the same bucket, and I've called it ThreatList.txt. Specify the format, plain text again. I agree. Add list. Then we got it. So now we have our trusted IP list and also our threat list that GuardDuty will use. And if you had a number of threat list, then you can select different ones to be active, etc. So it's very simple to add your trusted IP list and your threat list as you can see.

If we go down to Accounts on the left-hand side, this is where you can set up and manage multiple accounts. So you can use a master GuardDuty account. And then if you have other AWS accounts, you can add them as member accounts, and then view all the findings from those member accounts in this one master account So it makes management a lot easier, and I'll talk about this in a further lecture when I talk about multiple accounts. So I'll go into that a lot deeper then.

Now if we look at Free trial, we look at the details on the Free trial. When you first enable Amazon GuardDuty, you get 30 days free of the service. And using the screen here, you can see how many events have been monitored by CloudTrail logs and how many bytes we're using through VPC Flow logs and DNS logs. And it'll give you an estimate in cost on how much that would actually cost once you're outside of your 30-day free trial. So it gives you a good estimation on understanding how much this service would cost you over a typical month. So like I say, when you first enabled the service, you get 30 days free, and you can use this screen to kind of get an estimation on how much it would cost you going forward, which I think is a really good idea.

And then finally, on the left-hand side, we have Partners, and this will take you off to a list of Amazon GuardDuty partners. That's essentially it for the console. Like I say, it's a very simple service. There's not much to it at all.

Before I finish the demonstration, if we go into one of these findings, pick this one for example, we can see here that we have a brief description of what the finding is. We can see that an instance with an unusual type was launched by a IAM principal, has a severity, and tell us the region it was in, how many. The account ID that it came under and any resource information, and also the treat list name as well. Again, remember these are just samples. It tells us about the resource effective and the access keys and IDs and usernames, what action was used, like the API call and the service name, and also some geographic information as well about where that was initiated from. So when you select the finding, you can get quite a lot of information from this to help you resolve the issue. And I have a later lecture coming up that dives deeper into analyzing findings as well. So I'll talk more about these findings in that lecture. Let's click on Close. And there you have it.

So, it's very simple to enable GuardDuty. It's imply a one click and it's enabled for that region, and you just have a few menus on the left-hand side that are very self-intuitive.

That now brings me to the end of this lecture. Coming up next, I'm going to be talking about more on how to manage multiple accounts, so you can miss out of the dashboard. So I'll explain how to share the findings from all your member AWS accounts and push it to one master GuardDuty account.