PTES: Pre-engagement

Contents
1
Overview
2
Introduction to Scope
3
Metrics for Time Estimation
4
Scoping Meeting
5
Additional Support Based on Hourly Rate
6
Questionnaires
7
General Questions
7.1
Network Penetration Test
7.2
Web Application Penetration Test
7.3
Wireless Network Penetration Test
7.4
Physical Penetration Test
7.5
Social Engineering
7.6
Questions for Business Unit Managers
7.7
Questions for Systems Administrators
8
Scope Creep
9
Specify Start and End Dates
10
Specify IP Ranges and Domains
10.1
Validate Ranges
11
Dealing with Third Parties
11.1
Cloud Services
11.2
ISP
11.3
MSSPs
11.4
Countries Where Servers are Hosted
12
Define Acceptable Social Engineering Pretexts
13
DoS Testing
14
Payment Terms
14.1
Net 30
14.2
Half Upfront
14.3
Recurring
15
Goals
15.1
Primary
15.2
Secondary
15.3
Business Analysis
16
Establish Lines of Communication
17
Emergency Contact Information
17.1
Incident Reporting Process
17.2
Incident Definition
17.3
Status Report Frequency
17.4
PGP and Other Alternatives
18
Rules of Engagement
18.1
Timeline
18.2
Locations
18.3
Evidence Handling
18.4
Regular Status Meetings
18.5
Time of the Day to Test
18.6
Dealing with Shunning
18.7
Permission to Test
18.8
Legal Considerations
19
Capabilities and Technology in Place
Overview
The aim of this section of the PTES is to present and explain the tools and techniques available which aid in a successful pre-engagement step of a penetration test. The information within this section is the result of the many years of combined experience of some of the most successful penetration testers in the world.
If you are a customer looking for penetration test we strongly recommend going to the General Questions section of this document. It covers the major questions that should be answered before a test begins. Remember, a penetration test should not be confrontational. It should not be an activity to see if the tester can "hack" you. It should be about identifying the business risk associated with and attack.
To get maximum value, make sure the questions in this document are covered. Further, as the Scoping activity progresses, a good testing firm will start to ask additional questions tailored to your organization.
Introduction to Scope
Defining scope is arguably one of the most important components of a penetration test, yet it is also one of the most overlooked. While many volumes have been written about the different tools and techniques which can be utilized to gain access to a network, very little has been written on the topic which precedes the penetration: preparation. Neglecting to properly complete pre-engagement activities has the potential to open the penetration tester (or his firm) to a number of headaches including scope creep, unsatisfied customers, and even legal troubles. 
The scope of a project specifically defines what is to be tested. How each aspect of the test will be conducted will be covered in the Rules of Engagement section.
One key component of scoping an engagement is outlining how the testers should spend their time. As an example, a customer requests that one hundred IP addresses be tested for the price of $100,000. This means that the customer is offering $1,000 per IP address tested.  However, this cost structure only remains effective at that volume.  A common trap some testers fall into is maintaining linear costs throughout the testing process. If the customer had only asked for one business-critical application to be tested at the same pricing structure ($1,000), while the tester will still be only attacking a single IP, the volume of work has increased dramatically.  It is important to vary costs based on work done.  Otherwise a firm can easily find themselves undercharging for their services, which motivates them to do a less than complete job.
Despite having a solid pricing structure, the process is not all black and white.  It is not uncommon for a client to be completely unaware of exactly what it is they need tested.  It is also possible the client will not know how to communicate effectively what they’re expecting from the test.  It is important in the Pre-Engagement phase that the tester is able to serve as a guide through what may be uncharted territory for a customer.  The tester must understand the difference between a test which focuses on a single application with severe intensity and a test where the client provides a wide range of IP addresses to test and the goal is to simply find a way in.
Metrics for Time Estimation
Time estimations are directly tied to the experience of a tester in a certain area.  If a tester has significant experience in a certain test, he will likely innately be able to determine how long a test will take.  If the tester has less experience in the area, re-reading emails and scan logs from previous similar tests the firm has done is a great way to estimate the time requirement for the current engagement.  Once the time to test is determined, it is a prudent practice to add 20% to the time.
The extra 20% on the back end of the time value is called padding. Outside of consultant circles, this is also referred to as consultant overhead. The padding is an absolute necessity for any test.  It provides a cushion should any interruptions occur in the testing.  There are many events which commonly occur and hinder the testing process. For example, a network segment may go down, or a significant vulnerability may be found which requires many meetings with many levels of management to address. Both of these events are time consuming and would significantly impact the original time estimate if the padding was not in place.
What happens if the 20% padding ends up not being necessary?  Billing the client for time not worked would be extremely unethical, so it is up to the testers to provide additional value that may not normally have been provided if the engagement time limit had been hit. Examples include walking the company security team through the steps taken to exploit the vulnerability, provide an executive summary if it was not part of the original deliverable list, or spend some additional time trying to crack a vulnerability that was elusive during the initial testing.
Another component of the metrics of time and testing is that every project needs to have a definitive drop dead date. All good projects have a well-defined beginning and end. You will need to have a signed statement of work specifying the work and the hours required if you’ve reached the specific date the testing is to end, or if any additional testing or work is requested of you after that date. 
Some testers have a difficult time doing this because they feel they are being too much of a pain when it comes to cost and hours. However, it has been the experience of the author that if you provide exceptional value for the main test the customer will not balk at paying you for additional work.
Scoping Meeting
In many cases the scoping meeting will occur after the contract has been signed. Situation