All organizations with a reasonably mature software development and delivery process expose new or modified applications to extensive testing. However, security built into an application is often excluded from the testing process or is reviewed during functional testing. This approach is fine for things like access controls, but what about overall assurance that the application is secure from criminal hacking activities?
There are three basics ways to test software—black box, white box, and gray box. Black box testing is also known as functional testing. This approach is commonly used to allow users to test applications prior to moving them to production. No information about the internal structure of the system is revealed to testing personnel. This is useful in determining whether all functional requirements were met and whether the application is stable. However, it doesn’t necessarily allow testing of technical requirements designed to harden the system
In white box testing, the tester has access to all source code, system architecture documentation, and the database. This provides her with everything she needs to test intended security behavior. She can also search for ways to circumvent security controls or application controls such as buffer overflow prevention.
This is usually the best way to test application security. It makes no sense to hide the internal structure of a system when testing system assurance. It should be assumed that attackers will eventually obtain everything there is to know about an application. Your tester should have the same advantage.
The final testing approach is gray box. In gray box testing the tester has some visibility into the system, usually the database. For example, he can set up test data, run a routine, and then check the contents of one or more tables.
Each of these testing methods is useful, depending on the intended outcome of the testing process. In many cases, the use of multiple approaches might make the most sense.
Regardless of the testing method used, there are two points you should take away from this discussion. First, be sure to include security requirements in your test plans. Second, drill down into the inner workings of the target application as far as necessary to ensure the appropriate level of quality assurance.
Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be published in Q1/2013). Before joining the private sector, he served 10 years in the United States Army Military Police with four years as a military police investigator. He has an MBA and CISSP certification. He is also an online instructor for the University of Phoenix.