In our last blog on Alert Logic MDR Essentials, we talked about how you can aggregate Amazon GuardDuty findings across multiple AWS regions to create a central view for enhanced GuardDuty analysis, remediation, and reporting. Today, I’m going to talk about how you can integrate MDR Essentials with multiple AWS accounts to save on costs and get more detailed information about Amazon GuardDuty findings for each AWS account.
Alert Logic MDR Essentials & Amazon GuardDuty Integration
Before we discuss how to manage findings from different AWS accounts, let’s quickly review our integration and the services involved. Amazon GuardDuty is a new AWS service launched at re:Invent 2017 that analyzes AWS CloudTrail event logs, VPC Flow Logs, and DNS Logs. Within these logs, GuardDuty looks for unusual or suspicious behavior like using an uncommon port on EC2 or launching instances through unusual means. The suspicious behavior is called a finding in GuardDuty, and includes data like your AWS account, AWS region, time, and other information about the security event.
Alert Logic integrates with GuardDuty by allowing customers to forward all findings to MDR Essentials. MDR Essentials (also launched at re:Invent 2017) is an Alert Logic service that automates continuous discovery and configuration inspection of customer AWS environments, services and workload settings to identify risky configurations that go against AWS security configuration best practices. Within MDR Essentials, customers can also deploy vulnerability scanners that scan your software in AWS and identify Common Vulnerability Exposures (CVEs) or configurations that put you at risk.
Customers can integrate GuardDuty with Alert Logic MDR Essentials by using our AWS CloudFormation template which deploys an AWS Lambda function and an Amazon CloudWatch Events collector. This CloudWatch Events collector gathers all CloudWatch Events associated to GuardDuty findings and forwards those events to MDR Essentials. When MDR Essentials receives the findings, the service augments the data by providing more, detailed information about what to do with every finding and how to prevent the finding from occurring again. MDR Essentials also tracks historical trends between findings, EC2 instances, and misconfigurations to spot deployments that present a high security risk.
Figure 1: Alert Logic MDR Essentials Integration with Amazon GuardDuty
Why is it important to understand this integration? The reason is because our CloudWatch Events collector allows you do some interesting things when you’re using GuardDuty for multiple AWS accounts. Let’s discuss two scenarios that I call The Cost Savings Deployment and The Detailed Deployment that you can use with our CloudWatch Events collector.
MDR Essentials Cost Savings Deployment
GuardDuty has a feature called the master account which allows you to invite other AWS accounts (called member accounts) to use GuardDuty and forward their findings to a central account. The use case for this feature is to provide visibility of all findings across multiple AWS accounts to a central security team. You can read more in Managing AWS Account in Amazon GuardDuty.
MDR Essentials is typically configured by creating a deployment that maps to each AWS account. Within the Deployment, you can define which regions, VPCs, and EC2 instances you want MDR Essentials to scan and monitor. Using Deployments for each AWS account is a great way for you to visualize and structure responses to security incidents (GuardDuty findings) specific to each account. Therefore, MDR Essentials is priced along this dimension: a monthly fee for each AWS account (or deployment) that you monitor.
Although MDR Essentials is competitively priced, if you have 100s or 1000s of AWS accounts using GuardDuty, setting up deployments for each AWS account may be cost prohibitive. Luckily, by using our CloudWatch Events collector for the master account you can aggregate all findings for every member account and you only need to create one MDR Essentials deployment. By using this method, you save on costs while adding more security context to findings across all your AWS accounts.
Let me walk through an example of how to do this. In my example, I have two AWS accounts: (1) one master account, and (2) one member account. I’ve combined all findings by designating the master GuardDuty account and the member account, which has accepted the invitation and agreed to be monitored by the master account.
Figure 2: Amazon GuardDuty Master and Member Accounts
Next, I’ve created a deployment for the master account and deployed the CloudWatch Events collector into the master account, which is already getting findings from both accounts.
Figure 3: Alert Logic Integration with GuardDuty Master Account
The last step is to create a deployment based on an IAM role/policy for the master account (called MasterGDAct in my example).
Figure 4: MDR Essentials MasterGDAct Deployment
And voila! I can now see all GuardDuty findings for both accounts in MDR Essentials, and I only had to create one deployment for both AWS accounts.
That’s great! But there must be a catch, right? There’s no catch, but there is a down side to deploying this way. Because MDR Essentials has only one deployment tied to an AWS account, i.e., the master account, you lose out on some reporting granularity and filtering functionality.
For example, all GuardDuty findings are listed under the MDR Essentials Incidents menu. If you look at the screenshot below of my open incidents, you’ll notice that some are tied to the MasterGDAct deployment and some are tied to nothing (N/A).
Figure 5: Open Incidents List Menu
Because there is no deployment associated to the member account, MDR Essentials is unable to list the finding to a specific deployment. If you click on the incident and expand the Evidence details, you’re able to see the AWS account ID (meta data provided by GuardDuty) and can backtrack findings to each AWS account this way, but it does take a bit of sleuthing.
Figure 6: Evidence Menu
This isn’t too bad because I only have two AWS accounts, but it could get overwhelming tracking down evidence for all findings from 100s or 1000s of AWS accounts that don’t have MDR Essentials deployments. Additionally, there are MDR Essential reports that I won’t be able to fully use because they are structured by deployments.
However, if cost is a big factor for you and you don’t mind digging into details for each finding or just need a summary of which findings your AWS accounts see the most, then the Cost Savings Deployment is a great alternative that allows you to see more details at an aggregate level for all your AWS accounts.
Figure 7: Incidents Summary View
To deploy Alert Logic MDR Essentials in this method:
1. Follow the steps outlined in Designating Master and Member Accounts Through GuardDuty Console.
2. Create a deployment only for the master account using the steps outlined in Set up and manage deployments
3. Deploy the CloudWatch Event collector for the master account using the steps outlined in our GitHub repository.
Now let’s talk about how to get the most value out of GuardDuty and MDR Essentials: The Detailed Deployment.
MDR Essentials Detailed Deployment
The only real difference between the Cost Savings Deployment and the Detailed Deployment is that you create deployments for each AWS account. What this allows MDR Essentials to do is associate each finding to a deployment that you’ve mapped to an AWS account. Now you can filter, report, and create remediation plans that are specific to every AWS account, and if you like, you can setup access for the individual AWS accounts to see configuration checks for their specific deployment.
For this scenario, again I have two AWS accounts: (1) one master account, and (2) one member account. Again, I’ve combined all findings by designating the master GuardDuty account, and the member account has accepted to be monitored by the master account.
Last, I’ve deployed a CloudWatch Events collector into the master account, and the collector is forwarding all findings to MDR Essentials.
Figure 8: Alert Logic Integration with GuardDuty Master and Member Accounts
The one step that is different in this approach is I’ve created two MDR Deployments: one for the master account and one for the member account (called MasterGDAct and MemberGDAct in my example).
Figure 9: Deployment Menu with Two Deployments
Now if I look at my open incidents lists, I see unique deployments for every finding. Now I can also search by deployment name if I only want to see findings for a specific AWS account.
Figure 10: Findings for Both Deployments
Figure 11: Filter and Search by Deployments/AWS Accounts
To deploy MDR Essentials in this method:
1. Follow the steps outlined in Designating Master and Member Accounts Through GuardDuty Console.
2. Create deployments for every AWS account using the steps outlined in Set up and manage deployments
3. Deploy the CloudWatch Event collector for the master account using the steps outlined in our GitHub repository.
Note: with this approach, I don’t necessarily have to designate a master GuardDuty account because I created a deployment for every AWS account. MDR Essentials can combine GuardDuty findings for multiple AWS accounts, so I could skip this step if I wanted to do.
The tradeoff to not using a GuardDuty master account is I’ll need to deploy a CloudWatch Events collect for each AWS account as there’s no single account that receives CloudWatch Events from all AWS member accounts.
Figure 12: Alert Logic Integration with Multiple GuardDuty Accounts
I hope you’ve enjoyed this blog on how to integrate MDR Essentials with multiple AWS accounts. If you’d like to learn more, be sure to visit our page on Alert Logic MDR Essentials, or request a demo to see first-hand how it would benefit your organization.
