Incident response in the cloud

Many organisations are migrating their on-premise infrastructure to the cloud due to its known benefits including cost savings, quicker deployment, scalability, security and flexibility. But what does a business need to do to ensure its systems are secure, reliable and effective in the cloud?

Cyber-attacks are an ongoing problem

At the time of writing, Uber was investigating a cybersecurity breach. Uber has a multi-cloud deployment model with its services hosted in AWS and Google Cloud Platform (GCP). Examining the specifics of the Uber attack, it seems that regardless of its deployment model, the end result would have been the same.

This well-planned social engineering* attack was orchestrated by an 18-year-old whose initial target was an Uber employee. This victim was manipulated to hand over a password that allowed the hacker to gain access to Uber’s system.

Once on the internal network, the attacker found high privileged credentials sitting on a network file share and used them to access everything, including production systems.

*Social engineering is any manipulation technique that exploits human behaviour and error in order to gain access to sensitive or confidential information.

How does an enterprise’s choice of cloud model relate to incident response (IR) responsibilities?

From this incident, it is clear that social engineering attacks are still relevant today. The migration from on-premise data centres to the cloud has not reduced the number of social engineering cyber-attacks; in fact, cases may even have increased because many small and mid-size businesses are unsure which deployment model to choose and what responsibility they will inherit based on that decision.

Here we explore IR responsibilities for each deployment model.

Software as a Service

Software as a Service (SaaS) is an application delivered over the Internet by a provider. In a SaaS environment, the Cloud Service Provider (CSP) is wholly responsible for the entirety of the infrastructure, which means they’re not likely to be interested in sharing a lot of information. This leads to two possible scenarios for incident detection:

1. Log data from the SaaS CSP triggers an incident response scenario internally via security information and event management (SIEM) technology. In this scenario, the incident is entirely internal to the SaaS provider, and they handle the incident on their own with no need to notify the organisation.
2. When the CSP’s internal incident response process is triggered and the incident manifests in or touches on areas that contain consumer data, the CSP may notify the organisation within some pre-specified SLA-defined period. It is imperative that your provider notifies you if there is an incident that could affect your data.

Platform as a Service

Platform as a Service (PaaS) is a computing platform (operating system and other services) delivered as a service over the Internet by a provider. PaaS providers are likely to offer a lot more log and event data than SaaS providers.

In general, organisations have much more control over the infrastructure, or at least specific application and platform instances, than in a SaaS model, and some of this control may pertain to logging and event generation.

There are also many more viable use cases and scenarios that the CSP will accommodate for organisations, such as users accessing the applications, authentication logs, usage logs, traffic/application statistics and more.

Any platforms you control can likely have logging enabled too, and you can usually send these back to a log management or SIEM appliance or have the provider archive them for you.

With a PaaS provider, there is still an emphasis on the provider’s internal security for detection and response, but the likelihood of an incident touching the organisation’s system and data is higher due to the broader exposure window of full-blown platforms and custom development.

Organisations will need to tell the CSP what kinds of “triggers” should lead to incident notification (or at least event notification). These might include things like failed authentication attempts, improper data or application access, or even things like SQL injection attacks.

Of course, the PaaS provider must maintain its own infrastructure security, and in some scenarios, will not be obliged to disclose information to customers, especially if the incident has no impact on the customer.

Infrastructure as a Service

Infrastructure as Service (IaaS) is a virtualized computer environment delivered as a service over the Internet by a provider. IaaS providers will have two specific scenarios: CSP incident response to backend storage, networks, servers, and virtualization infrastructure only; and customer incident response for all organisation’s VMs and associated virtual networks producing logs identical to internal events.

With the proper degree of segmentation and isolation, it should be clear to the provider where the boundaries lie and what kinds of response efforts are likely to be needed.

In summary, the cloud models will dictate the IR responsibilities for an organisation.

• SaaS: CSP IR team is 100% responsible for all systems and data
• PaaS: CSP IR team will handle most events, but application-specific logs and events may be the customer’s responsibility
• IaaS: Responsibility will be shared

How should you respond to cloud cybersecurity incidents?

When it comes to your IR plans, there are two major frameworks – the National Institute of Standards and Technology (NIST) IR framework and SANS incident response framework. The SANS framework is similar to the NIST framework, except it splits containment, eradication and recovery into separate steps.

Here is the SANS six-step incident response methodology in brief:

1. Preparation: Ensure you’re ready to handle incidents, with team, tools, process and policy
2. Identification: Identify events that could be incidents, and make the call
3. Containment: “Stop the bleeding,” where you get a handle on things and prevent it from worsening
4. Eradication: Eliminating the problem, using root cause analysis
5. Recovery: Bringing production back to a normal state
6. Lessons Learned: Reporting and reviewing what happened, with and lessons learned

Pre-incident preparation and identification of events that could be incidents are critical, as they help ensure the IT team approaches the problem in the right way.

Pre-incident preparation

When planning for cloud incident response ensure you have Role-Based Access Control (RBAC), or Identity and Access Management (IAM) enabled for teams when needed. This needs to be considered in advance as you don’t want to stop and spend time to create privilege model for IR analysts while under attack. Enable multifactor authentication (MFA) for these accounts.

Enable cloud-wide logging and metric-based alarms. In Azure, we have Azure monitor, Log Analytics and Azure diagnostics to achieve this goal. In AWS, we have similar services like CloudWatch. All the above helps prepare your business for cloud IR function.

Pinpointing the problem, to better solve it

Aside from setting up strong defences, you can also leverage a wide range of tools and methods to help your organisation identity specific potential incidents in the cloud.

Alerts coming from cloud-native SIEM products like Microsoft Sentinel provide indispensable benefit. Depending on the CSP model and deployment type chosen by the customer, some CSPs can also provide security notifications and alerts.

Should any anomaly in monthly billing range be observed, you need to investigate to understand causes of additional cost. Identities in the cloud – particularly admin access – should be monitored as these accounts are often targeted by attackers.

Additionally, always investigate suspicious user activity, federated user activity on behalf of others, new resource creation by cloud services, specific time ranges that are suspicious, specific region activity and failed access to resources for user or group.

This is definitely not the only logs or events that you will want to keep track of, but is a good starting point for items of interest. As with any new detection and IR models, you’ll need to wade through some data to get a sense for what you find valuable and what is likely fluff or potential false positive feeds.

In summary, the benefits of cloud are undeniable, but it’s also clear that cloud computing comes with challenges for incident response. Business and technology leaders need to choose the best-fit cloud service models so they can better develop and roll out an effective incident response.