The course is part of this learning path
This course looks at how to collate and manage findings from multiple AWS accounts with Amazon GuardDuty. Amazon GuardDuty is a regionally based, intelligent, threat-detection service which will monitor unusual and unexpected behavior.
By the end of this course, you will be able to implement, manage and monitor your own Amazon GuardDuty findings across your own accounts through the analysis of AWS CloudTrail event logs, VPC flow logs, and DNS logs.
This course has been created for security operations engineers and architects who focus on monitoring and assessing threats to their AWS environment. I will explain the process and method in how to achieve this using Amazon GuardDuty in addition to a demonstration of its configuration
To get the most from this course you should be familiar with basic concepts of Amazon GuardDuty. For more information on this service, please see our existing course here: Understanding Amazon GuardDuty
Hello and welcome to this lecture which will focus on the centralized management of the Amazon GuardDuty findings. Firstly, a quick recap of Amazon GuardDuty itself. Amazon GuardDuty is a regional-based intelligent threat detection service, the first of its kind offered by AWS, which allows users to monitor the AWS account for unusual and unexpected behavior by analyzing CloudTrial event logs, VPC flow logs, and DNS logs. It then uses the data from these logs and assesses them against multiple security and threat detection feeds, looking for anomalies and known malicious sources, such as IP addresses and URLs.
The service itself is powered by machine learning and this allows the service to continuously evolve by learning and understanding operational behavior within your infrastructure. Amazon GuardDuty then uses this data to look for erroneous patterns within your AWS account that could indicate potential threats to your environment. These threats could be behavioral-based, where a resource has been compromised by an account or credential exposure, unexpected API calls that sit outside security best practices, or even communications from suspicious sources.
For ease of management, it's possible to aggregate GuardDuty findings from multiple AWS accounts and forward them to a single AWS account. This is ideal for your security teams who manage multiple AWS accounts, as that allows them to view all findings in a central location instead of having to view the findings from within each AWS account. With this in mind, it's possible to have one AWS account act as a master account to all other accounts, which will be known as member accounts. In this scenario, all the findings from the member accounts will be configured to send a copy of the results to the dashboard of the master account. The operation of Amazon GuardDuty with the member accounts remains the same. The users can still perform the same functions from within the dashboard and it's still possible to view and review the findings, upload trusted IP threat lists, as well as suspend or disable the service on that member account.
To set up your AWS accounts in a master and membership configuration for GuardDuty is a simple 3-stage process. Firstly, you select which AWS account will act as your master account. You then need to add your member accounts from within the master account, which will send an invitation to each member account. Administrators of the member accounts will then need to accept the invitation from within their own AWS account. To show you how to create a link between accounts, I'll now demonstrate these three steps by adding a member account to a master account.
Okay, so I'm at the dashboard of Amazon GuardDuty and what I need to do is go down on the left-hand side to Accounts. Now, I'm gonna have this account as my master account, and I want to invite a second AWS account that I have to be a member account. So, that member account's findings and details will be fed through to this master account. So the first thing I need to do is click on Add Accounts. And I need to enter the account ID of the member account and also the associated email address of that account. Now, if you have maybe 10, 20, 30 AWS accounts, or even more, then you might find it a little laborious to add each individual account. So what you can do, you can upload a CSV file with all that information in with all the account IDs and the associated email addresses. As I only have the single account I'm going to add, I can put that account number in, and also the associated email address. Click on Add, and at the bottom here we can see these, the accounts to be added. Then click on Next.
So, if we go down to under the Status column and click on Invite. Now, if we wanted to, we can enter a personal message here that will go to the owner of the secondary account, and I'm just gonna say, "Please accept." I'm also gonna select this tick box to send an email notification to the root user of the member account as well. At this point, we just need to click on Send Invitation. And that has now sent an email to the owner of the account that we added.
So, if I go across to my email and take a look at the email that we've received. Now, this is the email that I've received. Now, the title states that there's action requested, and it says, "The master account wants to become the AWS GuardDuty administrator for this secondary AWS account." And we can see down here, where it says, "The following notes were provided with this invitation," and it says, "Please accept." So that's that custom message that I added.
Now, to view the invitation, we can click this link here. Now, as long as I'm signed in to the member account which I am, then it takes me straight to this screen here, and it states that "The following AWS accounts have requested permission to view and manage GuardDuty findings on your behalf. You can accept only one invitation." So this is our master account here, and I want to accept. And then I'll go across to Accept Invitation. And that's it.
So this is now the member account and it will push its findings across to the master account. So now, if I go across to the master account. So I'm back in my dashboard for my master account, and now if I go down to Accounts, I can see here that I have a member account added, and the status is now Enabled. And that's it.
So it's a very simple process to achieve. So from your account that you want to be the master, you then invite any member accounts. Those member accounts then simply accept that invitation, and from that point onwards your master account will then monitor the status and findings of all your member accounts.
That brings me to the end of this course which demonstrated how the findings of Amazon GuardDuty from multiple AWS accounts can be monitored from a single central AWS account. If you'd like to learn more about Amazon GuardDuty, we have a course dedicated to the service, which will go into finer detail regarding the components and configuration of the service, how to manage permissions, how to interpret the findings received, the benefits of GuardDuty to the enterprise, the costings, and different partner offerings. This course can be found here.
Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you can contact email@example.com. Thank you for your time and good luck with your continued learning of cloud computing! Thank you.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 60++ courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.