Security Control v3: 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 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 to 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 incident in 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.
Implementation and additional context:
- Implement security across the enterprise environment
- Incident response reference guide
- NIST SP800-61 Computer Security Incident Handling Guide
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 notification 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 alert and notification in different Azure services based on your incident response needs.
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 Azure Sentinel. Azure 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.
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 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.
Azure Guidance: The data sources for investigation are the centralized logging sources that are already being collected from the in-scope services and running systems, but can also include:
- Network data: Use network security groups' flow logs, Azure Network Watcher, and Azure Monitor to capture network flow logs and other analytics information.
- Snapshots of running systems: a) Azure virtual machine's snapshot capability, to create a snapshot of the running system's disk. b) The operating system's native memory dump capability, to create a snapshot of the running system's memory. c) The snapshot feature of the Azure services or your software's own capability, to create snapshots of the running systems.
Azure 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.
Implementation and additional context:
- Snapshot a Windows machine's disk
- Snapshot a Linux machine's disk
- Microsoft Azure Support diagnostic information and memory dump collection
- Investigate incidents with Azure Sentinel
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.
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.
Additionally, mark resources using tags and create a naming system to identify and categorize Azure resources, especially those processing sensitive data. It is your responsibility to prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the incident occurred.
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 Azure Sentinel to automatically trigger actions or run a playbook to respond to incoming security alerts. The playbook takes actions, such as sending notifications, disabling accounts, and isolating problematic networks.
Implementation and additional context:
- Configure workflow automation in Microsoft Defender for Cloud
- Set up automated threat responses in Microsoft Defender for Cloud
- Set up automated threat responses in Azure Sentinel
Customer Security Stakeholders (Learn more):
IR-7: Post-incident activity - conduct lesson 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 lesson 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 lesson learned activity to update your incident response plan, playbook (such as Azure Sentinel playbook) and reincorporate findings into your environments (such as logging and threat detection to address any logging gap areas) to improve your future capability in detecting, respond, and handling of the incident in Azure.
Keep the evidence collected during the "Detection and analysis - investigate an incident step" such as system logs, network traffic dump and running system snapshot in storage such as Azure Storage account for retention.
Implementation and additional context:
Customer Security Stakeholders (Learn more):