Public cloud computing has evolved into a mainstream solution for data storage, on-demand service, and infrastructure. Garter forecasts the total revenue from worldwide public cloud services to reach $305.8 billion by 2018 and hit the point of $411.4 billion by 2020. It is only natural that penetration testing, a cornerstone of corporate security, is on demand, as it is the way to identify and assess possible vulnerabilities in cloud instances.

Is cloud-based penetration testing different from that conducted on-premises? What are its limitations and what determines them? Let's discuss it further.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Scope of public cloud penetration testing

Typically, an on-premises environment assumes that you own all network components so that penetration testing can be executed on all open system interconnection (OSI) layers. Penetration testing in the cloud differs from that on premises. Its major stumbling block is a shared security responsibility between the cloud service provider (CSP) and the cloud service consumer (CSC). Both can act as cloud penetration testing customers, and both are eligible to perform the test only on their cloud share. Thus, the first factor to consider before executing cloud-based penetration testing is whether you are a provider or a consumer. The other one is the cloud service model you have chosen.

Consumers vs. providers: cloud penetration testing responsibilities

Cloud providers can take advantage of the whole spectrum of cloud penetration testing opportunities (including the most brutal ones: red team penetration testing and DDoS testing). The cloud service market is highly competitive today. Amazon, Microsoft, IBM, Google, and Salesforce are just a few giants with a strong security posture. As consumers become more and more concerned about cybersecurity, they ask CSPs to provide the details on the overall security process (equipment types and architecture diagrams, security policies and security audit protocols, reports on patching and updates for all relevant software) and cloud penetration testing activities (systems tested, tools used, vulnerabilities found). So, CSPs must pay due attention to conduct various types of penetration testing to cover maximum vulnerabilities.

Cloud consumers are way more restricted in application, and network penetration testing on their cloud instances and the restriction extent varies depending on the cloud service model.

Public cloud penetration testing according to the cloud service model

There are three recognized cloud service models: infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS). They differ in the delineation of responsibilities between providers and consumers for cloud solution layers.

To understand cloud service models better, let's first look at eight components (layers) a cloud deployment consists of.

1. Facility (buildings).
2. Network (both physical and virtual).
3. Computers and storage (hardware supplying CPU and file storage).
4. Hypervisor (It is used in the case of a virtualized environment. The component allocates resources to all virtual machines.).
5. Operating system (OS) and Virtual machine (VM) (in a non-virtualized environment OS runs on the computer and storage hardware; in the case of virtualization – on a VM).
6. Solution stack (programming languages used for applications, frameworks, and databases).
7. Application (the apps used by consumers).
8. Application program interface (API) or Graphical user interface (GUI) (the interfaces used by consumers or their customers).

The control over these layers directly influences the scope of application and network penetration testing. Let's take a closer look at cloud layers that can be tested within each service model.

IaaS model

In the IaaS model, the consumer controls the virtual machine and the OS running on it together with upper cloud levels. At the same time, all the hardware and network connectivity are supplied by the provider. So, consumers are eligible to conduct cloud penetration testing on the VM, solution stack, application, and API/GUI layers.

PaaS model

The PaaS model suggests that the consumer deploys the application in a cloud, and the provider delivers all the hardware and software components to run this application. Apparently, this service model leaves consumers with fewer layers available for cloud penetration testing, namely application and API/GUI.

SaaS model

The SaaS model is a turnkey solution when the provider supplies the necessary applications and components to run them. The scope of cloud penetration testing, in this case, is limited to the API/GUI level. Sometimes, as in the case of Salesforce and SharePoint, SaaS model allows customers to have their own applications running. Thus, these apps are eligible for penetration testing from the customer's side.

Tips for a cloud penetration testing customer to remember

Cloud consumers should remember two golden rules for any cloud penetration testing activities:

• Ask for your CSP's permission to conduct cloud-based penetration testing.
• Make sure that it is conducted in the cloud layer you control.

The requirements for penetration testing are usually available on cloud providers' websites. For example, here you can see the requirements of Microsoft Azure, and here – of AWS. Not following these rules, you will land yourself in hot water. As CSPs guard the security of all their customers, they will shut your service down treating pentesting activities as an actual attack that harms other consumers' servers.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

A cloud service provider must find the balance between protecting consumers from security breaches and ensuring that the security policies implemented bring no harm to consumers' servers. Although less restricted to cloud penetration testing opportunities, CSPs also must keep within the limits of their cloud domain. Fortunately for cloud consumers, a provider is unlikely to break into a consumer's "territory" without permission. Doing so, CSPs are doomed to lose their customers.