Cloud Penetration Testing

Conventional penetration testing approaches are not designed for cloud-native environments and concentrate on procedures applicable to on-premise settings. Cloud penetration testing demands expertise that varies from standard penetration testing as it involves evaluating cloud-specific settings, passwords, applications, encryption, APIs, database, and storage access. Moreover, cloud penetration testing is influenced by the Shared Responsibility Model, which clarifies the responsibility for components within a cloud infrastructure, platform, or software.

During a Cloud penetration test, security controls that are the complete responsibility of the Cloud Service Provider (CSP) are typically excluded from the scope of the test. It is important to note that when it comes to cloud security, the focus is on testing the security within the cloud, rather than the security of the cloud itself. In an Infrastructure as a Service (IaaS) environment, security testing covers the User Access/Identity, Data, Application, and Operating System layers, while other components are managed and controlled by the Cloud Service Provider (CSP) and are considered out of scope. The scope of the penetration test is determined by the service model, and the extent and coverage of the testing will vary based on the services offered by the CSP.

Scope

The application of test cases and the scope of testing vary depending on the service model. SaaS applications have a relatively small scope, focusing on data and user access/identity controls. PaaS has a larger scope that includes the application layer and some platform configuration, with all lower layers excluded. IaaS has an even broader scope, including client responsibility and potential security testing. However, certain aspects such as virtualization, hardware, and sometimes the operating system are still under the control of the CSP. Moving workloads to the cloud changes the scope of potential security testing and introduces additional areas of testing, such as the cloud management plane. If authorized by the CSP, you can expand the scope of the cloud penetration testing service to include components under the control and management of the CSP, which introduces additional complexity to the scoping process.

Depending on the service model, client-side application testing is in scope when conducting Cloud penetration testing. Please refer to Web Application Penetration Testing and Mobile Application Penetration Testing for details. In addition, the following domains are relevant:

It is important to consider all three domains when scoping a penetration test, even if any of them are excluded from the test’s scope, as they can significantly impact each other. For instance, a misconfigured user account can increase the severity and probability of an application breach. An application that is poorly designed, implemented, or configured with elevated cloud privileges can result in a complete compromise if breached. Neglecting service use at the account level, billing thresholds, and controls can leave the application highly vulnerable to denial-of-service attacks, resource starvation, or billing abuse.

Objectives

The widely known STRIDE model can be used to look at Cloud specific testing objectives. The STRIDE model is a threat modeling framework used in software development and information security to identify and categorize potential threats to a system. The STRIDE model consists of six threat categories that represent different types of attacks that can be launched against a system:

When applied to Cloud penetration testing, the STRIDE model helps identify potential security weaknesses and vulnerabilities including virtual machines, containers, and cloud infrastructure.

Keep in mind that the cloud is a versatile platform with a multitude of potential deployments and applications, such as workloads, storage, and containers. As a result, vulnerabilities and security weaknesses can vary depending on what is being hosted and how it is implemented. Therefore, it is important to have specific testing guidelines for each of these components.

To conclude, please note that performing penetration testing involving Cloud deployments no matter the service model is considerably different than penetration testing of legacy systems. All stages of penetration testing – preparation, threat modelling, reconnaissance and research, testing, and reporting – involve many additional items to be considered when dealing with Cloud deployments.

We have the knowledge and expertise required in such an environment. This can’t be said about all companies offering such services.