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

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

Detecting the Undetected: The Risk to Your Info

IBM’s Advanced Threat Detection and Response Team (ATDR) has seen an increase in the malware family known as information stealers in the wild over the past year. Info stealers are malware with the capability of scanning for and exfiltrating data and credentials from your device. When executed, they begin scanning for and copying various directories that usually contain some sort of sensitive information or credentials including web and login data from Chrome, Firefox, and Microsoft Edge. In other instances, they…