Examining the considerations when building penetration testing lab environments in the cloud

In the succeeding chapters of this book, we will be designing and building multiple vulnerable-by-design labs in the cloud. After setting up each of the lab environments, we will simulate the penetration testing process to validate if the vulnerabilities present are exploitable. Before performing a penetration testing session in our cloud environments, we must be aware of the following:

• What activities are allowed without notification or authorization
• Whether the attack traffic will pass through the public internet
• Whether we will perform network stress-testing
• How our penetration testing lab environment looks like
• What activities we will perform inside the environment
• Whether we are testing the security of an application inside a server or we are testing the security of the configuration of a cloud service

In addition to these, we must be aware of the activities and actions prohibited by the cloud platforms. Here are a few examples of what’s not allowed in cloud environments:

• Attempting social engineering attacks on employees of the cloud platforms
• Attacking resources and trying to gain access to data owned by other account owners and users
• Using cloud services in a way that goes against a platform’s Acceptable Use Policy and Terms of Service

Note that there’s a long list of prohibited actions and activities in the relevant documentation pages available online for each of the cloud platforms. You can find the relevant links to resources on the succeeding pages and the Further reading section of this chapter.

We must also notify and contact the respective support and security teams of the cloud platform when needed. This will guarantee that we will not be breaking any rules, especially if we are unsure or if it is our first-time performing penetration tests in the cloud.

Note

The best practice is to notify the cloud platform ahead of time to get authorization and approval. In some cases, an approval or notification is not required but filing a support ticket before performing penetration tests on your resources won’t hurt.

On some occasions, you might think that you no longer need to get authorization from the cloud provider since your penetration testing session will not harm other customers. However, this is not always the case as there might be actions that still require authorization from the cloud provider. Figure 1.6 shows a sample penetration testing lab environment on AWS:

Figure 1.6 – Sample penetration testing lab environment setup

This lab environment has the following components:

• An attacker machine inside a VPC that prevents all outbound connections
• A target machine that contains vulnerable applications and services
• A VPC peering connection that allows traffic between the VPCs where the attacker and target EC2 instances are hosted (so that the attack traffic will pass through this VPC peering connection)
• An S3 bucket containing files accessed via Private Link

Performing penetration tests on an application running inside an EC2 instance requires no approval. On the other hand, performing penetration tests on your own S3 bucket in your AWS account is not allowed unless you get approval from AWS. Why? Performing penetration tests on an S3 bucket you own differs from penetration tests on an application hosted on S3. You must complete the Simulated Events Form and provide the required information to get authorization from AWS before performing penetration testing simulations on Amazon S3, along with other services not listed under Permitted Services of the Customer Service Policy for Penetration Testing information page. Make sure you check out the following links before performing penetration tests on AWS:

• AWS Customer Support Policy for Penetration Testing, Customer Service Policy for Penetration Testing, Other Simulated Events: https://aws.amazon.com/security/penetration-testing/
• Amazon EC2 Testing Policy: https://aws.amazon.com/ec2/testing/
• DDoS Simulation Testing Policy: https://aws.amazon.com/security/ddos-simulation-testing/

It is important to note that penetration testing policies and guidelines differ across cloud platforms. Here are some of the resources and links you need to check before performing penetration tests on Azure:

• Penetration Testing Rules of Engagement: https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement?rtc=1
• Penetration Testing: https://learn.microsoft.com/en-us/azure/security/fundamentals/pen-testing
• Azure Security Test Practices: https://learn.microsoft.com/en-us/azure/architecture/framework/security/monitor-test

Here are the relevant resources and links for GCP:

• Cloud Security FAQ: https://support.google.com/cloud/answer/6262505
• Google Cloud Platform Acceptable Use Policy: https://cloud.google.com/terms/aup
• Google Cloud Platform Terms of Service: https://cloud.google.com/terms/

Note

Note that these policies and guidelines may change in the future, so make sure you review the guidelines before doing penetration tests on applications running in a cloud environment. Make sure you reach out to the support and security teams of the cloud platforms for guidance if you have questions and need clarification.

In addition to what has been discussed already, there are other things we need to consider, particularly in terms of security and engineering:

• The performance requirements when choosing the cloud infrastructure resources needed for the lab: When building penetration testing lab environments in the cloud, it is crucial to consider the performance requirements and select the appropriate cloud infrastructure resources. This involves assessing factors such as network bandwidth, computational power, and storage capabilities to ensure the lab environment can effectively simulate real-world scenarios and handle the resource-intensive nature of security testing.
• The overall cost of setting up, running, and maintaining the penetration lab: The cost of establishing, operating, and maintaining a penetration testing lab environment in the cloud should be considered in the context of security and engineering. This includes expenses related to resource provisioning, infrastructure management, and ongoing monitoring and updates.
• The security and auditability of the environment as the penetration testing lab must be protected from unwarranted external attacks: When building penetration testing lab environments in the cloud, ensuring the security and auditability of the environment is critical. It is crucial to protect the lab from unwarranted external attacks by implementing robust security measures and controls. This includes utilizing security features offered by the cloud platform, such as network segmentation, access controls, and monitoring, to create a secure and auditable testing environment.
• The scalability and modularity of the lab environment: Making lab environments scalable and modular allows you to efficiently customize the lab for a variety of scenarios and requirements, allowing penetration testers to effectively simulate and evaluate diverse attack scenarios.
• The manageability of the lab versions: Utilizing version control systems and tools allows penetration testers to efficiently manage and track changes made to the lab environment configurations, software versions, and custom scripts. This ensures that the lab versions are easily maintainable and reproducible and can be rolled back or updated as needed.
• The use of automation tools and services for fast rebuilds and setup: By leveraging automation, penetration testers can focus more on the actual testing and analysis rather than spending significant time on manual setup and maintenance tasks.

We could add a few more to this list, but these considerations should do for now. We will discuss these security and engineering considerations in detail in the next few chapters as we build a variety of vulnerable-by-design lab environments across the different cloud platforms.