Deepwatch MDR AWS Built-in

This guide is for customers who are building a Deepwatch MDR integration solution using the AWS Built-In (ABI) program. It walks you through the process of configuring your AWS organization with Deepwatch MDR service.

ABI is a differentiation program that validates AWS Partner solutions that have automated their integrations with relevant AWS foundational services such as identity, management, security, and operations. It helps customers find and deploy a validated partner solution that addresses specific customer use cases while providing deep visibility and control of AWS native service integration.

Choose Overview.

Subsections of Deepwatch MDR

Deepwatch ABI Overview

AWS Built-In (ABI) is a certified program conferred upon ISV Partners. It assists customers in effortlessly implementing third-party software that seamlessly integrates with AWS Native Services. The intended audience for this program includes customers seeking an all-in-one solution, as opposed to the complexities of independently installing, securing, and configuring AWS Native Services to leverage the full potential of third-party software. Partners with their own Built-In offerings provide tailored deployment packages where their solutions are intricately woven into AWS services using Infrastructure as Code (IaC). This approach dramatically reduces the time customers would otherwise spend, transforming it from weeks into mere minutes. Consequently, it optimizes customer efficiency, expediting the deployment of new initiatives.

AWS Built-In partner solutions undertake the responsibility of installing, configuring, and harmonizing with core AWS services. They employ a well-structured Modular Code Repository (MCR) and offer automated deployment packages that have been meticulously reviewed and validated by AWS experts. This automation independently undergoes rigorous scrutiny by AWS, resulting in substantial time savings – an equivalent of hours, days, or even weeks in vendor integration testing.

By simplifying the integration process, we empower customers to unlock the full potential of foundational AWS native services while benefiting from the rich functionality of third-party solutions. Our primary aim is to deliver a unified and cohesive experience to customers, alleviating the complexities often associated with combining disparate software and data sources.

For instance, when a customer subscribes to an ISV partner product, they encounter a series of steps to transition from the subscription phase to full functionality. These steps encompass a mix of manual and Infrastructure as Code (IaC) procedures. These steps include enabling services like Amazon GuardDuty, AWS Security Hub, Amazon Inspector, and AWS CloudTrail, followed by additional actions such as incorporating AWS accounts and integrating with CloudTrail events, among other tasks on the partner SaaS product.

In comparison, this AWS Built-In package facilitates the integration of Deepwatch MDR with AWS Organizations on the AWS Cloud. It caters specifically to Deepwatch customers who utilize AWS CloudTrail and Amazon GuardDuty and seek to establish the essential resources for ingesting log sources for the Deepwatch MDR service across multiple AWS accounts.

If you are unfamiliar with AWS Built-In, refer to AWS Built-In.

Deploying this ABI package does not guarantee an organization’s compliance with any laws, certifications, policies, or other regulations.

AWS Marketplace listing

deepwatch Managed Security Services

Next: Terminology

Terminology

  • ABI: AWS Built-In.
  • ABI modules: These are modules in the AWS Security Reference Architecture repository. This provide templates for enabling AWS foundational services like CloudTrail, GuardDuty, SecurityHub, and other security services.
  • ABI projects: This GitHub repository is built by partners in collaboration with AWS. While building these projects, partners use ABI modules to enable necessary AWS services before creating partner-specific assets. The project contains:
  1. IaC templates to automate the enablement of both AWS and Partner services.
  2. Wrappers for most common formats like the CfCT manifest, AWS Service Catalog baselines, and more so customers can pick and choose available services.

In the current release, the package includes only the CfCT manifest file, in addition to the IaC templates.

  • Deepwatch MDR: Deepwatch managed-detection-and-response service. This applies only to Deepwatch customers that use this service.
  • Deepwatch MDR AWS account: The AWS account that uses the Deepwatch MDR service where the required resources are hosted. This account is referenced in the accompanying architecture diagrams.
  • Customer AWS resources: The resources deployed in the Deepwatch customer’s AWS account to facilitate log ingestion. This includes all of the necessary Lambdas, SNS topics, SQS queues, S3 Event Notifications, and IAM roles and policies.

Next: Costs and licenses

Costs and licenses

Deepwatch licensing costs

To address your cost-related concerns, please note that the deployment of this solution assumes that you are an existing Deepwatch MDR customer. You can find detailed pricing information for Deepwatch services on the AWS Marketplace..

AWS service costs

There is no additional cost to use this solution, but you will be billed for any AWS services or resources that this package deploys. For more information about costs, refer to the AWS pricing pages in your Region for the following services:

Next: Architecture

Architecture

Deploying this ABI package with default parameters builds the following architecture:

Architecture diagram Architecture diagram

As shown in the diagram, this solution sets up the following:

Enable organization level CloudTrail

  • Creates an organizational trail for all accounts in the organization in the management account.
  • A customer managed KMS key for the AWS Organizations CloudTrail logs and Amazon Simple Storage Service (Amazon S3) server-side encryption in the audit account.
  • AWS Secrets Manager secret containing the customer managed KMS key ARN in the audit account.
  • Amazon S3 bucket in the log archive account, where the organization CloudTrail logs are sent for all accounts in the AWS Organization.

Enable Amazon GuardDuty at organization level

  • Enables GuardDuty for all AWS accounts that are current members of the target organization in AWS Organizations
  • Turns on the Auto-Enable feature in GuardDuty, which automatically enables GuardDuty for any accounts that are added to the target organization in the future
  • Uses the organization’s Audit account as the GuardDuty delegated administrator
  • Creates an Amazon Simple Storage Service (Amazon S3) bucket in the logging account and configures GuardDuty to publish the aggregated findings from all accounts in this bucket
  • Assigns a life-cycle policy that transitions findings from the S3 bucket to Amazon S3 Glacier Flexible Retrieval storage after 365 days, by default
  • Enables GuardDuty S3 protection by default, with the option to enable EKS and Malware protection.

Deepwatch Managed Detection and Response (MDR) Integration

  • Deploys a stack set from the management account that creates the following resources in the Log Archive account:
    • Event notification on S3 bucket where the organizational GuardDuty and CloudTrail logs are stored
    • SNS Topic and SQS queues to process the S3 event notifications
    • Lambda function for processing and filtering of messages in SQS queues
    • IAM Role for cross-account role assumption by Deepwatch MDR Platform

Next: Deployment options

Predeployment options

Before deploying this ABI package, complete the following steps:

  1. Subscribe or Have an Agreement: Start by subscribing to the Deepwatch Managed Security Services AWS Marketplace Listing. Alternatively, if you already have an existing customer agreement signed with Deepwatch, you can proceed.

  2. Create your AWS Organization using AWS Control Tower [Recommended]: If you haven’t already, create an AWS organization using AWS Control Tower. Detailed instructions can be found in the Tutorial: AWS Control Tower quick start guide. [Update] As of Jan 2024, you can deploy this ABI package in an AWS Organization without AWS Control Tower setup as well.

  3. IAM User Permissions: To create an organization trail and enable GuardDuty, ensure that your IAM user has the necessary permissions for the user or role in your management account.

  4. Activate Trusted Access: Enable trusted access with AWS Organizations. This step is crucial for multi-account deployments. For detailed guidance, please refer to Activate trusted access with AWS Organizations. Without this, AWS CloudFormation won’t run.

  5. Check GuardDuty Status: Confirm that GuardDuty was not enabled individually or using delegated admin in any of the accounts with in the organizations. More information on this can be found in Managing multiple accounts in Amazon GuardDuty.

  6. If you’re using this solution in an AWS organization that doesn’t use AWS Control Tower, you need to create IAM roles to Set up basic permissions for stack set operations before deploying this ABI solution. a. You need to create pAdminRoleName [Parameter used while launching the solution] in your management account. The CloudFormation template to create this role is available here. b. You need to create pExecRoleName [Parameter used while launching the solution] across all child accounts with in the organization. You can use this CloudFormation template and deploy the stack acoss the organization using instructions from Create a stack set with service-managed permissions

  7. Explore Additional Resources: As you proceed, be sure to familiarize yourself with the additional resources available later in this guide.

Next: Deployment Steps

Deployment steps

Launch the CloudFormation template in the AWS Organizations management account

This option creates all of the necessary resources for ingestion of AWS security logs into the DeepWatch MDR platform. During the deployment, you can choose which options to enable for the individual services.

  1. Download the CloudFormation template

  2. Launch the CloudFormation template from your AWS Control Tower home Region.

    • Stack name: template-deepwatch-enable-integrations
      • pDeepwatchRoleName: deepwatch-mdr-role
      • pSRAS3BucketRegion: us-east-1
      • pSRASourceS3BucketName: aws-abi
      • pAutoEnableMalwareProtection: false
      • pAutoEnableKubernetesAuditLogs: false
      • pAutoEnableS3Logs: true
      • pEnableS3DataEvents: true
      • pEnableLambdaDataEvents: true
      • pCreateAWSControlTowerExecutionRole: true # Set to false if you have already created the AWSControlTowerExecution role in the management account Note: Include below parameters if you are deploying this solution in an Organization with no Control Tower.
      • pControlTower: false
      • pLogArchiveAccountId: 111111111111 # Your log-archive-account-id
      • pSecurityAccountId: 222222222222 # Your audit-account-id
      • pGovernedRegions: ‘us-east-1,us-east-2’ # List of regions
      • pSRASourceS3BucketName: aws-abi
      • pAdminRoleName: ‘AWSCloudFormationStackSetAdministrationRole’ # Replace with your admin role name
      • pExecRoleName: ‘AWSCloudFormationStackSetExecutionRole’ # Replace with your exec role name

  3. To launch the stack, choose the Capabilities and then Submit.

    [x] I acknowledge that AWS CloudFormation might create IAM resources with custom names.

    [x] I acknowledge that AWS CloudFormation might require the following capability: CAPABILITY_AUTO_EXPAND

Wait for the CloudFormation status to change to CREATE_COMPLETE.

Launch using Customizations for Control Tower

Customizations for AWS Control Tower combines AWS Control Tower and other highly available, trusted AWS services to help customers set up a secure, multiaccount AWS environment according to AWS best practices. You can add customizations to your AWS Control Tower landing zone using an AWS CloudFormation template and service control policies (SCPs). You can deploy the custom template and policies to individual accounts and organizational units (OUs) within your organization.

CfCT also integrates with AWS Control Tower lifecycle events to hlep ensure that resource deployments stay in sync with your landing zone. For example, when you create a new account using AWS Control Tower account factory, CfCT deploys all of the resources that are attached to the account.

The templates provided by this ABI package are deployable through CfCT.

Prerequisites

The CfCT solution can’t launch resources in the management account by default. You need select pCreateAWSControlTowerExecutionRole : true to allow the stack to create the role or must manually create a role in that account that has necessary permissions.

How it works

To deploy this sample partner integration page using CfCT, add the following blurb to the manifest.yaml file from your CfCT solution and update the account names as needed.

resources:
  - name: deepwatch-logging-top-level
    resource_file: https://aws-abi.s3.us-east-1.amazonaws.com/cfn-abi-deepwatch-mdr/templates/deepwatch-root-stack.yaml
    deploy_method: stack_set
    parameters:
      - parameter_key: pSRASourceS3BucketName
        parameter_value: aws-abi
      - parameter_key: pSRAS3BucketRegion
        parameter_value: us-east-1
      - parameter_key: pAutoEnableS3Logs
        parameter_value: 'true'
      - parameter_key: pAutoEnableKubernetesAuditLogs
        parameter_value: 'false'
      - parameter_key: pAutoEnableMalwareProtection
        parameter_value: 'false'
      - parameter_key: pDeepwatchRoleName
        parameter_value: 'deepwatch-mdr-role'
      - parameter_key: pEnableLambdaDataEvents
        parameter_value: 'false'
      - parameter_key: pEnableS3DataEvents
        parameter_value: 'true'
    deployment_targets:
      accounts:
        - [[MANAGEMENT-AWS-ACCOUNT-ID]]

Next: Postdeployment options

Postdeployment options

Verifying the solution’s functionality

Wait for the stack to finish deploying. You can check the status of the deployment either via the AWS console or by running the following command:

aws cloudformation describe-stacks --stack-name <YOUR_STACK_NAME>

The stack status is returned in the output. Wait until the status is CREATE_COMPLETE before proceeding to the next step. When the stack finishes deploying, you can access the created resources via the AWS Management Console or AWS CLI.

After the deployment completes, you will see the root stack and nested stacks in the AWS Control Tower management account with status CREATE_COMPLETE. Control Tower Manager Account Stacks Control Tower Manager Account Stacks

After you deploy the solution, provide your Deepwatch security engineer expert the output values of the StackSet-deepwatch-logging-resource-configuration-*uuid* stack. These values will be needed to finish setting up ingestion:

  • oCloudTrailQueueArn
  • oGuardDutyQueueArn
  • oDeepwatchRoleArn

Control Tower log archive account stacks Control Tower log archive account stacks

Next: Additonal resources

Test the deployment

Step-1

Step-2

Step-3

Next: See Additional resources to explore more documentation and references.

Notices

This document is provided for informational purposes only. It represents current AWS product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS products or services, each of which is provided “as is” without warranty of any kind, whether expressed or implied. This document does not create any warranties, representations, contractual commitments, conditions, or assurances from AWS, its affiliates, suppliers, or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.

The software included with this paper is licensed under the Apache License, version 2.0 (the “License”). You may not use this file except in compliance with the License. A copy of the License is located at http://aws.amazon.com/apache2.0/ or in the accompanying “license” file. This code is distributed on an “as is” basis, without warranties or conditions of any kind, either expressed or implied. Refer to the License for specific language governing permissions and limitations.

Cleanup instructions

After trying this AWS Built-in solution, you may want to redeploy or remove it completely. In either case, this solution leaves certain resources as-is when you delete the stacks that are deployed. This behavior is working as designed to avoid deleting the history of data collections in your accounts.

You can clean up resources created this AWS Built-in solution to avoid incurring charges for resources created and avoid conflicts while redeploying the stack.

This section provides instructions to clean up the resources created by the AWS Built-in package.

1. Delete the CloudFormation stack

  1. Navigate to the AWS CloudFormation console.
  2. Choose the stack created by the AWS Built-in solution and delete it.
  3. Wait for the DELETE_COMPLETE status to confirm the stack deletion.

2. Delete resources created by the AWS Built-in solution

Automated cleanup (PLEASE REVIEW the manual cleanup steps below for resources that deleted by the automated cleanup)

Establish a session to the management account and run the following command:

cd ${REPO_ROOT}/scripts
python3 cleanup_config.py -C cleanup_config.json

Note-1: The automated cleanup script will not delete all the stacks. You still need to delete the stacks *CloudTrailStack* and *GuardDutyStack* manually (if exists).

Note-2: If you choose pDisableGuardDuty as No (default) during the installation of the solution, you need to delete the guardduty detector in all regions.

Manual cleanup.

In the management account:

  1. Delete the following Amazon S3 buckets.
  • sra-gd-staging-<account-id>-<region>
  • sra-cloudtrail-staging-<account-id>-<region>
  • sra-helper-<account-id>-<region>
  • sra-staging-<account-id>-<regions> # Repeat for all regions where the solution is deployed.
  1. Delete Systems Manager parameters that start with below prefixes. Repeat for all active regions.
  • /sra/regions/
  • /sra/control-tower/
  • /sra/staging-s3-bucket-name
  1. Delete the AWS CloudWatch log groups that start with the following prefixes:
  • /sra/sra-org-trail
  • /aws/lambda/sra-codebuild-project-lambda
  • /aws/lambda/sra-guardduty-codebuild-project-lambda
  1. Delete a build project in AWS CodeBuild that start with the following prefixes.
  • sra-codebuild-project
  1. Delete AWS IAM roles that are listed below.
  • sra-execution

  1. Delete a stack set with name sra-stackset-execution-role.

  2. Delete a stack with follwing stack names:

  • sra-common-prerequisites-staging-s3-bucket
  • *CloudTrailStack*
  • *GuardDutyStack*
  1. Delete GuardDuty detectors in all regions (Only if you choose pDisableGuardDuty as No during the installation of the solution).

In the log archive account:

  1. Delete the following Amazon S3 buckets.
  • sra-guardduty-org-delivery-<account-id>-<region>
  • sra-org-trail-logs-<account-id>-<region>
  1. Delete Systems Manager parameters that start with below prefixes. Repeat for all active regions.
  • /sra/regions/
  • /sra/control-tower/
  1. Delete the AWS CloudWatch log groups that start with the following prefixes:
  • /aws/lambda/sra-ct-s3
  • /aws/lambda/sra-gd-s3
  • /sra/gd/
  1. Delete AWS IAM roles that are listed below.
  • sra-execution

In the audit account:

  1. Delete AWS IAM roles that are listed below.
  • sra-execution

FAQs

How can I contribute to this repository?

The repository is shared under Apache license version 2.0 (the “License”). For issues and improvement suggestions, submit a GitHub issue. If you want to build and contribute a fix or enhancement, submit a GitHub pull request.

All pull requests are validated by AWS before being merged.