and requirements
When defining the rules of engagement for the pentest, you also want to ensure that you discuss key points surrounding the company’s different resources such as the targets to focus on and who to communicate the results with. You learn earlier in this chapter about a few questions you should ask in relation to resources, but let’s discuss a bit more about resources and requirements.
Confidentiality of findings
A key point to discuss is the confidentiality of the updates given and the results of the penetration test. Determine with the customer who are the authorized persons to receive updates on the progress of the penetration test, who to go to in case of emergency, and who the penetration results (the report) should go to. Be clear that you will be unable to communicate details of the penetration test to anyone not on this authorized list.
www.gpg4win.org. Figure 2-1 shows how you can encrypt a file with Gpg4win on a Windows system.
FIGURE 2-1: Encrypting a file in Windows Explorer with Gpg4win.
Known versus unknown
During the pre-engagement phase, discuss the targets for the penetration test and how to handle the discovery of an unknown device on the network. An unknown device is a device not on the target list, or an unauthorized access point connected to the network, VPN server, or router. If any non-targeted device that makes the client network and security vulnerable is discovered, you should stop the penetration test to discuss with authorized persons on how they want to proceed.
Support for the pentester
When planning for the penetration test, be sure to request all potential resources available to help you determine the number of targets and to learn a bit more detail about the targets. The first important resource to request is documentation: ask for network diagrams identifying servers, routers, switches, and network segments to help you better prepare for the penetration test.
You can request a number of other support resources from the customer:
WSDL/WADL files: You can obtain detailed information such as the methods or functions and their parameter data types supported by a web service by looking at the Web Services Definition Language (WSDL) or the Web Application Description Language (WADL) files. These are XML-based files that describe the web service.
SOAP project file: You can use the SOAP project file to view details about the functionality of a web service.
SDK documentation: You can view the documentation for a software development kit (SDK) to get a better understanding of the functionality provided by the SDK and types of calls that can be made by applications using it.
Swagger document: A swagger document is a document that describes the functionality of an application programming interface (API). Swagger is a technology that helps automate the creation of the API documentation. This documentation could be quite useful to the pentester to help him or her understand the functionality offered by an API.
XSD: An XML schema document (XSD) is used to describe the structure of an XML document and is a great tool to help understand the data stored in XML.
Sample application requests: You could view a sample application request message sent to an application to obtain detailed information about the structure of the request.
Architectural diagrams: A key piece of documentation that can help with application testing is an architectural diagram of the application and all of its components. For example, a web application may communicate with some middleware software, which then communicates with a database. Having a diagram that shows the communication channels for all components is a great tool to help you understand the architecture of an application.
Budget
A big part of the pre-engagement activities is determining the cost of the penetration test. Once you have an idea of the size of the organization and the target resources for the penetration test, you can then work on calculating the cost of the pentest based on the man-hours you expect it to take and the cost per hour for the consultants. As the Penetration Testing Execution Standard (PTES) recommends, you should add 20 percent additional time to the estimated man-hours to accommodate any incidents that may slow down the penetration test. This will help the customer better understand the budget for the penetration test, and you can always lower the cost if you like once the job is complete. Customers are usually okay with the final cost ending up lower than what was quoted, but not happy if the cost goes up.
You also need to determine how payments are going to be scheduled. For smaller projects, you could do a net 30 days after the final report has been delivered, or for medium-sized and larger projects, you could go with a regular ongoing payment schedule that has the customer paying quarterly throughout the duration of the project. For larger jobs, some consultants ask for half of the payment upfront and then additional payments later on.
Impact analysis and remediation timelines
As discussed in “Disclaimers” earlier in this chapter, during the pre-engagement phase, it is critical that you communicate to the customer the risk or impact a penetration test can have on the company’s systems and the network. It is important that you try not to crash systems, and that you test all tools and techniques before using them on your customer’s systems, but in the end, the tools you are using are hacking tools, and they may have unexpected results in different environments. You must state that there is a risk to crashing a system or network in your contract, but stress during your discussions with the customer that you have tested the tools and will not intentionally try to crash systems.
The penetration test report will include remediation steps that the customer needs to take to better secure their assets. It is critical that after the customer implements these fixes that the assets are retested to make sure the penetration test is not successful. Make sure you accommodate for this retesting
