If you went through the exercise in the previous section, you will see the findings appear inside the GuardDuty console after about 8 to 10 minutes. At the top of the screen, the colored ovals that previously contained all zeros will now have one in the medium-severity category and two in the high-severity category.
Figure 6.9: Findings from the GuardDuty Test exercise
From the dashboard setting in GuardDuty, you can sort the findings by different values, including severity, finding type, resource (in this case, it would be an instance ID to allow grouping of all the EC2 instances), the time when the incident last occurred, and finally, the numerical count of the type of attack.
If you click on the instance, it opens up in the EC2 service page. It also shows more information on the screen, with details of the finding and some remediation recommendations.
Figure 6.10: More details revealed about the GuardDuty findings
The next step after learning how to retrieve findings in the GuardDuty console manually is to examine how you can use CloudWatch Events and become a bit more proactive with the events that GuardDuty finds.
One of the significant advantages of using CloudWatch Events is that it allows you to get events in a push context (where the events come proactively to you) rather than a pull context (where you need to retrieve the events).
GuardDuty will also aggregate multiple similar events so that you are not bombarded with noise from the similar events it found. An excellent example of this would be when there are exposed access keys and one or more bad actors, to whom your resources are generally inaccessible, try to use these keys to gain access from various IP addresses. Once the key has been determined to be exposed, this type of access attempt may happen quite often in an hour or shorter period, and receiving multiple alerts of the same kind can become frustrating for you or other security team members. GuardDuty instead sends out an initial alert and then will wait to send out the next one, based on your pre-determined interval schedule. The default setting for this is that you would not get another alert for six hours after the initial alert was sent.
Amazon GuardDuty can also perform remediation on findings through automation, and again, this uses Amazon CloudWatch Events to do so. From the Detect phase, which Amazon GuardDuty is a part of, and by pushing the findings through to the Amazon CloudWatch service, you can then perform automatic remediations using CloudWatch Events (or EventBridge) to then remediate the specific service in question.
Figure 6.11: Automatic remediation using CloudWatch Events
Although automated remediations are what professionals strive for in any instance, there are some occurrences where you have to automate all the steps, or the steps are complicated and manual intervention is required.
You can perform the following manual remediations on a finding, using the steps in the remediating security issues discovered by the GuardDuty guide, as mentioned in the Further Reading section of this chapter:
With each of the preceding scenarios, a detailed set of instructions for step-by-step remediation has been provided to help you return your resource and account to a normal running state.
After remediating security issues with automated responses and manual steps using the Amazon GuardDuty service, the next step is to examine the Security Hub service to learn how you can gather all your security findings into a single view.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
