Let’s do a quick demo to see how GuardDuty works in the console. We’ll talk about how to enable the service, I’ll walk you through the GuardDuty dashboard and then we’ll check out an example of a finding. 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. So I’ll type in GuardDuty in the search bar, and then click on it. If this is the first time that you're using the service, you'll be presented with this splash screen that enables you to get started. To do this, we’ll click “get started”.

The next thing it asks us to do is to enable the service. Basically, what this screen is saying is that by clicking enable down here, you’re granting permissions to VPC Flow logs, AWS CloudTrail management event logs, DNS query logs, AWS CloudTrail S3 data event logs, Kubernetes (EKS) audit logs, and RDS login activity logs. You’re also enabling all protecting plans by default, except for EKS runtime monitoring. To do this, it’s setting up a service role with permissions for this access.

If you’re cool with granting this access, all you have to do is click enable. Pretty easy process and now we have GuardDuty running in this account - for this Region, which is the us-east-2 region.

As you can see, at the moment, we’re currently in the Findings dashboard, and I don’t have any findings just yet. GuardDuty will populate this screen for me once it finds any potential threats, and I’ll be able to filter between all of my findings, the current findings, and any findings I’ve archived.

If we click on “usage”, we can see the breakdown of what we’ve used in GuardDuty and the average daily cost for each data source. GuardDuty does give you a 30 day free trial, which I am in currently - so I have no cost associated here.

Also on the left panel is where we can choose to initiate malware scans. These can be initiated both by GuardDuty or we can choose to initiate them on-demand if we’d like.

Now onto the protection plans, if we click on any one of these, say for example, the S3 Protection plan, we can see that it is enabled already. However, we can click disable for each if we’d like. The only one that isn’t enabled by default is the EKS runtime monitoring, so if I click on EKS protection, I can see it’s not enabled under here. If I wanted to enable it, I can click edit, make sure the runtime box is checked, and then click enable, I’ll have both the audit logs AND the runtime monitoring enabled.

If we go down to the Settings section, here you can configure several things. The first thing you can see is the permissions of the service role that GuardDuty uses to monitor your resources. Next you can see that you can export findings. It automatically exports to CloudWatch events on the interval that you select, and you can also optionally integrate with S3 to export your findings to an S3 bucket.

Under Sample findings, this is a useful feature if you’re new to the service . It enables you to visualize and analyze the finding types that GuardDuty generates. It populates your dashboard with sample findings to get a feel for how the service works. We’re gonna do this by clicking generate sample findings.

Now, if we go back to the findings dashboard by clicking “findings” on the left side, 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 169 findings.

If we look along these icons here, we can see that these findings can be separated by severity. So we have 16 low severity findings, 70 medium severity findings, and 83 high severity findings. If we click the high severity number, it will show us the 83 high severity findings.

And if you want to remove the filter, just simply click on the X here.

The last thing we’re gonna do in this video is take a look at one of these findings. Let’s look at the first one. Immediately, we can read the finding type - UnauthorizedAccess:IAMUser/MaliciousIPCaller. Already, we have an understanding of what happened here. We know that some bad IP address made an API call that they shouldn’t have made. If we click on this, we can see more information.

We can see the overview here - with the region ID and account ID. We can also see the resource affected in this case it was this instance ID and the instance was an m3.xlarge.

The action - so which API they called. In this case, it’s a fake API. The actor - so who did it? Well this bad IP address did it. The additional information section and the threat IP list that this bad actor was listed on.

So in this case, it was from a threat list that was provided to Guard Duty.

All right - that’s it for this one. I’ll see you in the next one.

Demo Part 1

SELF PACED PLATFORM

TRAINING CONTENT

JOB ROLE PATHS

CERTIFICATIONS