Most penetration testing methodologies are not cloud-native because this type of testing requires specific and diverse knowledge in both cloud and penetration testing, as well as expertise in areas such as authentication and authorization, APIs, and databases. That said, we need to consider the reasons for investing in this type of penetration testing: the main ones being the identification of risks and vulnerabilities. However, the tests can also help ensure that all best practices are being followed for audit purposes or internal improvement processes.
There are various frameworks for cloud testing, and we will discuss the most common one: the shared responsibility model. In this model, the testing involves examining the security requirements of the cloud (rather than testing the security of the cloud itself). Essentially, the provider is responsible for ensuring that the platform is secure, while the customer ensures that the environment and its components are secure. In this model, it is the provider's responsibility to define the scope of the tests, the frequency at which they can be conducted, and any other agreements (SLA). You can learn more about the rules for testing and also about the shared responsibility model in the AWS documentation.
At this point, the penetration test is quite similar to any other penetration testing. We basically have three stages: Discovery, Exploitation, and Remediation:
The pentester will search for known vulnerabilities, misconfigurations, information, or anything else that allows penetration into the environment.
Using the information gathered in phase 1, the pentester will combine information to exploit vulnerabilities and gain access to the environment. The focus here may also be on resilience, monitoring, or service availability, in addition to collecting evidence of everything achieved.
Involves the follow-up of corrections and retests to ensure that the vulnerabilities have been addressed.
- Understand the shared responsibility model
This ensures that you are working within the correct scope and areas that fall under your responsibility.
- Clearly define the type of test
Before starting, determine whether it will be a gray box, black box, or white box test. This will help better define the tactics to be used.
- Understand your provider's SLA
Avoiding disruptions and unnecessary processes is always a good idea.
Just as for software and API development, OWASP maintains a list of the top ten vulnerabilities commonly exploited in cloud-native environments, along with a guide for security testing in cloud-native environments.
First, thoroughly understand the shared responsibility model and all the involved SLAs. The next step is to understand how to exploit. In this stage, we will use AWS as an example cloud. See you in the next chapter :)
*You can read this article in pt-br here