Although cloud providers offer more and more robust security controls, in the end, you’re the one who has to secure your company’s workloads in the cloud. According to the 2019 Cloud Security Report, the top cloud security challenges are data loss and data privacy, followed by compliance concerns, tied with worries about accidental exposure of credentials. Cloud penetration testing can help with this.

What is cloud pen testing? It is an authorized simulation of a cyberattack against a system that is hosted on a cloud provider, e.g., Google Cloud Platform, Microsoft Azure, Amazon Web Services (AWS), etc. Its main objective is to find the threats and weaknesses of a system hosted on a cloud platform so that you can see how secure it really is. Cloud app pen testing also requires a shared responsibility model.

Shared Responsibility in Cloud Penetration Testing

In a cloud computing environment, there are two terms with which you need to be familiar:

  • Provider: Provider is the entity that builds and runs the cloud environment and offers its services on a metered basis to one or more tenants.
  • Tenant: Tenant is the entity that is using the metered service of the cloud provider.

When determining the scope, you should check whether the organization is a cloud provider or tenant. For multiple clouds, an organization can act as a provider for one and a tenant for others.

Cloud Service Models

Before penetration testing cloud-based applications, you should understand which resources the cloud service provider will take care of and which resources the tenant will take care of.

  • Infrastructure-as-a-Service (IaaS): Hardware and network connectivity are supplied by the cloud provider. The tenant takes care of the virtual machine and everything that runs within it.
  • Platform-as-a-Service (PaaS): The provider supplies all the components required to run the application, and the tenant supplies the application it wishes to deploy.

Cloud penetration testing works in PaaS and IaaS environments as long as you work together with the cloud service provider. Note that there is a third option: Software-as-a-Service (SaaS). In this case, the provider supplies the application and all the components required to run it. Due to the impact on the infrastructure, providers don’t allow penetration testing in the SaaS environment.

Understand the Policies of the Cloud Service Provider

Putting aside private clouds, public clouds have policies related to security testing. You need to notify the provider that you are going to carry out penetration testing and comply with the restrictions on what you can actually perform during the testing.

Many public cloud providers have a certain process that needs to be followed. Not adhering to the process could get you in legal trouble. For example, if your testing leads to a distributed denial-of-service (DDoS) attack, the provider may shut down your account.

Public clouds are multi-tenant. Your penetration testing could also take up so many resources that it affects other tenants in the cloud. There are rules for this, so you need to understand the legal requirements, policies and procedures before carrying it out.

Create a Penetration Testing Plan

A penetration testing strategy for a cloud-based app should include the following:

  • User interfaces: Identify and include user interfaces in the specific application
  • Network access: Examine how well the network safeguards the application and data
  • Data: Check how the testers will test the data as it passes through the application and into the database
  • Virtualization: Determine how well virtual machines can separate your workload
  • Automation: Select automated tools
  • Regulation: Know the laws and regulations you need to adhere to within the application or database
  • Approach: Determine whether application admins should be included.

Select Your Penetration Testing Tools

There are a plethora of penetration testing tools on the market. While it’s common to use on-premises tools to test cloud-based services, you can now also use cloud-based testing tech that may be more cost-effective. Furthermore, they do not require a large amount of hardware. The tool’s main feature is that it can imitate an actual attack.

Observe the Response

Look for the following things while performing the penetration testing:

  • The human response, or how the application’s admins and users react to it. The responses will be more telling if you don’t make the test public. Many people will just shut down the system, while others may diagnose the problem first before detecting and escalating the threat. This includes your cloud provider’s people; how they respond is just as crucial.
  • The security system’s automated response, or how it can detect and respond to penetration testing. Make sure that reaction is multi-tiered, with options ranging from merely banning the IP address that generated the test to shutting down the system. In any case, notify security and application administrators, and supply them with the details of the corrective action performed.

It’s important to keep track of both human and automated responses. This is where you’ll uncover any flaws in the systems and people’s responses to the danger, as well as the system’s overall defenses.

Find and Remove Vulnerabilities

While this may seem like an obvious step, in the end, you’ll have a list of vulnerabilities identified by penetration testing. The list could be hundreds of issues long or as short as two or three.

If there aren’t any, your testing may not be as effective as it should be, and you should consider it again and retry.

Vulnerabilities discovered during penetration testing of cloud-based apps often look like this:

  • Using an application programming interface (API), you can access application data
  • After 10 failed tries, the tester gained API access
  • The virtual machine does not isolate the workload well enough
  • The tester guessed the password for the application using an automated password generator
  • If the tester turns off DNS, a virtual private network allows access from the outside
  • Encryption does not meet new regulations
  • Other issues.

Of course, the issues you discover will differ based on the application and type of penetration testing you conduct. Also, keep in mind that there are other layers to consider.

Perform separate tests on the application, network, database and storage layers, and report issues one by one. The layers should also be tested jointly to study how well they work together and if there are any concerns. It’s best practice to report what happened at each layer as a whole.

Final Pen Testing Suggestions

Another factor to examine is who is conducting the penetration testing. If you handle it in-house, you can be sure that some difficulties will go unnoticed. Internal testing teams, no matter how skilled they are, can overlook something. They’re too near to the action and too familiar with the software, which can lead to carelessness and errors.

You should consider best practices for your cloud provider, the applications you’ll be testing and any compliance requirements you’ll need to meet. Using the methods that others have used is a fantastic place to start, but keep in mind that you should tailor your penetration testing methods and tools to your specific needs.

Penetration testing is no longer optional. It’s the only method to demonstrate that your cloud-based services and data are safe enough to allow a large number of users to access them with minimal risk.

More from Application Security

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Audio-jacking: Using generative AI to distort live audio transactions

7 min read - The rise of generative AI, including text-to-image, text-to-speech and large language models (LLMs), has significantly changed our work and personal lives. While these advancements offer many benefits, they have also presented new challenges and risks. Specifically, there has been an increase in threat actors who attempt to exploit large language models to create phishing emails and use generative AI, like fake voices, to scam people. We recently published research showcasing how adversaries could hypnotize LLMs to serve nefarious purposes simply…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today