CompTIA Pentest+ Certification For Dummies. Glen E. ClarkeЧитать онлайн книгу.
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 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.
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 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.
Defining Targets for the Pentest
During the planning and scoping phase, you need to define the targets for the penetration test. The contract agreement should have a section on target selection that specifies the systems that are the targets of the pentest. Let’s take a look at common targets for a penetration test.
Internal and external targets
When performing a penetration test, you will be working with internal targets, external targets, or both. An internal target is a system that exists inside the corporate network and is not accessible from the Internet because it is behind firewalls. An external target is a system that is reachable from the Internet and resides in the demilitarized zone (DMZ) network or in the cloud.
You will need to determine what internal systems (targets) should be tested and obtain the internal IP addresses or domain names for these assets. For example, you’ll need to obtain the internal addresses of the intranet servers, mail servers, file servers, or network-attached storage (NAS) devices, to name just a few. When identifying the internal assets and IP ranges, it is important to identify if those assets are on-site or off-site. On-site resources are systems and devices that exist on the network at the location being assessed, while off-site resources could be systems in the cloud, at an alternate site, or maybe resources that are mobile like a network on a boat or other vehicle. When conducting a pentest of the internal network, you may have to visit different locations to perform the penetration test, which should be reflected in the budget.
You will also want to be sure to determine the external IP addresses and domain names of systems to pentest. This is critical to verify as you do not want to try to exploit an external address not owned by the customer.
First-party versus third-party hosted
As I mention earlier in this chapter, you need to verify where the targets are being hosted, whether by the customer (first party) or by an outside company (third party). If systems are hosted by a third-party company such as an ISP or cloud provider, you need to get authorization from the third party to perform the pentest on those assets.
Other targets
When performing a penetration