Glen E. Clarke - CompTIA Pentest+ Certification For Dummies

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.

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.

You should also set up a secure communication channel so that all communications in regard to the penetration test are encrypted. This includes the actual report file as well. Be sure that the report file is encrypted so that unauthorized persons cannot view the file. You could use the Secure Shell protocol (SSH) for secure file transfers, or a tool like GNU Privacy Guard for Windows (Gpg4win) to encrypt files and email messages. You can download the latest version of Gpg4win from 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.

Remember to encrypt the penetration testing report and all communication with the customer that pertains to the penetration testing report.

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.

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 help the pentester 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.

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.

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.

You can minimize the risk by performing the penetration test on exact clones of the systems in a test environment. This environment could be a set of VMs that are exact copies of the production 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 in your budget estimate. It is also important to make sure you give a deadline on when the remediation steps need to be completed — and how long after report delivery retesting is covered in the price.