Tuesday, June 03, 2008
Black, white and gray box tests provide different approaches for assessing the security of your Network and applications. Each approach has specific advantages and disadvantages, and selecting a testing approach needs to be done based on the time and resources available, as well as the overall goals of the test being performed.
You can assume most real-world attackers will approach systems from a black-box perspective. But to better account for the advantage attackers have with regard to time and resources, and to avoid relying on security through obscurity, gray and white box tests can be appropriate approaches as well. Maximizing the security value of testing approaches when you have limited time and resources requires careful test planning and a thorough understanding of how testing constraints affect the completeness of testing results.
Let's take a look at the differences between the three tests.
Black box testing
Black box testing refers to testing a system without having specific knowledge to the internal workings of the system, no access to the source code, and no knowledge of the architecture.
In essence, this approach most closely mimics how an attacker typically approaches applications. However, due to the lack of internal application knowledge, the uncovering of bugs and/or vulnerabilities can take significantly longer. Black box tests must be attempted against running instances of applications, so black box testing is typically limited to dynamic analysis such as running automated scanning tools and manual penetration testing.
White box testing
White box testing which is also known as clear box testing, refers to testing a system with full knowledge and access to all source code and architecture documents. Having full access to this information can reveal bugs and vulnerabilities more quickly than the "trial and error" method of black box testing. Additionally, you can be sure to get more complete testing coverage by knowing exactly what you have to test.
However, because of the sheer complexity of architectures and volume of source code, white box testing introduces challenges regarding how to best focus the testing and analysis efforts. Also, specialized knowledge and tools are typically required to assist with white box testing, such as debuggers and source code analyzers
In addition, if white box testing is performed using only static analysis techniques using the application source code and without access to a running system, it can be impossible for security analysts to identify flaws in applications that are based on system misconfiguration or other issues that exist only in a deployment environment of the application in question.
Gray box testing
When we talk about gray box testing we're talking about testing a system while having at least some knowledge of the internals of a system. This knowledge is usually constrained to detailed design documents and architecture diagrams. It is a combination of both black and white box testing, and combines aspects of each.
Gray box testing allows security analysts to run automated and manual penetration tests against a target application. And it allows those analysts to focus and prioritize their efforts based on superior knowledge of the target system. This increased knowledge can result in more significant vulnerabilities being identified with a significantly lower degree of effort and can be a sensible way for analysts to better approximate certain advantages attackers have versus security professionals when assessing applications.