Amazon offers a variety of cloud hosting services that are used by businesses for content delivery, storage and management, network infrastructure, and physical hosting capabilities. The widespread coverage automatically brings forward the question of security of which the AWS penetration testing technique remains the most successful.
The main benefits of using AWS comes from the ease of scalability, reliability, and flexibility of the platform. This especially comes in handy for web application services, data storage, networking requirements, and code development. However, when conducting AWS penetration testing, there are a few important reminders to keep in mind.
What’s allowed/not allowed in AWS Penetration Testing?
In AWS, both the user-operated and vendor-operated services can be subjected to pentesting, although there are some restrictions in the latter category. User-operated services mainly involve the cloud-based assets created and configured by the user. This means the AWS Elastic Compute Cloud (EC2) instance can be tested completely except for any attack methods that may disrupt business operations. In fact, the EC2 component is the most commonly tested component of the AWS – some of the tested areas are:
- Web and mobile applications under the firm
- Any virtual machines and/or operating systems
- The application programming interface (APIs) including HTTP, HTTPS, etc.
- Application servers, their associated stack, and the programming languages (Python, React, etc.)
Under vendor-operated services, which includes the cloud-based assets owned and operated by a third-party vendor, pentesting is limited to certain aspects of the cloud environment. This means the tester can target the environment implementation and configuration details but not the infrastructural foundation. For example, both the Cloudfront and the API gateway configuration can be tested.
The AWS platform is mainly based on the software-as-a-service (SaaS) model which brings a shared responsibility for security maintenance. The cloud environment in this scenario doesn’t belong to the user and therefore cannot be completely tested like a traditional on-premise firm or as in the infrastructure-as-a-service (IaaS) model. A good combination of black-box testing techniques and a full scale IT security audit should be used to crack the vulnerabilities of SaaS services that cannot be covered otherwise.
Some other aspects that cannot be covered under a standard AWS penetration testing exercise are services and/or hardware that belongs to AWS, EC2 environments belonging to third-party vendors, and security appliances owned by other vendors (without permission). Any physical hardware, infrastructure, or facilities that belong to AWS and Amazon’s Relational Database Service (RDS) are also not covered under the testing scope.
What are the differences between traditional and AWS penetration testing?
The main difference refers to the ownership of the systems and the assets under both these testing techniques. Under the AWS services, Amazon owns a majority of the core infrastructure and any traditional hacking methods could breach the ‘acceptable use’ policies of AWS. This consequently leads to incident response security procedures initiated by the Amazon security team, suspension of business operations, and wastage of time and resources.
The AWS penetration testing procedure will instead focus on assets and services owned and operated by the user. This will cover the identity and access management procedures, user permissions, configuration flaws, and the usage of APIs in the AWS environment. Different kinds of attack methods can be used here such as targeting weak AWS IAM keys, evaluating the security of the S3 bucket configuration, manipulating the Cloudtrail logs, and establishing access through the Lambda backdoor functions. Since these strategies are highly specific to the AWS environment, the testing team requires advanced knowledge and expertise to design the hacking methods for effective results.
What’s after AWS Penetration Testing?
After every penetration testing procedure, there needs to be a finalized report with details on the findings, techniques used, and other recommendations. Remediation for the discovered vulnerabilities should be based on the criticality and the consequent business impact. The higher the risk, the more possible it’s for an exploitation situation to occur, and the greater the impact for the business. There should be a defined procedure that determines the criticality of each vulnerability based on a list of parameters.
Following this, certain AWS penetration testing companies also offer the opportunity for retesting to ensure that the vulnerability has been properly fixed. In fact, some regulations and compliance standards dictate that a retesting is required if the vulnerability is termed as ‘critical’. Further, if the final pentesting report is being distributed to an auditor, clients, or other third-party groups, the details of the remediation and retesting procedures should be included. This is so that no further malicious procedures can happen based on these resolved vulnerabilities if hackers access this information and launch attacks.
These are a few tips and informational points one must keep in mind before embarking on an AWS penetration testing procedure. Firms must also make sure to check third-party pentesting service providers who are aware of these fine details and have enough expertise to conduct a successful testing procedure.
