by The success of a penetration test relies 50% on the planning and the information that it has been obtained in advance and the other 50% of the actual deployment of the test. Many times the proposal documents might not contain all the necessary information for the security consultant or the pentester.
As a penetration tester we need to ensure that the requirements of the project are met and there are no delays or any surprises (outside of the actual test) that will impact the assessment and the results.This can happen only with 2 ways:
- Validation of the information in the proposal
- Establishment of a communication channel with the client to obtain further information around the pentest
Checklists are always helpful as we don’t forget what information is needed. Below is a checklist that is focused on web application assessments and it can assist pentesters especially the newest in the field to ensure that they have all the prerequisites to conduct the project with efficiency and to prevent any failures.
- Determination of the type of pentest (Blackbox, Whitebox)
- Key objectives behind this penetration test
- Location address and contact (if it is an onsite job)
- Validation that the Authorization Letter has been signed
- URL of the web application that is in scope and validation that is accessible
- 2 sets of credentials (normal and admin or a privilege user) and validation that are working
- Determination of the environment (Production or UAT)
- Number of static and dynamic pages
- Testing Boundaries (DoS, Brute force attacks etc.)
- Technologies (PHP, ASP, .NET, IIS, Apache, Operating system etc.)
- Any VPN or port numbers are needed and verify those ahead of time
- Any web services that the site may use.
- Any pages that the client does not want to be tested.
- Any pages that submit emails
- IP address of the tester
- Escalation contact
- 3rd parties that needs to be contacted in advance of the pentest
- Web application firewalls and other IDS in place
- Timeframe of the assessment (dates and hours)
- Diagrams and any kind of documentation
- Validation that a backup has been performed recently on the application
- Other client requirements
P.S
If you think that there is more information that’s needs to be gathered please reply with a comment and I will update the list.
Penetration Testing Lab 
Great list! Wanted to add a couple things that you would want to know before starting the test:
1.) In addition to knowing the URL and verifying access to it, you would also want to know if any VPN or port numbers are needed and verify those ahead of time as well.
2.) Any web services that the site may use.
3.) Any pages that the client does not want to be tested.
I have added those elements as well.Thank you Ryan for your contribution!
You should also add ‘Any pages that submit emails.’ How many times have you spammed a Client because of a lack of effect form field validation? All those “Contact Us” pages that send thousands of emails while testing for XSS, CSRF and SQLi.
That’s a good point Joseph! Thanks!
Engagement letter to keep you out of jail.
Information Added..! 🙂
Validate that no licenses of testing tools have expired, also check versions. Especially if not pentesting on a regular basis this can become an issue (though an internal only).
Also make sure that there are no application deployments planned during the assessment – it might lead to inconsistent testing results.
To expand a little bit on Andres’ comment: You want to know their standard maintenance schedule as well. The testing results could be unstable during maintenance windows.
I’d add some more, some of which I’ve learnt the hard way…
* IP address/es of the target systems; their local resolution might not match your Internet based resolution.
* Two accounts per level of access per tester – two accounts per level so if one gets locked out a tester can use the other one while waiting for the first to be re-enabled, two accounts per level so a single tester can test “horizontal” privilege escalation, “per level” so you don’t presume there’s just users and admins, “per tester” so each tester can test all interactions between their accounts without having to consult with colleagues.
* Make it “any *services* which send emails”; WAFs that email on every alert can make your test “fun” for their admins.
* WAF and IDS – are they part of the test? If not then disable them if pre-prod, whitelist the testers if prod, always test under “worst case scenario” as that ensures that the application is secure, AFAICT, even if the WAF fails open and the IDS can be bypassed.
Handy list, nicely done 🙂