Developers Growing Challenge

By Peter Coffee  |  Posted 2005-05-16 Print this article Print

Case Study: The need for complex, open apps means the 'art of abstraction' must be unlearned.

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

Peter Coffee is Director of Platform Research at, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel