Cloud 101CircleEventsBlog
Register for CSA's free and virtual Global AI Symposium, October 22-24, for cutting-edge insights on AI and cloud security. 

Incident Response in Cloud Security

Incident Response in Cloud Security

Blog Article Published: 07/25/2024

Written by Ashwin Chaudhary, CEO, Accedere.


Computer security incident response has become an important component of information technology (IT) programs. Cybersecurity-related attacks have become not only more numerous and diverse but also more damaging and disruptive. New types of security-related incidents emerge frequently. Preventive activities based on the results of risk assessments can lower the number of incidents, but not all incidents can be prevented.

An incident response capability is therefore necessary for rapidly detecting incidents, minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring IT services Incident Response (IR) is a critical facet of any information security program. Preventive security controls have proven unable to completely eliminate the possibility that critical data could be compromised.

Most organizations have some sort of IR plan to govern how they will investigate an attack, but as the cloud presents distinct differences in both access to forensic data and governance, organizations must consider how their IR processes will change. Cloud Security Alliance's Security Guidance v5 covers incident response in domain 11.

According to NIST 800-61rev2, an event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt.

A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. Examples of incidents are: An attacker commands a botnet to send high volumes of connection requests to a web server, causing it to crash, Users are tricked into opening a “quarterly report” sent via email that is actually malware; running the tool has infected their computers and established connections with an external host, An attacker obtains sensitive data and threatens that the details will be released publicly if the organization does not pay a designated sum of money. A user provides or exposes sensitive information to others through peer-to-peer file sharing services.

Attacks frequently compromise personal and business data, and it is critical to respond quickly and effectively when security breaches occur. The concept of computer security incident response has become widely accepted and implemented. One of the benefits of having an incident response capability is that it supports responding to incidents systematically (i.e., following a consistent incident handling methodology) so that the appropriate actions are taken.

  • Incident response helps personnel to minimize loss or theft of information and disruption of services caused by incidents.
  • Another benefit of incident response is the ability to use information gained during incident handling to better prepare for handling.

The Incident Response Lifecycle is defined in the NIST 800-61rev2 Computer Security Incident Handling Guide document. It includes the following phases and major activities:

  • Preparation: “Establishing an incident response capability so that the organization is ready to respond to incidents.”
    • Process to handle the incidents.
    • Handler communications and facilities.
    • Incident analysis hardware and software.
    • Internal documentation (port lists, asset lists, network diagrams, current baselines of network traffic).
    • Identifying training.
    • Evaluating infrastructure by proactive scanning and network monitoring, vulnerability assessments, and performing risk assessments.
    • Subscribing to third-party threat intelligence services.
  • Detection and Analysis
    • Alerts [endpoint protection, network security monitoring, host monitoring, account creation, privilege escalation, other indicators of compromise, SIEM, security analytics (baseline and anomaly detection), and user behavior analytics].
    • Validate alerts (reducing false positives) and escalation.
    • Estimate the scope of the incident.
    • Assign an Incident Manager who will coordinate further actions.
    • Designate a person who will communicate the incident containment and recovery status to senior management.
    • Build a timeline of the attack.
    • Determine the extent of the potential data loss.
    • Notification and coordination activities.
  • Containment, Eradication and Recovery
    • Containment: Taking systems offline. Considerations for data loss versus service availability. Ensuring systems don’t destroy themselves upon detection.
    • Eradication and Recovery: Clean up compromised devices and restore systems to normal operation. Confirm systems are functioning properly. Deploy controls to prevent similar incidents.
    • Documenting the incident and gathering evidence (chain of custody).
  • Post-mortem
    • What could have been done better? Could the attack have been detected sooner? What additional data would have been helpful to isolate the attack faster? Does the IR process need to change? If so, how?


Security Considerations
  • SLAs and setting expectations around what the customer does versus what the provider does are the most important aspects of incident response for cloud-based resources. Clear communication of roles/responsibilities and practicing the response and hand-offs are critical.
  • Cloud customers must set up proper communication paths with the provider that can be utilized in the event of an incident. Existing open standards can facilitate incident communication.
  • Cloud customers must understand the content and format of data that the cloud provider will supply for analysis purposes and evaluate whether the available forensics data satisfies legal chain of custody requirements.
  • Cloud customers should also embrace continuous and serverless monitoring of cloud-based resources to detect potential issues earlier than in traditional data centers. Data sources should be stored or copied into locations that maintain availability during incidents. If needed and possible, they should also be handled to maintain a proper chain of custody.
  • Cloud-based applications should leverage automation and orchestration to streamline and accelerate the response, including containment and recovery.
  • For each cloud service provider used, the approach to detecting and handling incidents involving the resources hosted at that provider must be planned and described in the enterprise incident response plan.
  • The SLA with each cloud service provider must guarantee support for the incident handling required for the effective execution of the enterprise incident response plan. This must cover each stage of the incident handling process: detection, analysis, containment, eradication, and recovery.
  • Testing will be conducted at least annually or whenever there are significant changes to the application architecture. Customers should seek to integrate their testing procedures with that of their provider (and other partners) to the greatest extent possible.



About the Author

Ashwin Chaudhary is the CEO of Accedere, a Data Security, Privacy Audit, and Training Firm. He is a CPA from Colorado, MBA, CITP, CISA, CISM, CGEIT, CRISC, CISSP, CDPSE, CCSK, PMP, ISO27001 LA, ITILv3 certified cybersecurity professional with about 20 years of cybersecurity/privacy and 40 years of industry experience. He has managed many cybersecurity projects covering SOC reporting, ISO audits, VAPT assessments, Privacy, IoT, Governance Risk, and Compliance.

Share this content on your favorite social network today!