CompTIA Pentest+ Certification For Dummies. Glen E. Clarke

from the third party to perform the pentest.

       Security controls that could shun the pentest: Verify whether the pentest team can expect to be blocked or shunned by security controls such as firewalls, intrusion prevention systems, and blacklisting on the network. These controls can limit the pentest and increase the time to perform the penetration test.

       Whether security controls should be tested: Discuss whether you should be testing the effectiveness of the security controls in place. For example, should you report on whether the company security team was able to detect and respond to information gathering, footprinting attempts, scanning and enumeration, and attacks on systems?

      Environmental considerations

      It is important to identify the types of environments that are included within the penetration test. For example, some penetration tests may only include networking assets on the on-premises network, while other penetration tests may only test the web applications used by the company. Following is a list of common environments to include or exclude in a penetration test:

       Network: The network environment could include assets on the local area network (LAN), the wide area network (WAN), and public Internet resources such as DNS servers, web servers, and email servers that are hosted on-premises.

       Applications: A penetration test may include applications used by the company. This could be web applications (websites) running inside the LAN or they could be Internet applications. Many applications make calls to APIs, so check into whether testing of the API is to be included in the pentest.

       Cloud: Many businesses today have moved to hosting their assets in the cloud, such as email servers, web servers, and database servers. Determine if any assets are in the cloud and if these assets should be tested. If there are cloud assets, be sure to get authorization from the cloud provider to perform the pentest on those assets.

      Target audience and reason for the pentest

      During the pre-engagement activities, it is important to determine the target audience for the penetration test and the reason the pentest is being performed. Many companies state that the primary goal of the penetration test is to verify that their systems are secure by seeing how they hold up to real-world attacks. Another goal may be to see how the security team (known as the blue team) defends against the attacks, and to verify the effectiveness of the security controls in place (such as intrusion detection systems and firewalls). As a secondary goal, the company may need to be compliant to regulations stating that the company must have a penetration test performed regularly.

      It is important to know why the pentest is being performed, but also who it is being performed for. The pentest report will need to be written to satisfy the goals of the pentest and be written to include information for the intended audience. For example, upper-level management may just want an executive summary that states how the company held up to the pentest, while the network administrators and security team may want more details on the vulnerabilities that still exist within their systems.

      Communication escalation path

      In addition to determining the target audience for the penetration test and the reason the pentest is being performed, it is also important to determine who the penetration testing team is to communicate with during the pentest. This includes determining when updates are delivered to the contact person and also who to contact when there is an emergency (such as a system or network crash due to the pentest).

Following are some common questions you can ask during the pre-engagement phase to determine communication paths:

       How frequently should updates on the progress of the penetration test be communicated?

       Who is the main point of contact in the company for communication updates?

       Are the penetration testers allowed to talk to network administrators and the security team, or is this a silent pentest?

       Who should be the point of contact in case of emergency?

      As a pentester you also want to be sure you have collected proper contact information in case there is an emergency, such as a system goes down or an entire network segment goes down. Following is the key information you should collect about the customer in case of emergency:

       Name of the company contact

       Job title and responsibility of the contact

       Does the contact have authorization to discuss details of the pentest activities?

       Office phone number, mobile phone number, and home phone number of the contact

       Another reason to communicate with the customer is to let the customer know if something unexpected arises while doing the pentest, such as if a critical vulnerability is found on a system, a new target system is found that is outside the scope of the penetration test targets, or a security breach is discovered when doing the penetration test. You will need to discuss how to handle such discoveries and who to contact if those events occur. In case of such events, you typically stop the pentest temporarily to discuss the issue with the customer, then resume once a resolution has been determined.

      Resources 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.

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.

      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