Cloud incident response: Frameworks and best practices

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 systems. 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 could be wholly or partially managed by CSPs. If organizations experience an intrusion in a SaaS cloud, for example, incident response efforts might 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 the best fit for cloud environments. Some aren't compatible, for example, or have implementation or performance challenges. Other tools might 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.

Cloud incident response benefits and challenges

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 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.
• 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.
• Failure to properly implement tools that provide deep visibility into cloud activity.
• Unfamiliarity with how cloud incidents differ from those within a traditional perimeter.
• Lack of access to physical servers, which presents a change in how forensic evidence is collected.

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 they occur.
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 might indicate whether a full incident response effort is needed, as well as what the potential effect(s) might 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 might 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. Use this phase to also determine whether controls and processes properly detected and responded to events and incidents.

Cloud incident response best practices

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 could 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 an AWS Lambda function or AWS Config rule that rebuilds the workload from an approved image. Similarly, enable automated acquisition of evidence artifacts, such as disk and memory or network packet captures in some cloud environments, to save the incident response team time.
• Collaborate and align with cloud engineering and DevOps teams. Design cloud incident response playbooks and plans to minimize production disruption wherever possible.

Dave Shackleford is founder and principal consultant with Voodoo Security; a SANS analyst, instructor and course author; and GIAC technical director.