Other than completing the form via the AWS Console support, are there other ways to request authorization for penetration tests. I’m sure I’ve seen something in the breakout notes from various people to say there is but I can’t find any references to additional methods.
Thanks
6 Answers
In addition to the online form I would recommend contacting your AWS account team. They will be able to assist with this request.
I had a question (on network specialty) around pre-authorised vulnerability scanners on aws marketplace. Whether you need to registester this scanning within AWS or not. I was googling for a while to verify that and couldn’t find anything on AWS doc site other than "you need to register all scans" – but in here https://qualysguard.qualys.com/qwebhelp/fo_portal/scans/ec2_scan_preauthorized.htm it says that because it is pre-authorised – you don’t need to request to AWS again. Interesting, I will try to confirm that somehow
Here are a few excerpts from the AWS Penetration Testing Request Form that help answer this question:
AWS Penetration Testing
https://aws.amazon.com/forms/penetration-testing-request?catalog=true&isauthcode=true
In order to request permission to conduct vulnerability and penetration testing originating from any resources in the AWS Cloud, the following information is required. The requesting party must also accept the Terms and Conditions and AWS’s policy regarding the Use of Security Assessment Tools and Services.
Penetration Testing (the “Testing”):
(a) will be limited to the source and destination IP addresses, network bandwidth, and instance-level resources (such as CPU, memory and input/output) specified in your AWS Vulnerability/Penetration Testing Request Form, and the times and other conditions specified in the authorization email that will be sent to email addresses provided above,
(b) will not involve t2.nano, m1.small or t1.micro instances (as described on the AWS website, located at http://aws.amazon.com),
(c) is subject to the terms of the Amazon Web Services Customer Agreement between AWS and Company (available at http://aws.amazon.com/agreement/) (the “Agreement”),
(d) and will abide by AWS’s policy regarding the use of security assessment tools and services (included below).
Your performance of the Testing and the results will be considered AWS Confidential Information under Section 9 of the Agreement.
AWS’s policy regarding the use of security assessment tools and services allows significant flexibility for performing security assessments of your AWS assets while protecting other AWS customers and ensuring quality-of-service across AWS.
You are NOT limited in your selection of tools or services to perform a security assessment of your AWS assets. However, you ARE prohibited from utilizing any tools or services in a manner that perform Denial-of-Service (DoS) attacks or simulations of such against ANY AWS asset, yours or otherwise. Prohibited activities include, but may not be limited to:
Protocol flooding (eg. SYN flooding, ICMP flooding, UDP flooding)
Resource request flooding (eg. HTTP request flooding, Login request flooding, API request flooding)
It is the sole responsibility of the AWS customer to ensure the tools and services employed for performing a security assessment are properly configured and successfully operate in a manner that does not perform DoS attacks or simulations of such. It is the sole responsibility of the AWS customer to independently validate that the tool or service employed does not perform DoS attacks, or simulations of such, PRIOR to security assessment of any AWS assets. This AWS customer responsibility includes ensuring contracted third-parties perform security assessments in a manner that does not violate this policy.
A bit more in here again
https://nexpose.help.rapid7.com/docs/nexpose-scan-engine-pre-authorized-ami
Because the engine is pre-authorized by AWS, this normally suspicious traffic is allowed to occur between your EC2 instances without the need to fill out a separate form.
By design, the pre-authorized engine is only allowed to scan assets in a single VPC. The customer is expected to deploy multiple pre-authorized engines if they wish to scan multiple VPCs. If the customer wishes to scan non-AWS assets, they are expected to deploy engines outside of AWS.
We had some trouble organising penetration testing with AWS a few months ago and it turned out to be a problem with the definition of "penetration testing". We wanted to test a website that was partially implemented with static content in S3. Our request for penetration testing was denied as their acceptable use policy strictly forbids any penetration testing on S3 buckets. This is in line with the Shared Responsibility Model – S3 as a managed service does not make the infrastructure visible to the customer so compliance such as penetration testing of the infrastructure is AWS’s responsibility not the customer’s.
The customer still has responsibility however for S3 configuration, so any penetration testing of S3 conducted by the customer needs to focus on that (e.g. S3 bucket security configuration) and not on attacking the underlying infrastructure. This meets the AWS acceptable use policy, and is called (by AWS) "auditing" of the managed service configuration rather than "penetration testing". You don’t need to request permission to do it, you just need to make sure the test provider understands that the managed service infrastructure must not be targeted.
According to AWS Support:
"The pre-approved scanners are already authorized to perform testing, thus traffic coming from an IP address of a pre-approved scanner will not be flagged as malicious traffic. As mentioned before though, If you are testing between different VPC’s and depending on the type of testing you’ll be conducting, it is best to submit a penetration test even when making use of a pre-approved scanner.
Penetration testing and other simulated events are frequently indistinguishable from malicious activities, thus we have established a policy for customers to request permission to conduct penetration tests and vulnerability scans to or originating from the AWS environment."
In short, the answer is:
1 – Request penetration testing
2 – Use a pre-approved scanner from the AWS Marketplace
I’ve not found anything to back it up yet, but I suspect this might be the answer. Will try and do some digging to confirm this
I had a question on the exam with a pre-authorized vulnerability scanner on AWS marketplace as a viable answer.