Cloud penetration testing is a specialised form of penetration testing that focuses on identifying vulnerabilities in the infrastructure, configuration, and accessibility of cloud resources. Regular penetration testing is focused on testing an application directly by identifying vulnerabilities that malicious actors might exploit directly in the application.
However, when applications are hosted in the cloud, the security of the cloud infrastructure itself becomes crucial. Tools and services provided by the cloud environment play a key role in safeguarding applications, potentially nullifying application level vulnerabilities. At the same time, this cloud configuration introduces a level of complexity that is not usually present in traditional hosting environments.
For regular penetration testing, all that is needed is access to the application. Once access is obtained, penetration testers usually focus on web requests and other TCP or HTTP traffic to compromise the application. Cloud penetration testing, on the other hand, is more focused on the configuration of your cloud resources. Even if your application has no vulnerabilities, it can still be compromised if it is configured to pass data to vulnerable cloud services such as web accessible databases.
Cloud environments are inherently web-accessible. While the applications hosted on cloud infrastructure might not be web-accessible, the configuration and control of these resources are. They have to be by their nature, as the resources are configured over the web via cloud consoles, APIs, or SDKs. Unlike an environment where everything is hosted on-premises, malicious actors do not need to breach your private network to alter or access cloud resources.
Cloud providers do offer some level of configuration protection and advice. AWS S3 is a good example, where over the years AWS has implemented more explicit policies and protective default settings to prevent the public exposure of data.
However, cloud providers cannot provide a one-size-fits-all security analysis for their customers due to the diversity of their user base. The security requirements for a bank differ significantly from those of a small home user hosting a single web server.
Cloud providers focus on delivering infrastructure and solutions for their customers who have chosen their services over decades. Their primary responsibility is to keep these solutions operational, even if they are not the most secure, as maintaining up-time and availability is crucial. As a security consultancy, we have the luxury of offering opinionated advice on the best and most secure approaches to using these solutions. We are not bound by the need to support a wide range of potentially insecure configurations, allowing us to prioritise security above all else.
AWS performs basic security checks, such as identifying open firewall rules, publicly available data, and loose IAM credentials. For smaller projects, AWS security tools are generally sufficient.
However, for solutions requiring a more aggressive security posture, the provided tools may not offer an adequate level of due diligence. For example, we consider any EC2 server with a public IP address to be a security risk. In most solutions, inbound traffic is best delivered via Load Balancers or CDNs. Both Load Balancers and CDNs offer several advantages:
You can run an EC2 server securely by only allowing traffic to known ports and ensuring that all software listening on those ports are as secure as possible. However, a single security group rule change can expose the machine to potential threats as the only barrier to access is via AWS Security Group rules. By placing additional services, such as Load Balancers or CDNs, in front of the server, you introduce additional layers of security and gain access to more tools that enhance protection. These additional layers plus the enhanced security features mean that we don’t consider direct access to EC2 machines to ever be comparatively secure.
This is just one example of our approach to an enhanced security posture.
We provide security advisories on our blog, and if you would like to subscribe, you can easily build secure cloud environments using the information we share. Additionally, there are plenty of free resources and high-quality content from various security advisories that can help you build a secure environment.
In general, key things we advise to look out for include:
These three points cover the immediate security concerns we look for. They’re the most common cause of compromise and provide the most efficient return on investment.
Automated penetration testing differs from regular penetration testing by utilising a set of tools and services that continuously test applications to identify and exploit both new and old vulnerabilities. Most tools available in the cloud and application security space have some level of automation, with some tools operating entirely automatically, requiring a small number of initial commands and configuration. These automated tools handle various components of the testing process, such as discovery, identification, scanning, and simulated attacks.
penetration testing cloud automation
If you are hosting applications on Amazon Web Services (AWS), it is important to consider the impact to AWS from your penetration testing. A key aspect of this consideration is determining whether what penetration testing can be safely conducted on the AWS platform without advanced permission and which testing should be abstained from without prior agreement.
penetration testing cloud aws
