fbpx

How exactly to automate incident reaction to security activities with AWS Systems Supervisor Incident Manager

Incident response is really a core security capability for organizations to build up, and a core aspect in the AWS Cloud Adoption Framework (AWS CAF) . Giving an answer to security incidents quickly is essential to reduce their impacts. Automating incident response can help you scale your capabilities, rapidly decrease the scope of compromised resources, and reduce repetitive work by your security team.

In this article, I demonstrate how exactly to use Incident Manager, a capacity for AWS Systems Manager, to create a highly effective automated incident management and response treatment for security events.

 

You’ll walk through three common security-related events and ways to use Incident Manager to automate your response.

  • AWS account root user activity: An Amazon Web Services (AWS) account root user has full usage of all your resources for several AWS services, including billing information. It’s therefore elemental to stick to the best practice of utilizing the root user and then create your first IAM user and securely lock away the main user credentials and utilize them to perform just a few account and service management tasks. Which is critical to keep yourself updated when root user activity occurs in your AWS account.
  • Amazon GuardDuty high severity findings: Amazon GuardDuty is really a threat detection service that continuously monitors for malicious or unauthorized behavior to greatly help protect your AWS accounts and workloads. In this website post, you’ll learn to initiate an incident response plan every time a high severity finding is discovered.
  • AWS Config rule change and S3 bucket allowing public access: AWS Config enables continuous tabs on your AWS resources, rendering it easy to assess, audit, and record resource changes and configurations. You’ll use AWS Config to monitor your Amazon Simple Storage Service (S3) bucket policies and ACLs for settings that allow public read or public write access.

Prerequisites

If that is your first-time using Incident Manager, follow the original onboarding steps in Getting prepared with Incident Manager.

Incident Manager can begin managing incidents automatically using Amazon CloudWatch or Amazon EventBridge. For the perfect solution is in this website post, you’ll use EventBridge to fully capture events and begin an incident.

To perform the steps in this walkthrough, you will need the next:

Create an Incident Manager response plan

A reply plan ties together the contacts, escalation plan, and runbook. When an incident occurs, a reply plan defines who to activate, how exactly to engage, which runbook to initiate, and which metrics to monitor. By developing a well-defined response plan, it is possible to save your valuable security team time later on.

Add contacts

Your contacts will include everyone who may be mixed up in incident. Follow these steps to include a contact.

To include contacts

  1. Open the AWS Management Console, and then head to Systems Manager within the console, expand Operations Management, and expand&amp then;nbsp;Incident Manager.
  2. Choose Contacts, and choose&amp then;nbsp;Create contact.

    Figure 1: Adding contact details

    Figure 1: Adding contact details

  3. On Contact information, enter names and define contact channels for the contacts.
  4. Under Contact channel, it is possible to select Email, SMS, or Voice. You can even add multiple contact channels.
  5. In Engagement plan, specify how fast to activate your responders. In the example below illustrated, the incident responder will undoubtedly be engaged through email immediately (0 minutes) when an incident is detected and through SMS ten minutes into an incident. Complete the fields and choose Create.

    Figure 2: Engagement plan

    Figure 2: Engagement plan

Develop a response plan

Once you’ve created your contacts, it is possible to create a response intend to define how to react to incidents. Make reference to the GUIDELINES for Response Plans.

Note: (Optional) You can even create an escalation plan that enables you to further define the escalation path for the contacts. You can find out more in Create an escalation plan.

To make a response plan

  1. Open the Incident Manager console, and choose Response plans in the left navigation pane.
  2. Choose Create response plan.
  3. Enter a distinctive and identifiable name for the response plan.
  4. Enter an incident title. The incident title really helps to identify an incident on the incidents website.
  5. Select a proper Impact in line with the potential scope of the incident.

    Figure 3: Selecting your impact level

    Figure 3: Selecting your impact level

  6. (Optional) Select a chat channel for the incident responders to interact in during an incident. To find out more about chat channels, see Chat channels.
  7. (Optional) For Engagement, you can choose a variety of contacts and escalation plans. For this solution, choose the security team responder that you created earlier as you of your contacts.

    Figure 4: Adding engagements

    Figure 4: Adding engagements

  8. (Optional) You can even create a runbook that may drive the incident mitigation and response. For more info, make reference to Automation&lt and runbooks;/a>.
  9. Under Execution permissions, choose Create an IAM role utilizing a template. Under Role name, choose the IAM role you created in the prerequisites which allows Incident Manager to perform SSM automation documents, and choose &lt then;strong>Create response plan.

Monitor AWS account root activity

When you initially create an AWS account, you begin with an individual sign-in identity which has complete usage of all AWS services and resources in the account. This identity is named the main user and is accessed by signing in with the e-mail address and password that you used to generate the account.

An AWS account root user has full usage of all your resources for several AWS services, including billing information. It is advisable to prevent root user access from unauthorized use also to take note whenever root user activity occurs in your AWS account. To find out more about AWS recommendations, see Security guidelines in IAM.

To be sure that root user activity is authorized and expected, it’s vital that you monitor root API calls to confirmed AWS account also to be notified when root user activity is detected.

Create an EventBridge rule

Create and validate an EventBridge rule to fully capture AWS account root activity.

To generate an EventBridge rule

  1. Open the EventBridge console.
  2. In the navigation pane, choose Rules, and choose Create rule.
  3. Enter a true name and description for the rule.
  4. For Define pattern, choose Event pattern.
  5. Choose Custom pattern.
  6. Enter the next event pattern:
    
         

    “detail-type”: [
    “AWS API Call via CloudTrail”,
    “AWS Console REGISTER via CloudTrail”
    ],
    “detail”:
    “userIdentity”:
    “type”: [
    “Root”
    ]

  7. For Select targets, choose Incident Manager response plan.
  8.  

  9. For Response plan, choose SecurityEventResponsePlan, that you created when you setup Incident Manager.
  10.  

  11. To generate an IAM role automatically, choose Develop a new role because of this specific resource. To utilize a preexisting IAM role, choose Use existing role.
  12.  

  13. (Optional) Enter a number of tags for the rule.
  14.  

  15. Choose Create.
  16.  

    To validate the rule

    1. Register using root credentials.
    2. This console login activity by way of a root user should invoke the Incident Manager response plan and show an open incident as illustrated below. The respective contact channels that you defined in your &lt earlier;strong>Engagement Plan, will undoubtedly be engaged.

    Figure 5: Incident Manager open incidents

    Figure 5: Incident Manager open incidents

    Watch out for GuardDuty high severity findings

    GuardDuty is really a monitoring service that analyzes AWS CloudTrail amazon and management S3 data events, Amazon Virtual Private Cloud (Amazon VPC) flow logs, and Amazon Route 53 DNS logs to create security findings for the account. GuardDuty is enabled once, it starts monitoring your environment immediately.

    GuardDuty integrates with EventBridge, which may be used to send findings data to other applications and services for processing. With EventBridge, you should use GuardDuty findings to invoke automatic responses to your findings by connecting finding events to targets such as for example Incident Manager response plan.

    Create an EventBridge rule

    You’ll use an EventBridge rule to fully capture GuardDuty high severity findings.

    To generate an EventBridge rule

    1. Open the EventBridge console.
    2. In the navigation pane, select Rules, and choose Create rule.
    3. Enter a name and description for the rule.
    4. For Define pattern, choose Event pattern.
    5. Choose Custom pattern
    6. Enter the next event pattern that may filter on GuardDuty high severity findings
      
           

      “source”: [“aws.guardduty”],
      “detail-type”: [“GuardDuty Finding”],
      “detail”:
      “severity”: [
      7.0,
      7.1,
      7.2,
      7.3,
      7.4,
      7.5,
      7.6,
      7.7,
      7.8,
      7.9,
      8,
      8.0,
      8.1,
      8.2,
      8.3,
      8.4,
      8.5,
      8.6,
      8.7,
      8.8,
      8.9
      ]

       
    7. For Select targets , choose Incident Manager response plan .
    8. For Response plan , select SecurityEventResponsePlan , that you created when you create Incident Manager.
    9. To generate an IAM role automatically, choose Develop a new role because of this specific resource . To utilize an IAM role that you made before, choose Use existing role .
    10. (Optional) Enter a number of tags for the rule.
    11. Choose Create .

    To validate the rule

    To check and validate if the above rule is currently functional, you will generate sample findings within the GuardDuty console.

    1. Open the GuardDuty console .
    2. In the navigation pane, choose  Settings .
    3. On the  Settings  page, under  Sample findings , choose  Generate sample findings .
    4. In the navigation pane, choose  Findings . The sample findings are displayed on the  Current findings  page with the prefix  [SAMPLE].

    Once you’ve generated sample findings, your Incident Manager response plan will undoubtedly be invoked almost immediately and the engagement plan together with your contacts will begin.

    It is possible to select an open incident in the Incident Manager console to see additional details from the GuardDuty finding. Figure 6 shows a higher severity finding.

    Figure 6: Incident Manager open incident for GuardDuty high severity finding

    Figure 6: Incident Manager open incident for GuardDuty high severity finding

    Monitor S3 bucket settings for public access

    AWS Config enables continuous tabs on your AWS resources, rendering it better to assess, audit, and record resource configurations and changes. AWS Config does this through rules define the required configuration state of one’s AWS resources. AWS Config offers a amount of AWS managed rules that address an array of security concerns such as for example checking your Amazon Elastic Block Store (Amazon EBS) volumes are encrypted, your resources appropriately are tagged, and multi-factor authentication (MFA) is enabled for root accounts.

    Setup AWS Config and EventBridge

    You’ll use AWS Config to monitor your S3 bucket ACLs and policies for violations that could allow public read or public write access. If AWS Config finds an insurance plan violation, it’ll initiate an AWS EventBridge rule to invoke your Incident Manager response plan.

    To generate the AWS Config rule to fully capture S3 bucket public access

    1. Register to the  AWS Config console .
    2. If that is your first-time in the AWS Config console, make reference to the STARTING OUT guide to find out more.
    3. Select Rules from the menu and choose Add Rule .
    4. On the AWS Config rules page, enter S3 in the search box and choose the  s3-bucket-public-read-prohibited  and  s3-bucket-public-write-prohibited  rules, and choose&nbsp then; Next .

      Figure 7: AWS Config rules

      Figure 7: AWS Config rules

    5. Leave the Configure rules page as default and choose Next .
    6. On the  Review  page, select  Add Rule . AWS Config is currently analyzing your S3 buckets, capturing their current configurations, and evaluating the configurations contrary to the rules you selected.

    To generate the EventBridge rule

    1. Open the Amazon EventBridge console
    2. In the navigation pane, choose Rules , and choose Create rule .
    3. Enter a genuine name and description for the rule.
    4. For Define pattern , choose Event pattern .
    5. Choose Custom pattern
    6. Enter the next event pattern, that will filter on AWS Config rule s3-bucket-public-write-prohibited being non-compliant.
           
      

      “source”: [“aws.config”],
      “detail-type”: [“Config Rules Compliance Change”],
      “detail”:
      “messageType”: [“ComplianceChangeNotification”],
      “configRuleName”: [“s3-bucket-public-write-prohibited”, “”],
      “newEvaluationResult”:
      “complianceType”: [
      “NON_COMPLIANT”
      ]

       
    7. For Select targets , choose Incident Manager response plan .
    8. For Response plan , choose SecurityEventResponsePlan , that you created earlier when establishing Incident Manager.
    9. To generate an IAM role automatically, choose Develop a new role because of this specific resource . To utilize a preexisting IAM role, choose Use existing role .
    10. (Optional) Enter a number of tags for the rule.
    11. Choose Create .

    To validate the rule

    1. Develop a compliant test S3 bucket without public read or write access through either an ACL or perhaps a policy.
    2. Change the ACL of the bucket to permit public report on objects so the bucket is non-compliant.

      Figure 8: Amazon S3 console

      Figure 8: Amazon S3 console

    3. After a short while, you should start to see the AWS Config rule initiated which invokes the EventBridge rule and for that reason your Incident Manager response plan.

    Summary

    In this article, I showed you how exactly to use Incident Manager to monitor for security events and invoke a reply plan via Amazon CloudWatch or Amazon EventBridge. AWS CloudTrail API activity (for a root account login), Amazon GuardDuty (for high severity findings), and AWS Config (to enforce policies like preventing public write usage of an S3 bucket). I demonstrated ways to create an incident management and response intend to ensure you purchased the energy of cloud to generate automations that react to and mitigate security incidents regularly. For more information about Incident Manager, see WHAT’S AWS Systems Manager Incident Manager in the AWS documentation.

    When you have feedback concerning this post, submit comments in the comments section below. When you have questions concerning this post, take up a new thread on the  Systems Manager forum  or  contact AWS Support .

    Want more AWS Security how-to content, news, and show announcements? Follow us on Twitter .