(IP) ranges: Determine IP ranges that are to be targeted during the penetration test.
Domains: Determine any internal and external domain names that should be targeted during the penetration test.
Application programming interfaces (APIs): Identify any APIs that should be tested. APIs are code that is called upon by other applications and should be tested. This includes stand-alone APIs such as custom DLLs and web APIs such as RESTful web services.
Physical locations: Determine the physical locations that are in scope with the penetration test and if you have permission to attempt to bypass physical access controls to gain access to those locations. For example, a customer may state that the company’s Boston data center is in scope, but data centers at other locations are not.
Domain name system (DNS): Identify the DNS server addresses used for internal DNS and external DNS.
External versus internal targets: Take time to identify what internal targets (on the LAN) are in scope and what external targets (on the Internet) are in scope.
First-party versus third-party hosted: It is important to identify assets that exist on-premises (first-party) and assets that are hosted in the cloud (third-party).
Depending on the type of testing being performed, there are a number of other questions you can ask during the scoping of the project. The Penetration Testing Execution Standard (PTES) website found at www.pentest-standard.org has an extensive list of questions you can ask. The following sections list example questions for each different type of test.
General questions
What is the goal of the penetration test? (Why is it being done?)
Is the pentest being performed for compliance reasons?
What hours of the day can the penetration test be performed (business hours/non-business hours)?
What are the internal and external target IP addresses?
Are security controls in place such as firewalls and intrusion detection systems?
If a system is compromised, what actions should be taken next (for example, no action, elevate privileges, and so on)?
Web application testing questions
How many web applications/sites are being tested?
How many of those require authentication?
How many static pages are in those sites?
How many dynamic pages are in those sites?
Is the source code available for review?
Is authentication testing to be performed?
Wireless network testing questions
How many wireless networks are there?
What wireless encryption protocol(s) are being used?
What is the area covered by wireless?
Should detection of rogue devices be performed?
Should wireless attacks against clients be performed (or just focus on the access point)?
How many wireless clients are there?
Physical security testing questions
Is physical security testing part of the pentest?
How many locations are there?
Are the locations shared with other businesses? If so, what floors do you occupy?
Are lock picks and bump keys allowed to bypass a locked door?
Are video cameras being used? If so, does the customer own those devices?
Social engineering testing questions
Is social engineering testing part of the pentest?
Does the customer have email addresses for social engineering?
Does the customer have phone numbers for social engineering?
Testing questions for IT staff
Are there fragile systems that are easy to crash?
What is the mean time to repair from a system outage?
What are the business-critical servers and applications?
Are backups tested regularly?
Is there a disaster recovery procedure in place for devices and systems being tested?
When was the last backup performed?
Identifying the Rules of Engagement (RoE)
As part of the planning and scoping phase of the CompTIA penetration testing process, it is important to define the rules of engagement (RoE) for the penetration test. The “rules of engagement” refer to any restrictions and details in regard to how the customer wants the penetration test performed. Following are some points covered by the rules of engagement:
The timeline for the penetration test: Determine the start date and the end date of the penetration test based on a schedule for each task and phases being performed.
When testing is to be performed (time of day): Define the hours of the day testing is permitted. This could be during work hours, non-work hours, or on weekends.
Types of allowed and disallowed tests: Ensure that the RoE specifies what types of tests are allowed during a penetration test and any tests that are not allowed. For example, many companies would not want a DoS attack to be performed during a penetration test, so a DoS attack should be added to the RoE as a disallowed test.
What to test (locations, targets, services, and applications): Identify what resources or targets will be tested. This includes the office locations, target systems, target services and applications, and the accounts to be targeted.
How the results should be reported: The details and results of the penetration tests, such as the vulnerabilities associated with each system, are highly sensitive. Define what method of communication is acceptable to communicate the pentest details and results. Communication should be encrypted, whether it is sent via email or on a disk.
Who should contact the pentest team: Define who is allowed to communicate with the pentest team during the penetration test.
How frequently updates should be communicated: Define who the pentest team is to go to with updates on the progress of the penetration test and how often updates should be communicated.
Authorization to perform the pentest: Verify that you have signed authorization to perform the penetration test.
Legal considerations with third parties: Verify whether any of the systems or services are hosted by a third party such as an ISP or cloud provider. If a third party is used to host services, verify that you