Software "bombs," such as the Malicious code planted on the servers of UBS PaineWebber in 2002, can be shockingly effective in committing cybercrimes, despite being fairly simple.

Almost exclusively deployed by company insiders, a software bomb consists of a trigger and a payload. The trigger can be set to go off at a specified time or to react when an event does or doesn't happen--for example, if the bomb maker fails to log in one morning. Unlike viruses or Trojans that work their way in from the outside, software bombs are planted by someone with access to internal software. Bombs typically are designed to delete files, though the only real limitations on their malicious capabilities are tied to their size. Larger bombs are easier to find if a company has processes to review its software.

Software bombs have confounded IT staffs for decades. One of the first occurred in 1988 at securities trading firm USPA & IRA in Fort Worth, Texas. Some 168,000 payroll records were deleted from a database six months after the bomb builder left the company. An employee, who'd been reprimanded for personal use of a computer, was convicted. In 1992, an employee of the United Kingdom's Chilworth Communications was convicted of planting a logic bomb before his resignation in September 1990. The bomb was triggered in October 1990 and damaged important files that cost the company more than $50,000. The former employee had to do only 140 hours of community service and pay nearly $6,000 in compensation.

Companies can take steps to diffuse these explosive situations; most measures have more to do with processes than technology. "Software bombs hide in plain sight," says Vincent Weafer, senior director of Symantec Security Response. As a result, companies must ensure that they don't have the same programmers both develop and test the programs they write. In addition to doing thorough criminal background checks on the IT employees they hire, companies should set up peer reviews so that more than one programmer can analyze and become familiar with any piece of code. "If you've got a really strong development life cycle," says Weafer, "you should know who's touching your software code, what they're doing, and when they're doing it." And what they're planting.

Return to the story:
UBS Trial Puts Insider Security Threats At Center Stage