Penetration testing, often abbreviated as pentest, is a process that is followed to conduct an in-depth security assessment or audit. A methodology defines a set of rules, practices, and procedures that are pursued and implemented during the course of any information security audit program. A penetration testing methodology defines a roadmap with practical ideas and proven practices that can be followed to assess the true security posture of a network, application, system, or any combination thereof. This chapter offers summaries of several key penetration testing methodologies. Key topics covered in this chapter include:
Penetration testing can be carried out independently or as a part of an IT security risk management process that may be incorporated into a regular development lifecycle (for example, Microsoft SDLC). It is vital to note that the security of a product not only depends on the factors that are related to the IT environment, but also relies on product-specific security best practices. This involves the implementation of appropriate security requirements, performing risk analysis, threat modeling, code reviews, and operational security measurement.
Penetration testing is considered to be the last and most aggressive form of security assessment. It must be handled by qualified professionals and can be conducted with or without prior knowledge of the targeted network or application. A pentest may be used to assess all IT infrastructure components, including applications, network devices, operating systems, communication media, physical security, and human psychology. The output of penetration testing usually consists of a report divided into several sections that address the weaknesses found in the current state of the target environment, followed by potential countermeasures and other remediation recommendations. The use of a methodological process provides extensive benefits to the pentester, to understand and critically analyze the integrity of current defenses during each stage of the testing process.
Although there are different types of penetration testing, the three most general approaches accepted in the information security industry are black box, white box and grey box penetration tests. Each of these has distinct advantages and penetration testers should have a clear idea of each.
A black box penetration test mimics as closely as possible a real world attack. In this type of testing, the penetration tester has no knowledge of the system architecture, software, hardware, or any internal workings that are under assessment. In this way, the black box penetration test is conducted in much the same way that a threat actor would attack the system. This means that the penetration tester will ensure that all possible vulnerabilities are identified, that targets are properly enumerated, and all potential attack vectors are used to compromise the system.
Black box testing is very time consuming and expensive. There is also the potential to cause outages and damage to systems that are undergoing the testing. As a result, penetration testers should be cautious when recommending this type of test, as it should be reserved for more mature clients. Having said this, the black box test is as close to a real-world attack a penetration test could mimic. As a result, the reported findings are critical to the client and the security of their system.
The complete opposite of a black box test is the white box test. In this type of testing, the penetration tester has detailed knowledge of the system, applications, hardware, and software. This information can include full network diagrams, operating system inventories, system patch levels, and even source code for applications. In white box testing, the penetration tester is not so much concerned with attacking the same way an external threat would, but rather validating the security controls of the system under assessment. These types of tests are often directed against new applications or systems that are being developed. Testers will often be engaged to find the vulnerabilities in systems in development before they are brought into production and exposed to real-world threats. In mature security programs, these tests are routinely conducted as part of the System Development Life-Cycle. As a result, they are a cost effective way to identify vulnerabilities and remedy them before a system goes to production.
A hybrid of black and white box testing is the gray box test. In this type of test, the tester will have some information about the system, application, hardware, or software under assessment. This information may be limited in scope, such as operating system versions or documentation about internal network architecture. Gray box tests are often undertaken as a limited scope engagement with a specific assessment goal. For example, a penetration tester may be engaged to test the segmentation between a production network domain and their credit card processing domain. In this case, the penetration tester will be given specific information about the two domains, such as IP address blocks and systems that are connected. The aim of a gray box test is often validating security controls in system components without the potential of taking the system offline.
Deciding on which test to perform is often dictated by the objectives laid out by either the client or the organization that employs the pentester. For instance, if the organization being tested is moving a new system from development to production and they want to ensure that they have configured the security settings correctly, they will often ask for a white box test. On the other hand, an organization that has a mature security program and wants to test the overall security system from the perspective of a real-world attack will go with a black box test.
Whether in your own organization or performing a third-party test, there should be some consideration of the target organization's experience with penetration testing. Organizations that are new to this type of test will often express some reservation. This is due to the fact that the test may negatively impact their systems. Oftentimes, performing a white box test will go a long way to relieving this reservation. As was stated previously, organizations with a mature security program will often have no issue with a black box test.