Developers Growing Challenge

Enterprise application developers are squarely in the cross hairs of the next generation of IT system attacks. As generic infrastructure security and user awareness issues are increasingly addressed, the most dangerous remaining and newly arising vulnerabilities are those in the applications that define any modern organizations procedures and controls.

When perimeter security is lax, attackers will exploit promiscuous connectivity or weak password discipline; when users are careless and/or clueless, opportunistic attacks such as e-mail worms will have free rein. In the current environment, though, there are three reasons that line-of-business applications are ever-more-attractive targets.

First, increasingly complex business logic and growing integration among application modules that were not specifically designed to work together create a rising number of places where error may lurk or where unexpected interactions may arise.

Click here to read about an Internet-worm early warning system proposal.

Second, the costs of finding and fixing vulnerabilities in a vertical application must be borne by the relatively narrow community of users in a specific commerce or industry segment—unlike more broadly felt problems in perimeter or platform security, whose costs of mitigation are spread across much larger groups of users.

Finally, supply chain pressures dictate that enterprise online presence, in the form of network-facing applications, must be accessible to the largest possible number of potential users and must meet aggressive targets for rapid development and deployment.

Application developers thus find themselves under pressures that lead to the creation of systems with numerous and subtle flaws that are forbiddingly costly to fix. Even so, organizations feel compelled to expose the results of these development efforts to increasingly well-informed and motivated assailants.

Enterprise sites cannot address this problem by adding layers of firewalls, by imposing additional modes of user authentication or by generating more detailed documentation of routine IT tasks.

None of these measures addresses the fundamental problem of an application thats intentionally exposed to an authorized user or invited customer but that offers unintended access to information or opportunities to do harm.

The developer contribution to enterprise information security has to be made from the inside out. It must take the form of code that grants only the privileges needed to perform a business task.

Thats not a complete solution, however: An enterprise could still be defrauded by the use of a stolen credit card number, for example, or by any of a long list of traditional con games or misrepresentations. The development teams definition of success must therefore be the extent to which risk is shifted from the domain of technical flaws to the domain of business practices, not the degree to which all risk is removed.

If developers can look their business-unit managers in the eye and say, "The only risks that remain are the ones that you decide to take by serving the target customer in the target market," then they have done their job.

Software developers climb ladders of abstraction. These begin at the bare-metal level of those who write device drivers, rise to the interface level of those who write operating systems or network software, and eventually reach the airy heights of those who think in terms of business processes.

Application platforms such as Java or Microsoft Corp.s .Net and emerging standards such as Business Process Execution Language encourage developers to take advantage of software abstractions that conceal what are supposed to be irrelevant details. Attackers, though, can also take advantage of a developers assumption that a piece of code will be used only as intended.

Buffer-overflow attacks, for example, continue to succeed because developers continue to make unconscious assumptions that a software module will receive only input that makes sense in the context of how that module is meant to be used.

"An Empirical Study of the Reliability of Unix Utilities," a classic paper written by Barton Miller et al. and published in 1990, was inspired by a frustrating afternoon of accessing remote systems over an electrically noisy connection. The paper gave early and somewhat whimsical exposure to the problem of developers assuming that input would conform to their expectations. It found that random input to many auxiliary programs, such as the ftp file transfer utility, could often crash a program or even a machine.

A more recent anecdote from Mark Graff et al., in a 2003 book titled "Secure Coding: Principles and Practices," described a buffer-overflow attack directed against a mouse driver. The driver was fed absurdly huge values for X and Y coordinate positions that developers had never even considered because they exceeded the dimensions of any conceivable display.

Next Page: Defending Against Attacks