Cloud incident response: Frameworks and best practices

Incident response planning and the development of incident handling procedures are core to any effective information security program. As enterprise cloud use becomes more ubiquitous, it's more important than ever to include the cloud in the incident response process.

What is cloud incident response?

Incident response, in general, encompasses plans, processes and controls that help organizations prepare for, detect, analyze and recover from an incident.

Cloud incident response is no different. Organizations still need plans, procedures and controls that facilitate incident detection and response actions. The infrastructure, however, has changed. Many organizations use cloud service providers (CSPs) for private and public cloud deployments, as well as a variety of SaaS, IaaS and PaaS. How cloud incident response is done, therefore, has some unique differences.

Cloud incident response vs. traditional incident response

Cloud deployments involve the shared responsibility model. This means some assets and services in the cloud may be wholly or partially managed by CSPs. If organizations experience an intrusion in a SaaS cloud, for example, incident response efforts may not be triggered due to limited investigation capabilities and little visibility or telemetry available related to events and indicators of compromise. Within a more diverse IaaS cloud, however, many objects and assets are under the control of the customer and are largely their responsibility.

Another difference is that many of the security tools and controls teams rely on within on-premises data centers are not always be the best fit for cloud environments. Some won't be compatible, for example, or have implementation or performance challenges. Other tools may not be attuned to cloud API calls and cloud working models to contextually detect attacks and intrusion indicators.

A third difference is that the entire cloud fabric is software-based. This means more emphasis is placed on using cloud-native services as guardrails and critical elements of the incident response workflow — for example, focusing primarily on automation and orchestration. Finally, new costs can arise with cloud log and event generation, as well as cloud security services.

Benefits and challenges of cloud incident response

The benefits of building a cloud incident response function are many, especially as growth in cloud deployments continues. The worst time to figure out how to respond to an incident, after all, is during an incident, so preparation is key. Having a sound cloud incident response strategy in place ensures teams can quickly and effectively respond to security incidents, which, in turn, means the following:

• preventing business disruption;
• reducing damage from incidents such as data breaches; and
• recovering quicker and more effectively from incidents.

The top challenges of cloud incident response include the following:

• shortage in skill sets;
• lack of familiarity with cloud-specific events, such as API calls and information to analyze and process; and
• failure to properly implement tools that provide deep visibility into cloud activity.

Cloud incident response framework

Incident response frameworks from NIST, ISO and SANS Institute, while not cloud-specific, are often used by organizations to create an incident response plan.

The Cloud Security Alliance offers a cloud-specific framework, which outlines the following four key phases:

1. Preparation and follow-on review. The preparation phase of cloud incident response includes tooling and controls implementation; staff training on cloud services, cloud security capabilities and cloud threats; and the creation of cloud response policies and playbooks. This phase involves everything done to enable a security team to handle cloud incidents before one occurs.
2. Detection and analysis. Organizations should monitor cloud service environments for potential indicators of attack and other disruptions or incidents. Track potential precursors — for example, notifications of new cloud attack vectors, cloud service vulnerabilities and known disruptions. In this phase, security teams detect adverse events that may indicate whether a full incident response effort is needed, as well as what the potential effect(s) may be to the cloud environment and the organization as a whole. Evidence artifacts also are gathered in this phase.
3. Containment, eradication and recovery. This phase focuses on several distinct goals. First, the response team should prevent the incident from spreading or getting worse. This may involve actions such as migrating to a different availability zone or region for improved continuity or isolating and quarantining assets behaving suspiciously or maliciously. Eradication involves eliminating or removing the root cause of the incident — for example, a malware-infected container image and runtime or a compromised account. Recovery means resuming normal business operations in the cloud environment.
4. Post-mortem. This phase is an opportunity to review what occurred during an incident to determine what worked well and what didn't, as well as how to prevent the incident type from reoccurring. This is an ideal time to coordinate with other teams and stakeholders, including cloud engineering, architecture, DevOps and application development teams, as well as CSPs. Also, use this phase to determine whether controls and processes properly detected and responded to events and incidents.

Best practices for cloud incident response

The following best practices should be considered when building and executing cloud incident response strategies:

• Send cloud incident response team members to CSP training. Familiarize the team with the types of services, objects, APIs, commands and other cloud-centric concepts they need to properly build a cloud incident response function.
• Have identity and access management and role-based access controls enabled for response teams. This is an important planning step. IT can't be expected to create a least privilege model for incident response analysts in the heat of battle. Create least privilege accounts to perform specific actions in the cloud when needed. Define a role for these, ideally for cross-account access. Enable multifactor authentication for these accounts.
• Enable write-once storage for logs and evidence. Do this ahead of time, even if evidence isn't currently stored in the cloud. For example, Amazon Simple Storage Service Versioning can be used for secure retention and recovery.
• Enable cloud-wide logging if available. Enable triggered metric-based alarms, such as Amazon CloudWatch or Azure Monitor.
• Enable cloud guardrail services to provide additional visibility and monitoring. Services such as Microsoft Defender for Cloud, Google Cloud Security Command Center, Amazon GuardDuty and AWS Security Hub, for example, may enable teams to use the CSP's native fabric to monitor assets, services and behaviors in cloud accounts and subscriptions.
• Ensure incident response tools are compatible with CSPs in use. For example, check that endpoint detection and response and workload forensics tools are capable of monitoring and alerting on attacks and malicious activity within PaaS systems, such as containers, Kubernetes and serverless.
• Include cloud service API integration and automation capabilities in workflows when building cloud incident response playbooks. It's easier to build automated if-then actions in the cloud than in on-premises data centers. Use readily available native tools to do this. An alert from GuardDuty, for example, could trigger a change to isolate the affected workload until the incident response team can investigate. GuardDuty could also trigger a AWS Lambda function or AWS Config rule that rebuilds the workload from an approved image. Similarly, automated acquisition of evidence artifacts — such as disk and memory or network packet captures in some cloud environments — can be enabled to save the incident response team time.
• Collaborate and align with cloud engineering and DevOps teams. Make sure cloud incident response playbooks and plans are designed to minimize production disruption wherever possible.