How do I fill out the AWS Penetration Testing Request Form?

Update: Amazon has removed their requirement for an AWS Penetration Testing Request Form to be completed prior approval for penetration testing on most services as of March 2019. This means the form explained in this article is no longer necessary to submit prior to having a penetration test performed. For all the details and a full list of services that don’t require approval, see Amazon’s full announcement here.

When penetration testing Amazon Web Services (AWS) cloud-based assets, Amazon requires their customers to submit an AWS Penetration Testing Request Form here. This form must be submitted at least 48 hours prior to conducting any testing activities, and you’ve got to get a confirmation back from them confirming that you’re OK to proceed. Otherwise, and we’ve had this happen before, we could be blacklisted and prevented from sending traffic to AWS hosts by their security team.

Now, filling out this form may seem like a pretty simple task, but many of the questions they ask and the fields you must fill out are not so straightforward. Since we get a lot of questions about this process, we wanted to try and explain what some of these fields mean and how they should be filled out, prior to conducting a penetration test on your AWS cloud assets.

The form should look like this, just so you know you’re in the right place:

AWS penetration testing request form

The following sections can be found in the form, and we’ve provided some guidance for each:

Customer Information

This is simply your contact information or the contact information of your technical personnel who should receive communications from Amazon regarding the penetration test approval or any issues that arise.

Target Data

This section should include all of your in-scope assets that are part of the penetration test. EC2 instances, Cloudfront distributions, API gateways, RDS resources, and ELB names should all be included here. If you don’t recognize some of these acronyms, it’s probably safe to say you don’t need to include anything, however we’re happy to discuss the particulars on a test-by-test basis to make sure you get this part right. This is the same information your penetration testing team will need in order to target the correct assets during testing. The field for Non-AWS Targets would only need to be filled out if penetration testing was being conducted from within AWS and targeting non-AWS hosts, which shouldn’t be the case.

DNS Zonewalking

This section always generates a lot of questions and almost always, does not need to be filled out. DNS Zonewalking is a method of enumerating DNS records to read the full contents of DNS zones signed with DNSSEC, due to the use of an older version of NSEC Resource Records. This would not typically be used in our cloud penetration testing, as we’d be provided with your target assets prior to starting the engagement, rather than taking a full “blackbox” approach which would require more time for things like DNS enumeration.

Source Data

This section should be filled out with our Source IP addresses and contact information. All of this information will be provided within the Rules of Engagement document that we’ll review as part of our Project Kick-Off Meeting. For the two checkbox questions:

  • Is the above IP address located in your offices? – No, it will be our IP addresses provided.
  • Does the testing company have a NDA with AWS? – No, we do not and it is not a requirement to have one in place.

Testing Details

The final section included in the AWS Penetration Testing Request Form contains some pretty specific questions regarding certain aspects of testing traffic flows. The required portions that need to be filled out here are:

  • Expected peak bandwidth – 0.5 Gbps or 500 Mbps is a generally acceptable and conservative estimate.
  • Expected peak requests per second (RPS) – 100 RPS is a generally acceptable and conservative estimate.
  • Start Date/Time and End Date/Time – This information will be detailed in the ROE and provided to you. It should include the time from the beginning of testing to the end of the documentation and quality assurance phases to allow for testing follow-up, as needed.
  • Do you have a way to immediately stop the traffic if we/you discover any issue? – Yes, if we’re running automated scans or manual exploits on targets, we can always be reached to stop testing traffic.
  • Please provide two emergency contacts – Our contact information will be included in the ROE.

After agreeing to the AWS policies and Terms and Conditions surrounding security testing at the bottom, you are good to go! Generally, you’ll receive an email response from the AWS Security team within 24 hours of submitting the request, but they say it can take up to 48 hours. It’s a good idea to forward this confirmation to your testing team for their records and in case any issues arise during testing. Of course, if you need help when going through an assessment or are unsure about the appropriate responses, don’t hesitate to reach out to your testing team. We’re always happy to assist and fill out the form for you or walk you through it.