Jaa


Security Control: Incident response

Incident Response covers controls in incident response life cycle - preparation, detection and analysis, containment, and post-incident activities, including using Azure services (such as Microsoft Defender for Cloud and Sentinel) and/or other cloud services to automate the incident response process.

IR-1: Preparation - update incident response plan and handling process

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
17.4, 17.7 IR-4, IR-8 10.8

Security principle: Ensure your organization follows industry best practice to develop processes and plans to respond to security incidents on the cloud platforms. Be mindful about the shared responsibility model and the variances across IaaS, PaaS, and SaaS services. This will have a direct impact on how you collaborate with your cloud provider in incident response and handling activities, such as incident notification and triage, evidence collection, investigation, eradication, and recovery.

Regularly test the incident response plan and handling process to ensure they're up to date.


Azure guidance: Update your organization's incident response process to include the handling of incidents in the Azure platform. Based on the Azure services used and your application nature, customize the incident response plan and playbook to ensure they can be used to respond to the incident in the cloud environment.

Azure implementation and additional context:


AWS guidance: Update your organization's incident response process to include the handling of incidents. Ensure a unified multi-cloud incident response plan is in place by updating your organization's incident response process to include the handling of incidents in the AWS platform. Based on the AWS services used and your application nature, follow the AWS Security Incident Response Guide to customize the incident response plan and playbook to ensure they can be used to respond to the incident in the cloud environment.

AWS implementation and additional context:


GCP guidance: Update your organization's incident response process to include the handling of incidents. Ensure a unified multi-cloud incident response plan is in place by updating your organization's incident response process to include the handling of incidents in the Google Cloud platform.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

IR-2: Preparation - setup incident notification

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
17.1, 17.3, 17.6 IR-4, IR-8, IR-5, IR-6 12.10

Security principle: Ensure the security alerts and incident notifications from the cloud service provider's platform and your environments can be received by correct contact in your incident response organization.


Azure guidance: Set up security incident contact information in Microsoft Defender for Cloud. This contact information is used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. You also have options to customize incident alerts and notification in different Azure services based on your incident response needs.

Azure implementation and additional context:


AWS guidance: Set up security incident contact information in AWS Systems Manager Incident Manager (the incident management center for AWS). This contact information is used for incident management communication between you and AWS through the different channels (i.e., Email, SMS, or Voice). You can define a contact's engagement plan and escalation plan to describe how and when the Incident Manager engages the contact and to escalate if the contact(s) does not response to an incident.

AWS implementation and additional context:


GCP guidance: Set up security incident notifications for particular contacts using Security Command Center or Chronicle. Use Google Cloud services and third-party APIs to provide real-time email and chat notification to alert of security findings for Security Command Center, or playbooks to trigger actions to send notifications in Chronicle.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

IR-3: Detection and analysis - create incidents based on high-quality alerts

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
17.9 IR-4, IR-5, IR-7 10.8

Security principle: Ensure you have a process to create high-quality alerts and measure the quality of alerts. This allows you to learn lessons from past incidents and prioritize alerts for analysts, so they don't waste time on false positives.

High-quality alerts can be built based on experience from past incidents, validated community sources, and tools designed to generate and clean up alerts by fusing and correlating diverse signal sources.


Azure guidance: Microsoft Defender for Cloud provides high-quality alerts across many Azure assets. You can use the Microsoft Defender for Cloud data connector to stream the alerts to Microsoft Sentinel. Microsoft Sentinel lets you create advanced alert rules to generate incidents automatically for an investigation.

Export your Microsoft Defender for Cloud alerts and recommendations using the export feature to help identify risks to Azure resources. Export alerts and recommendations either manually or in an ongoing, continuous fashion.

Azure implementation and additional context:


AWS guidance: Use security tools like SecurityHub or GuardDuty and other third-party tools to send alerts to Amazon CloudWatch or Amazon EventBridge so incidents can be automatically created in Incident Manager based on the defined criteria and rule sets. You can also manually create incidents in the Incident Manager for further incident handling and tracking.

If you use Microsoft Defender for Cloud to monitor your AWS accounts, you can also use Microsoft Sentinel to monitor and alert the incidents identified by Microsoft Defender for Cloud on AWS resources.

AWS implementation and additional context:


GCP guidance: Integrate Google Cloud and third-party services to send logs and alerts to Security Command Center or Chronicle so incidents can be automatically created based on defined criteria. You can also manually create and edit incident findings in Security Command Center or rules in Chronicle for further incident handling and tracking.

If you use Microsoft Defender for Cloud to monitor your GCP projects, you can also use Microsoft Sentinel to monitor and alert the incidents identified by Microsoft Defender for Cloud on GCP resources, or stream GCP logs directly into Microsoft Sentinel.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

IR-4: Detection and analysis - investigate an incident

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/A IR-4 12.10

Security principle: Ensure the security operation team can query and use diverse data sources as they investigate potential incidents, to build a full view of what happened. Diverse logs should be collected to track the activities of a potential attacker across the kill chain to avoid blind spots. You should also ensure insights and learnings are captured for other analysts and for future historical reference.

Use the cloud native SIEM and incident management solution if your organization does not have an existing solution to aggregate security logs and alerts information. Correlate incident data based on the data sourced from different sources to facility the incident investigations.


Azure guidance: Ensure your security operations team can query and use diverse data sources that are collected from the in-scope services and systems. In addition, it sources can also include:

  • Identity and access log data: Use Azure AD logs and workload (such as operating systems or application level) access logs for correlating identity and access events.
  • Network data: Use network security groups' flow logs, Azure Network Watcher, and Azure Monitor to capture network flow logs and other analytics information.
  • Incident related activity data of from snapshots of the impacted systems, which can be obtained through:
    • The azure virtual machine's snapshots capability, to create a snapshot of the running system's disk.
    • The operating system's native memory dump capability, to create a snapshot of the running system's memory.
    • The snapshot feature of other supported Azure services or your software's own capability, to create snapshots of the running systems.

Microsoft Sentinel provides extensive data analytics across virtually any log source and a case management portal to manage the full lifecycle of incidents. Intelligence information during an investigation can be associated with an incident for tracking and reporting purposes.

Note: When incident related data is captured for investigation, ensure there is adequate security in place to protect the data from unauthorized alteration, such as disabling logging or removing logs, which can be performed by the attackers during an in-flight data breach activity.

Azure implementation and additional context:


AWS guidance: The data sources for investigation are the centralized logging sources that collect from the in-scope services and running systems, but can also include:

  • Identity and access log data: Use IAM logs and workload (such as operating systems or application level) access logs for correlating identity and access events.
  • Network data: Use VPC Flow Logs, VPC Traffic Mirrors, and Azure CloudTrail and CloudWatch to capture network flow logs and other analytics information.
  • Snapshots of running systems, which can be obtained through:
    • Snapshot capability in Amazon EC2(EBS) to create a snapshot of the running system's disk.
    • The operating system's native memory dump capability, to create a snapshot of the running system's memory.
    • The snapshot feature of the AWS services or your software's own capability, to create snapshots of the running systems.

If you aggregate your SIEM related data into Microsoft Sentinel, it provides extensive data analytics across virtually any log source and a case management portal to manage the full lifecycle of incidents. Intelligence information during an investigation can be associated with an incident for tracking and reporting purposes.

Note: When incident related data is captured for investigation, ensure there is adequate security in place to protect the data from unauthorized alteration, such as disabling logging or removing logs, which can be performed by the attackers during an in-flight data breach activity.

AWS implementation and additional context:


GCP guidance: The data sources for investigation are the centralized logging sources that collect from the in-scope services and running systems, but can also include:

  • Identity and access log data: Use IAM logs and workload (such as operating systems or application level) access logs for correlating identity and access events.
  • Network data: Use VPC Flow Logs and VPC service controls to capture network flow logs and other analytics information.
  • Snapshots of running systems, which can be obtained through:
    1. Snapshot capability in GCP VMs to create a snapshot of the running system's disk.
    2. The operating system's native memory dump capability, to create a snapshot of the running system's memory.
    3. The snapshot feature of the GCP services or your software's own capability, to create snapshots of the running systems.

If you aggregate your SIEM related data into Microsoft Sentinel, it provides extensive data analytics across virtually any log source and a case management portal to manage the full lifecycle of incidents. Intelligence information during an investigation can be associated with an incident for tracking and reporting purposes.

Note: When incident related data is captured for investigation, ensure there is adequate security in place to protect the data from unauthorized alteration, such as disabling logging or removing logs, which can be performed by the attackers during an in-flight data breach activity.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

IR-5: Detection and analysis - prioritize incidents

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
17.4, 17.9 IR-4 12.10

Security principle: Provide context to security operations teams to help them determine which incidents ought to first be focused on, based on alert severity and asset sensitivity defined in your organization’s incident response plan.

Additionally, mark resources using tags and create a naming system to identify and categorize your cloud resources, especially those processing sensitive data. It is your responsibility to prioritize the remediation of alerts based on the criticality of the resources and environment where the incident occurred.


Azure guidance: Microsoft Defender for Cloud assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Microsoft Defender for Cloud is in the finding or the analytics used to issue the alert, as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Similarly, Microsoft Sentinel creates alerts and incidents with an assigned severity and other details based on analytics rules. Use analytic rule templates and customize the rules according to your organization's needs to support incident prioritization. Use automation rules in Microsoft Sentinel to manage and orchestrate threat response in order to maximize your security operation's team efficiency and effectiveness, including tagging incidents to classify them.

Azure implementation and additional context:


AWS guidance: For each incident created in the Incident Manager, assign an impact level based on your organization's defined criteria, such as a measure of the severity of the incident and criticality level of the assets impacted.

AWS implementation and additional context:


*GCP guidance: For each incident created in Security Command Center, determine the priority of the alert based on the severity ratings assigned by the system and other criteria defined by your organization. Measure the severity of the incident and criticality level of the assets impacted to determine which alerts should be investigated first.

Similarly in Chronical, you can define custom rules to determine the your incident response priorities. GCP implementation and additional context:


Customer security stakeholders (Learn more):

IR-6: Containment, eradication and recovery - automate the incident handling

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/A IR-4, IR-5, IR-6 12.10

Security principle: Automate the manual, repetitive tasks to speed up response time and reduce the burden on analysts. Manual tasks take longer to execute, slowing each incident and reducing how many incidents an analyst can handle. Manual tasks also increase analyst fatigue, which increases the risk of human error that causes delays and degrades the ability of analysts to focus effectively on complex tasks.


Azure guidance: Use workflow automation features in Microsoft Defender for Cloud and Microsoft Sentinel to automatically trigger actions or run a playbooks to respond to incoming security alerts. Playbooks take actions, such as sending notifications, disabling accounts, and isolating problematic networks.

Azure implementation and additional context:


AWS guidance: If you use Microsoft Sentinel to centrally manage your incident, you can also create automated actions or run a playbooks to respond to incoming security alerts.

Alternatively, use automation features in AWS System Manager to automatically trigger actions defined in the incident response plan, including notifying the contacts and/or running a runbook to respond to alerts, such as disabling accounts, and isolating problematic networks.

AWS implementation and additional context:


GCP guidance: If you use Microsoft Sentinel to centrally manage your incident, you can also create automated actions or run playbooks to respond to incoming security alerts.

Alternatively, use Playbook automations in Chronicle to automatically trigger actions defined in the incident response plan, including notifying the contacts and/or running a playbook to respond to alerts.

GCP implementation and additional context:


Customer security stakeholders (Learn more):

IR-7: Post-incident activity - conduct lessons learned and retain evidence

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
17.8 IR-4 12.10

Security principle: Conduct lessons learned in your organization periodically and/or after major incidents, to improve your future capability in incident response and handling.

Based on the nature of the incident, retain the evidence related to the incident for the period defined in the incident handling standard for further analysis or legal actions.


Azure guidance: Use the outcome from the lessons learned activity to update your incident response plan, playbook (such as a Microsoft Sentinel playbook) and reincorporate findings into your environments (such as logging and threat detection to address any gaps in logging) to improve your future capability in detecting, responding, and handling of incidents in Azure.

Keep the evidence collected during the "Detection and analysis - investigate an incident step" such as system logs, network traffic dumps and running system snapshots in storage such as an Azure Storage account for immutable retention.

Azure implementation and additional context:


AWS guidance: Create incident analysis for a closed incident in Incident Manager using the standard incident analysis template or your own custom template. Use the outcome from the lessons learned activity to update your incident response plan, playbook (such as the AWS Systems Manager runbook and Microsoft Sentinel playbook) and reincorporate findings into your environments (such as logging and threat detection to address any gaps in logging) to improve your future capability in detecting, responding, and handling of the incidents in AWS.

Keep the evidence collected during the "Detection and analysis - investigate an incident step" such as system logs, network traffic dumps and running system snapshot in storage such as an Amazon S3 bucket or Azure Storage account for immutable retention.

AWS implementation and additional context:


GCP guidance: Use the outcome from the lessons learned activity to update your incident response plan, playbook (such as a Chronicle or Microsoft Sentinel playbook) and reincorporate findings into your environments (such as logging and threat detection to address any gaps in logging) to improve your future capability in detecting, responding, and handling of incidents in GCP.

Keep the evidence collected during the "Detection and analysis - investigate an incident step" such as system logs, network traffic dumps and running system snapshots in storage such as an Google Cloud Storage or an Azure Storage account for immutable retention.

GCP implementation and additional context:


Customer security stakeholders (Learn more):