Application security testing in black and white
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:
- 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.
- 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,
Security
Additional Resources



Learn the important issues you must consider before starting your next mobility initiative. Get your mobility white paper from IDC now, compliments of Sybase.
White Papers & Webcasts
Death to PST Files
Download Now
The Tangled Web: Silent Threats & Invisible Enemies
Download Now
Tape Killed the IT Guy
Watch Now
Forrester Consulting Mobility Study: Taking Control of Enterprise Mobile Device Diversity
Download Now
BRM: What You Can Do To Reduce Risk In Challenging Times
Watch this webcast now!
What IT Must Do to Support Employee-Owned BlackBerry, iPhone and Android Mobile Devices
Download Now
Web 2.0, Social Media and the Dark Web - A Web Criminals Paradise?
In this discussion, learn about the challenges of protecting your users from the potentially unsafe content hidden in the "Dark Web".
eGuide: Enterprise Security
Smart Security Strategies for 2010. Read now!
Disaster Recovery 2008: Reduced Costs and Improved Performance
How long can your Enterprise afford to be without your data? With an accelerated disaster recovery program, you never have to answer this...

