Because of the nature of cloud computing, determining who to contact when a security incident, data breach, or other need for investigation and action occurs becomes more difficult. Standard security incident response mechanisms must be modified to meet the changing needs of the same reporting responsibilities.

Users should be aware that applications deployed to the cloud are not always designed with data integrity and security in mind. As a result, vulnerable applications may be deployed into the cloud environment, resulting in security incidents. Furthermore, flaws in infrastructure architecture, errors in hardening protocols, and simple operational oversights can all pose significant risks to cloud service operation. Of course, similar flaws can endanger the operation of traditional data centres.

Obviously, technical expertise is required for incident response, but privacy and legal experts can also make a significant contribution to cloud security. They will also play an important role in incident response, including notification, remediation, and possible legal action. If a company is thinking about using cloud services, it should consider whether mechanisms for employee access to data that is not governed by user agreements and privacy policies are in place. In contrast to SaaS providers, the cloud service provider’s own applications do not manage application data in IaaS and PaaS architectures.

The complexity of large cloud service providers providing SaaS, PaaS, and IaaS services creates pitfalls during major incident response, and potential Users must assess the acceptable level of corresponding SLAs. When comparing cloud service providers, keep in mind that the provider may host hundreds or thousands of application instances. Any external application broadens the security operations center’s responsibility in terms of incident monitoring (SOC). Typically, the SOC monitors indicators that generate alerts and other events from intrusion detection systems and firewalls, but in an open cloud environment, the number of sources and announcements that must be monitored grows exponentially; for example, the SOC may need to monitor consumer-to-consumer activity as well as external events.

An organisation must understand the cloud service provider’s incident response policy. This policy must address unauthorised access to application data identification and notification, as well as remediation options. To make matters even more complicated, the management and access to application data has different implications and regulatory requirements depending on where the data is stored. For example, if the data is in Germany, an incident occurs; however, if the data is in the United States, it may not be considered a “incident.” This makes identifying events difficult.

Recommendations:

Prior to service deployment, the cloud subscriber defines and communicates with the cloud service provider what constitutes an incident (e.g., data corruption) and what is simply an event.

The cloud subscriber’s involvement in the incident response activities of the cloud service provider may be very limited. As a result, it is critical that the customer understands the established communication path with the incident response team of the cloud service provider.

To ensure compatibility with their systems, the cloud subscriber should investigate which incident detection and analysis tools the cloud service provider employs. Some private or unusual format of the cloud service provider’s logs can frequently be a significant impediment in joint investigations, particularly those involving legal investigations (discovery) or government interventions (intervention).

Applications and systems that are poorly designed and protected can easily “overwhelm” everyone’s ability to respond to incidents. To reduce the likelihood of a security incident occurring in the first place, systems must be properly risk managed and defense-in-depth practises implemented.

Security Operations Centers (SOCs) often assume a single control model for incident response, but this is not appropriate for multi-tenant cloud service providers. A robust and well-maintained security information and event management (SIEM) process identifies available data sources (application logs, firewall logs, and IDS logs, etc.) and consolidates these logs into a common analytic alerting platform that can assist the SOC in detecting events in the cloud computing environment.

To greatly facilitate detailed offline analysis, cloud service providers that can provide snapshots of the entire customer virtual environment, including firewalls, networks (switches), system applications, and data, can be examined.

Containment is a race between damage control and evidence gathering. A containment approach based on a trinity of confidentiality-integrity-availability (CIA) is effective.

Remediation highlights the importance of being able to restore a system to some previous state, even if it requires going back to a known available configuration 6 or 12 months ago. Keeping legal options and requirements in mind, remediation may also require “forensics” records to support incident data.

All data classified as “private” due to data breach regulation should be encrypted to reduce the consequences of a breach. The client should specify the encryption requirements in the contract.

Some cloud service providers may have a large group of Users with unique applications. To be able to provide granularity of events to each specific customer, these cloud service providers should consider an application layer logging framework. These cloud service providers should also build a registry that logs application owners by application interface (URL, SOA service, etc.).

In a multi-tenant environment, application-level firewalls, proxy servers, and other application logging tools are key capabilities currently available to assist with incident response.

Vinchin Backup & Recovery allows you to recover the entire VM and all its data from any restore point (full backup, incremental backup, or differential backup) without affecting the original backup data. Backups that have been deduplicated or compressed can be recovered. It is an excellent solution for ensuring enterprise business continuity and minimising critical business interruptions caused by disaster or system failure.

You can also quickly validate backup data availability by instantly restoring the target VM to a remote location in a matter of minutes. Ascertain that, in the event of a true disaster, all VMs can be recovered and that the data contained within is not lost or damaged. Vinchin provides solutions such as VMware backup for the world’s most popular virtual environments, XenServer  backup, XCP-ng backup, Hyper-V backup, RHV backup, oVirt backup, etc.