Penetration Test Preparation Checklist

Penetration tests are risk-oriented and consist of activities ranging from vulnerability assessment to post-exploitation. Effective pen testing planning should include establishing specific test goals which helps ensure the test meets expectations and these questions should always be addressed during the scoping process.

This piece features an actionable checklist for effective penetration testing along with recommended questions to save time scoping and planning.

Penetration Test Preparation Checklist 

Penetration Testing Goals 

• Does the test have specific compliance goals? For example, is it required to meet standards such as Payment Card Industry (PCI), Health Insurance Portability and Accountability Act (HIPAA), etc.?
• Is any network segmentation testing expected (i.e., required for an isolated PCI cardholder data environment)? If so, network ranges of segments must be provided.
• Do specific systems, services or functions warrant extra attention?
• Is stealth required (e.g., is the security operations center’s response being tested)?
• Are humans (i.e., social engineering) in scope?
• Do any of the systems to be tested use uncommon or specialized technology stacks or protocols?
• Are any of the devices to be tested considered sensitive and extremely critical to life or infrastructure (e.g., devices attached to patients, controlling the power grid or required for human safety features)?
• To what degree is pivoting to additional systems in scope?

READ: How to Use Pen-Test Reports to Improve Security 

Testing Access and Permission 

• How will testers access the in-scope network or applications for testing (e.g., a virtual private network, a tester-provided appliance)?
• Are network credentials required for this test, and have they been provided?
• Have the testers been allow-listed in firewall, web application firewall (WAF) and intrusion prevention system (IPS) rules as needed?
• Are any in-scope networks or systems hosted by a third-party? If so, have the appropriate pen-test notification forms been submitted?

Networks 

• Have all internal and external in-scope IP ranges been provided?
• Have the IP addresses of any devices excluded from scope been provided?
• If the internal range is large (e.g., a Class A or many Class B networks), can a network diagram or spreadsheet be provided to narrow the test scope? Can sampling be used for larger subnets?

Web Applications 

• Have at least two user accounts been provided for each normal role within the application to test horizontal and vertical privilege escalation?
• If there is an administrative role, has an administrative account been provided?
• Is testing being performed in production or a lower environment? If this is not production, will the testing team have exclusive access to the environment or is it being used by other testing teams?
• Are there any scheduled outages (e.g., deployment windows) for the environment being tested?
• For code still in development, is it considered stable for the duration of the test or are developers actively modifying or adding functionality?

Mobile Applications 

• It is normal for a mobile application penetration test to be conducted against a development version of the app? Have the testers been provisioned for developer/quality assurance (QA) access so they can install the correct version of the app?
• Which platforms are in scope (e.g., iOS, Android, etc.)?
• Will source code be provided?
• Does the application implement certificate pinning? If so, can a version be provided with certificate pinning disabled?

Web Services 

• Has a project file (e.g., SOAP UI or Postman) been provided? If not, have sample valid service requests (i.e., HTTP) been provided?
• If access to web services is role-based, has access been provisioned to different test accounts with different roles?
• Have instructions for authenticating to the web service been provided (e.g., for how to obtain a valid bearer token)?

Administrative 

• Are there any time restrictions on testing (e.g., outage windows, business hours, etc.)?
• Have two emergency (24/7) points of contact (primary and backup) been provided?
• Has a channel for sensitive communications (e.g., secure mail, portal) been provided?
• How often and in what format should test updates be provided? 
• Are there any special rules of engagement? The standard rules are:
  • We will stop testing and notify on signs of compromise or discovery of critical issues 
  • We will move forward only with known, proven, stable exploit code
  • If we find sensitive data, we will extract only the amount necessary (within reason) to demonstrate risk or to pivot (if pivoting is in scope)
• Exceptions to the rules must be stated by the client in writing (by email).

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.