AWS Penetration Testing Approval Form


#1

Looking for more information to complete the approval for vulnerability and penetration testing for AWS required for Game of Steaks registration https://contribute.cosmos.network/b/xvatkq/view.

The authorization form here https://aws.amazon.com/security/penetration-testing/ requires the following information about the nature of the stress testing for submission:

Testing Details

Expected peak bandwidth (Gbps):*
Expected peak requests per second (RPS):*
Expected peak Queries per second (QPS) for DNS Zone Walking:
Start Date and Time (YYYY-MM-DD HH:MM)* End Date and Time (YYYY-MM-DD HH:MM)*
Additional testing details and why this testing is needed:
What criteria/metrics will you monitor to ensure the success of this test?
Do you have a way to immediately stop the traffic if we/your discover any issue? Yes / No
Please provide two emergency contacts (email and phone):*

What should validators running sentry nodes on AWS fill out here?


#2

We will have a list of IPs where we will be doing some testing from that we will post here sometime soon. Keep an eye out for that.


#3

Seems like we might need some lead time to make sure this form is submitted and accepted by AWS prior to the registration deadline; is there an idea of when we can get better clarity around the above details to make sure we satisfy the registration requirements?


#4

I am also waiting for an answer.

Since AWS rejected some of the participants’ approval requests, there needs to be better clarity around the above details to satisfy the registration requirements.

Other than the testing details section, source data section needs to have guideline, too.

[Source Data]

IP address

Is the above IP address located in your offices?

  • Yes / No

Who owns the IP addresses?

Phone contact for testing team:


#5

Over the past week, we’ve been discussing ways to help Game of Stakes participants navigate the registration process, especially completing the AWS penetration testing form mentioned in the GoS guidelines. To give participants a bit more time to ensure they’re respecting platform policies, we’ve extended the deadline for Game of Stakes registration through October 22nd.

On our end, we’ve evaluated a few different options to help participants meet the requirements of the pentesting form. A few options we’ve discussed (and dismissed) have included:

  • Setting up a VPN that participants could connect to and use to send attack traffic. This option mirrors a practice used in some bug bounty programs, and it would ensure that participants on AWS were respecting policy though it presented a few downsides that would require amending contest guidelines.

  • Collecting IP addresses from participants. This could be an unwieldy process and may not result in an complete and exhaustive list, but it would enable participants on AWS to meet the information requirements of the pentesting form and respect usage policies.

  • Encouraging participants to fill out the form without providing IPs, and instead providing a description of the challenge and its goals with an additional note about potential adversarial activity during the testing of our distributed network. Given how their approvals process works, this probably wasn’t going to end the way we wanted it to so it landed in the “No” pile pretty quickly.

After reflecting on our biggest goals for the contest and reaching out to a few contacts for clarification around conflicting advice, we realized that the options we had been discussing were unnecessary (and kind of a pain, tbh).

When we wrote the guidelines for Game of Stakes, I initially recommended that we mention the pentest form in the guidelines out of an abundance of caution— but Game of Stakes is a cryptoeconomic challenge in an adversarial environment, not a formal pentesting engagement with intrusion technology at the core.

What that means for participants on AWS is pretty simple: you can forget about the pentesting form. Instead, what you will need to do to ensure compliance with AWS policy is request authorization for a simulated event.

To do that, you’ll need to send an email to aws-security-simulated-event@amazon.com, and per Amazon’s guidelines (scroll down to “Simulated Events” to confirm), and provide them with information about:

  • Dates
  • Accounts involved
  • Contact information including phone number
  • Detailed description of the planned events

For the purposes of this form, the best date range to use is October 26th through November 30th. To provide the best answer for the question about accounts involved, you may want to include the AWS accounts of validators you may be working to collude with during the challenge, and also mention that this is a test of a decentralized network so there will participants that you may not be able to include information for. If you’d like to supply contact information for Tendermint team in the form, you are welcome to include security@tendermint.com in your response… if they reach out to us, I will definitely see it there. Additionally, you can always use our Game of Stakes blog posts and the guidelines to add to your description of planned events.

After reaching out to AWS, you should receive an email confirming receipt of your submission from a human who works for them within 2 business days.

If you’ve filled out the pentesting form already, if you’re waiting for a response, or if it has been stressing you out, thank you for bearing with us and being patient through this last change in the run up to the game.

May the odds be ever in your favor :slight_smile:


#6

I attached detail request of information from AWS below.
From this, we expect the testing period cannot exceed 48 hours.(bold)
This might again will be a pain in the ass…
We will try the approval anyway!

Customer ID:
Customer Name:
Email Address:
AWS Account ID load test will be performed from:
Does the customer have an NDA?

Target Data

EC2 Resources:
Cloudfront Distribution:
API Gateway / Lambda ID:
ELB Names:
Non-AWS Target:
Region (please list all regions in scope for testing):

Source Data:

IP Addresses:
Source Account ID:
Regions involved:

Testing Parameters:

How much traffic do you plan to generate by region during testing? (i.e. xx Gb)
What is your expected peak load from source by region? (i.e. xx Gbps)
Are you testing traffic outbound (egress) from EC2, inbound (ingress) into EC2, or both:
Egress. What is your expected peak load from source by region? (i.e. xx Gbps)
Ingress. What is your expected peak load from source by region? (i.e. xx Gbps)

Start Date: End Date (should not exceed 48 hours from start date):
Finite testing details including timeline of testing:
Summary of Test:
Testing Timelines by phase including rps, pps, and Gbps:
Peak bandwidth for each source IP:
Tools Used for each phase of test:
Types of testing to be performed for each phase of the request:
What criteria/metrics will you monitor to ensure the success of this test?
Who is performing the Load Test? (Please provide contact details):
Does the tester have an NDA?


#7

Thanks for your detailed response Jessy.

I have to say that I found the pentesting form requirement somewhat misleading in that it gave me the impression that participants should be hardening our deployments against potential DDoS attacks; a sentiment that I thought was confirmed by other participants. We’ve invested some time in strategies to mitigate specifically against those attack vectors.

Given that it’s clear now that the goals are to test potential collusion strategies between participants, I find myself in a position where I have less than desirable visibility into our application deployment at runtime than I’d like. We would’ve invested more time into it prior to the testnet launch if we had been aware of the parameters of the test.

Since the registration deadline has been extended, should the testnet launch date be extended as well?


#8

Thanks for the thoughtful feedback, and for being patient with us while we’ve been working towards the launch of our adversarial testnet experiment. I completely understand the position you’re describing, and we will do a better job of communicating our goals and contest objectives more clearly in the future.

Our thinking about Game of Stakes has evolved quite a bit since our first post about the competition, and with that change came a bit of a shift in the vision for and goals of the challenge. The investments you’ve made in hardening your nodes against DDoS attacks are still immensely valuable to the overall security maturity of your validator, and they will pay off in mainnet conditions.

We haven’t publicly shared a date for the Gaia-9000 testnet launch just yet, but we are factoring the registration deadline extension into our internal timeline for Game of Stakes launch.


#9

For some reason, my impression was that Gaia-9000 would be launching during Devcon 4? It would be tremendously helpful in our planning if there was better certainty around whether we should expect this to be the case.