Considerations for incident response in the cloud
When we speak about cloud computing, we are talking about a shared responsibility between the cloud provider and the company that is contracting the service. The level of responsibility will vary according to the service model, as shown in the following diagram:
Figure 2.12: Shared responsibility in the cloud
For Software as a Service (SaaS), most of the responsibility is on the cloud provider; in fact, the customer’s responsibility is basically to keep their infrastructure on-premises protected (including the endpoint that is accessing the cloud resource). For Infrastructure as a Service (IaaS), most of the responsibility lies on the customer’s side, including vulnerability and patch management.
Understanding the responsibilities is important in order to understand the data gathering boundaries for incident response purposes. In an IaaS environment, you have full control of the virtual machine and have complete access to all logs provided by the operating system. The only missing information in this model is the underlying network infrastructure and hypervisor logs.
Each cloud provider will have its own policy regarding data gathering for incident response purposes, so make sure that you review the cloud provider policy before requesting any data.
For the SaaS model, the vast majority of the information relevant to an incident response is in the possession of the cloud provider. If suspicious activities are identified in a SaaS service, you should contact the cloud provider directly, or open an incident via the portal. Make sure that you review your SLA to better understand the rules of engagement in an incident response scenario.
However, regardless of your service model, there are a number of key issues to bear in mind when migrating to the cloud—such as adjusting your overall IR process to accommodate cloud-based incidents (including making sure you have the necessary tools to deal with cloud-based issues) and investigating your cloud service provider to ensure they have sufficient IR policies in place.
Updating your IR process to include the cloud
Ideally, you should have one single incident response process that covers both major scenarios—on-premises and cloud. This means you will need to update your current process to include all relevant information related to the cloud.
Make sure that you review the entire IR life cycle to include cloud computing-related aspects. For example, during the preparation, you need to update the contact list to include the cloud provider contact information, on-call process, and so on. The same applies to other phases such as:
- Detection: Depending on the cloud model that you are using, you want to include the cloud provider solution for detection in order to assist you during the investigation.
- Containment: Revisit the cloud provider capabilities to isolate an incident if it occurs, which will also vary according to the cloud model that you are using. For example, if you have a compromised VM in the cloud, you may want to isolate this VM from others in a different virtual network and temporarily block access from outside.
For more information about incident response in the cloud, we recommend that you read Domain 9 of the Cloud Security Alliance Guidance.
Appropriate toolset
Another important aspect of IR in the cloud is to have the appropriate toolset in place. Using on-premises-related tools may not be feasible in the cloud environment, and worse, may give you the false impression that you are doing the right thing.
The reality is that with cloud computing, many security-related tools that were used in the past are not efficient for collecting data and detecting threats. When planning your IR, you must revise your current toolset and identify the potential gaps for your cloud workloads.
In Chapter 12, Active Sensors, we will cover some cloud-based tools that can be used in the IR process, such as Microsoft Defender for Cloud and Microsoft Sentinel.
IR process from the Cloud Solution Provider (CSP) perspective
When planning your migration to the cloud and comparing the different CSPs’ solutions, make sure to understand their own incident response process. What if another tenant in their cloud starts sending attacks against your workloads that reside on the same cloud? How will they respond to that? These are just examples of a couple of questions that you need to think about when planning which CSP will host your workloads.
The following diagram has an example of how a CSP could detect a suspicious event, leverage their IR process to perform the initial response, and notify their customer about the event:
Figure 2.13: How a CSP might detect a potential threat, form an initial response, and notify the customer
The handover between CSP and customer must be very well synchronized, and this should be settled during the planning phase for cloud adoption. If this handover is well co-ordinated with the CSP, and you ensure that cloud-based incidents are accounted for in both your own IR and the CSP’s IR, then you should be far better prepared for these incidents when they arise.