Home > Security

Computerworld - In today's business environment, companies large and small are looking for ways to secure the applications they create.
Most start by reviewing their internally developed software, but many don't realize that underlying operating systems and other third-party components must also be validated to ensure application security.
This article will discuss two approaches for securing critical software infrastructures -- white-box testing and black-box testing -- and describe the expertise needed and challenges involved with doing each effectively.
White-box testing: Looking under the covers
White-box testing, sometimes called "crystal box" testing, involves looking at a system's code to find bugs. Most organizations use a team that reviews code in internal applications. Sometimes this team falls under the category of quality assurance and isn't necessarily focused exclusively on security. Sometimes the team is in the IT group and is more security-focused. The team is usually composed of highly skilled engineers who review code manually and with automated tools.
Two common issues with white-box testing are the following:

1. Manual reviews: Everyone has days where they are less effective, and manual reviews require the reviewer's skills to be at their peak at all times. When reviewing code all day, it can quickly become tedious, leading to burnout and reduced effectiveness.


2. Source code: Source code generally isn't available for all of the components that make up an enterprise application.

Unfortunately, the expertise required for auditing binary code is even rarer than the expertise required for testing source code. Maintaining a component-reuse repository and reusing binary-only components that have already been reviewed can help by avoiding duplication of the review work. Another option involves using automated binary-code analysis tools.
The major advantages of the binary-code analysis approach include:

• The ability to integrate code analysis into standard automated build processes and procedures.


• The improved ability to cover all produced code within an organization by reducing the dependency on a scarce human resource -- the security analysis team.


• Increased assurance that the analyzed code is the actual code deployed into production -- eliminating the risk of analyzed source-code modifications (and the potential for introduced security exposures) after the security review is completed.

Black-box testing: Making the application run the gauntlet
In most organizations, black-box testing is done by the same security team that does the white-box code analysis, but sometimes it's done by the quality assurance team or the application development team.
Rather than looking at the code (inside the box), the security team pokes at the box from the outside, disregarding any knowledge of the application's internal workings. This dual perspective is essential,