The course is part of these learning paths
During AWS re:Invent 2017, AWS launched its 11th security service in the on-going drive to help its customers protect and secure their applications, environments, and accounts. This service was Amazon GuardDuty, a regionally based, intelligent, threat-detection service. This service allows users to monitor their AWS account for unusual and unexpected behavior by analyzing AWS CloudTrail Event Logs, VPC Flow Logs, and DNS Logs. It then uses the data from logs and assesses them against multiple security and threat detection feeds, looking for anomalies and known malicious sources, such as IP addresses and URLs. This course will introduce you to this Amazon GuardDuty and explain how it works and how to configure it, allowing you to be able to enable this service within your own AWS accounts to provide automatic and continuous security analysis for safeguarding your entire AWS environment.
Learning Objectives
By the end of this course you will be able to:
- Describe the Amazon GuardDuty service
- Manage and configure GuardDuty for single and multiple accounts
- Implement the correct permissions to both enable and manage GuardDuty
- Manage and resolve findings generated
- Explain how GuardDuty can play an important role within your organization
This course has been designed for individuals in the following roles:
- Security consultant/specialist
- Security analyst
- Security auditor
- Cloud architect
- Cloud operational support analyst
This course would also be valuable to anyone looking to learn more about AWS security and threat detection within AWS.
Prerequisites
As a prerequisite to this course, you should have a basic understanding of the fundamentals of AWS along with an awareness of different security measures and mechanisms that are offered by different AWS services, such as within IAM, specifically IAM policies.
Feedback
If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.
Hello and welcome to this lecture where I'm going to explain how it's possible to link multiple AWS accounts when using Amazon GuardDuty for centralized management.
Many organizations have multiple AWS accounts for many different reasons. When using GuardDuty, it's possible to have one of these accounts act as a master account, and then all other AWS accounts act as members. In this scenario, all the findings from the member accounts are configured to send a copy of the results to the dashboard of the master account. This is ideal for your security teams who manage multiple AWS accounts, as it allows them to view all findings in a central location, instead of having to view the findings from within each AWS account.
It's important to point out that Trusted IP lists and threat lists within the member accounts are not used within the master account. The member accounts each have their own lists, which can be configured by the users within those member accounts. However, the master account does give you added control and administrative functions, such as having the ability of being able to suspend Amazon GuardDuty within its own account and other member accounts. If you wanted to disable the service, then you must first remove the member accounts from the master account, as the master account is not allowed to disable GuardDuty on its member accounts.
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 three stage process. You must first add an AWS account from within the master account, send an invitation to the member account, and then accept the invitation from within the member account. This process prevents a single account from simply adding member accounts without authorization. The member account has to accept the invitation before sharing its findings with the master account.
To show you how to create the link between accounts, I will now demonstrate these three steps by adding a member account to a master account.
Okay, so I'm at the dashboard of the Amazon GuardDuty, and what I need to do is go down on the left hand side to Accounts. Now, I'm going to 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 are the accounts to be added, and then click on next, and we see here that member accounts share the findings with you, and members must first accept your invitation.
So, if we go down to under the Status column and click on Invite. Now, if you wanted to, you can enter a personal message here that will go to owner of the secondary account, and I'm just going to say "Please accept." 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. And we can see the status is now saying "Pending." 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, and it takes me straight to this screen, and it says you have a membership invitation, but we must enable GuardDuty before we can accept invitations. So, we'll need to enable GuardDuty on this account first.
GuardDuty's now enabled, and it states that "The following AWS accounts have requested permission permission to view and manage GuardDuty items 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 down to Accounts on this member account, I can see that this is a member account, and that pushes its findings to this master account, so I've accepted the invitation there.
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 monitored. 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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
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.