Black-box testing takes an outsider view of the system, and white-box testing takes an internal view of the system.
Black-box testers attempt to affect an application but have no prior knowledge of the system and do not depend on access to source code or knowledge of the system's architecture. Black-box testing looks for vulnerabilities that can be used to gain unauthorized access, denial-of-service, or many other types of attacks. A black-box test can be seen like an external penetration test where the goal is to get access to sensitive data or protected resources.
White-box testers, however, have or are given internal knowledge, potentially access to internal documentation and source code, and other internal resources. While black-box testing attempts to look at vulnerabilities from an attacker's point of view, white-box testing attempts to see threats from a quality assurance perspective. White-box testing validates the code, security functionality, or identifies exploitable vulnerabilities. This can be done with source code analysis tools or manual analysis.
White-box testing might be more acceptable to some organizations because many times black-box testing is performed at the edges of ethical boundaries of the security industry. All black-box testing should be performed by ethical testers that are appropriately engaged with the client and will maintain the confidentially of the results.
Sometimes, though, reformed criminals are recruited to perform black-box testing because they can think like a criminal when trying to find the bugs to exploit for illegitimate access. This is seen as allowing criminals to profit from their crimes, and represents a moral gray area in the information security world.
More details on white- and black-box testing (including gray-box testing) can be found at the Build Security In project by the U.S. Department of Homeland Security and Cigital Inc.
This was first published in May 2010