Penetration Testing of an AWS-based Application – What You Need to Know
Amazon Web Services, or AWS, offers 90 types of cloud hosting services such as computation and storage, security management, physical hosting facility, content delivery, etc. These services can be generally classified as IaaS (Infrastructure as a Service), PaaS (Platform as a Service), or SaaS (Software as a Service). Some of the most common purposes behind these services include data storage, code development, web application services, and networking. These days, organizations prefer opting for cloud services due to a reduction in maintenance costs for physical systems. In the context of an AWS-based application, a decision-maker needs to understand that a penetration test cannot be conducted on the AWS platform where your environment is built. However, you can test your AWS configuration and code or other assets residing in your cloud environment.
Where can you perform?
When vendor operated services are involved where cloud offerings are maintained by a third-party vendor, the scope of penetration testing is limited to the configuration of a cloud environment and its implementation. The underlying infrastructure of AWS is out of the scope of penetration testing. For example, you can pentest the API Gateway Configuration but its hosting infrastructure i.e. underlying systems cannot be tested.
In user-operated services, cloud offerings are managed by the user. If you have an EC2 instance, you can perform a full-fledged penetration test excluding any such test which can harm the business continuity such as DoS or DDoS attacks. Out of many cloud hosting services, EC2 is commonly tested. Various areas in an EC2 instance that allow penetration testing are APIs, application servers and associated stacks, VMs, and web/mobile applications used by your organization.
Where you cannot perform?
As is the case with every service based on the SaaS model, the end-user i.e. your organization is not the owner of a cloud platform. An organization could still conduct penetration testing via either Blackbox engagement or a security audit. Here is a list of few things which cannot be pentested in the AWS cloud environment due to various legal/technological obligations –
- AWS own services
- AWS’ physical hardware or underlying infrastructure
- EC2 instance of other organizations
- Amazon’s RDS (Relational Database Service)
How is it different?
In traditional penetration testing, an organization is the sole owner of physical as well as virtual assets. However, this status quo changes once an organization starts using AWS services. When AWS services are used, Amazon is the owner of the whole AWS infrastructure and conducting a traditional penetration test will violate the Acceptable Usage Policy of AWS and in turn, the AWS Security Team will also initiate incident response procedures. In order to avoid this situation, the focus of penetration testing should be only on the assets owned by your organization.
Performing a penetration test, just like every other IT project, requires careful planning and domain experts. To start with, you should take the following steps necessary in order to avoid any obstructions –
- Define the scope of penetration test which should include the details about your AWS environment and other systems as required.
- Select a type of penetration testing.
- Understand the expectations of the internal as well as external stakeholders of your organization.
- Plan and document a timeline for assessment of systems, receiving reports, remediation, and follow-up testing exercise after recommendations are
- Share the following information with AWS beforehand –
- When will the penetration test be conducted?
- Which are the IP Addresses being tested?
- Which are the IP Addresses from which the penetration test will be conducted?
Performing Basic Scans
There are many tools available which can assist you in performing an initial scan of your cloud environment. Using these tools, you can explore the existing vulnerabilities and assess the possible damages that can be caused to your organization if any of the existing vulnerability is exploited. In addition, using tools like AWS Inspector or Nmap also help in performing a regular review of your cloud presence so that the maximum level of security is achieved. Some of the other ways to improve security are checking access permissions, avoiding performing operations using your root account, implementing an efficient multifactor authentication, etc.
Choosing a Service Provider and Afterwards
A penetration test can be either conducted by an external service provider or an internal team. At times, organizations do not have a sufficient budget to arrange for resources required to conduct an in-premises penetration test. Or, there are also chances that the internal security team does not have experience of conducting a penetration test on an AWS-based application. These concerns can be easily addressed by availing the services of a third-party service provider.
When it is finally decided that you are going for a service provider, choosing a service provider presents an altogether different set of challenges. It must be kept in mind the decision-making processes of selecting a service provider must not entirely rely on marketing brochures sent by a service provider. You must select a service provider with –
- Proven track record
- Industry subject-matter experts on security in AWS
An ideal service provider is capable of providing properly documented and detailed test reports along with conducting a penetration test as per the requirements of an organization. After carefully considering each and every factor, you should carefully select a service provider. Breachlock is one such service provider. If there is even a small hint of doubt, you should keep the alternatives ready.
After a service provider concludes a penetration test, the testers present and show a documented report of findings and remediation measures to be taken. The process for remediation of existing vulnerabilities is initiated so that all the vulnerabilities associated with your AWS-based application are effectively addressed.