In a black-box testing assignment, the penetration tester is placed in the role of the average hacker, with no internal knowledge of the target system. Testers are not provided with any architecture diagrams or source code that is not publicly available. A black-box penetration test determines the vulnerabilities in a system that are exploitable from outside the network.
This means that black-box penetration testing relies on dynamic analysis of currently running programs and systems within the target network. A black-box penetration tester must be familiar with automated scanning tools and methodologies for manual penetration testing. Black-box penetration testers also need to be capable of creating their own map of a target network based on their observations, since no such diagram is provided to them.
The limited knowledge provided to the penetration tester makes black-box penetration tests the quickest to run, since the duration of the assignment largely depends on the tester’s ability to locate and exploit vulnerabilities in the target’s outward-facing services. The major downside of this approach is that if the testers cannot breach the perimeter, any vulnerabilities of internal services remain undiscovered and unpatched.
The next step up from black-box testing is gray-box testing. If a black-box tester is examining a system from an outsider’s perspective, a gray-box tester has the access and knowledge levels of a user, potentially with elevated privileges on a system. Gray-box pentesters typically have some knowledge of a network’s internals, potentially including design and architecture documentation and an account internal to the network.
The purpose of gray-box pentesting is to provide a more focused and efficient assessment of a network’s security than a black-box assessment. Using the design documentation for a network, pentesters can focus their assessment efforts on the systems with the greatest risk and value from the start, rather than spending time determining this information on their own. An internal account on the system also allows testing of security inside the hardened perimeter and simulates an attacker with longer-term access to the network.
White-box testing goes by several different names, including clear-box, open-box, auxiliary and logic-driven testing. It falls on the opposite end of the spectrum from black-box testing: penetration testers are given full access to source code, architecture documentation and so forth. The main challenge with white-box testing is sifting through the massive amount of data available to identify potential points of weakness, making it the most time-consuming type of penetration testing.
Unlike black-box and gray-box testing, white-box penetration testers are able to perform static code analysis, making familiarity with source code analyzers, debuggers and similar tools important for this type of testing. However, dynamic analysis tools and techniques are also important for white-box testers since static analysis can miss vulnerabilities introduced by misconfiguration of target systems.
White-box penetration testing provides a comprehensive assessment of both internal and external vulnerabilities, making it the best choice for calculation testing. The close relationship between white-box pentesters and developers provides a high level of system knowledge but may affect tester’s behaviors, since they operate based on knowledge not available to hackers.