eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
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
TKTK
Higher-level application modules tend to incorporate higher-level assumptions about the kind of input theyll receive. Developers who dont challenge their own assumptions—writing necessary validation routines and bounding their code with robust exception handling—are begging to be next on the list of “Can you believe that someone still got hit by this?”
Network-facing applications invite developers to rely on additional abstractions—a trend thats accelerating with the emergence of frameworks such as Microsofts “Indigo” that offer developers access to immense capability with minimal writing of code.
Its therefore essential for developers to understand at least the rudiments of both hardware and software infrastructure, warned Andrew Plato, a consultant at Anitian Corp., in Beaverton, Ore. Unfortunately, Plato said, that is not always the case. “I find that development teams have virtually no comprehension of network or infrastructure security,” he said. “Ive had developers ask me, Whats an IP address? Whats a DNS server? Youd think theyd know that or want to know that, but they say, I write software.”
eWEEK Labs concurs with Platos warning: To write a network-facing application while relying entirely on platform abstraction is like driving down a paved highway and looking only at lane markers, oblivious to even the possibility of potholes.
One piece of network cable is assumed to be substitutable for any other that meets the same specifications, but enterprise application code is a product of personal creation that reflects personal training, attitude and culture.
The culture of programming continues to evolve. Computer science educators have described to eWEEK Labs the changing approach to the application development task that theyve seen in successive generations of students: First-generation developers got their initial exposure to computers in the context of learning to program, while current students are at least as likely to come from a background of playing computer games.
The result that those professors see, understandably, is a growing inclination for game-imprinted students to declare success and move on as soon as a piece of code does what its supposed to do. Thats a far cry from considering the things that code might be made to do, let alone crafting it to do nothing that is not actually desired.
Development managers may thus benefit, ironically, from the strictures of legislative and regulatory mandates such as the Sarbanes-Oxley Act, with associated demands for precise characterization of IT system function and control.
Telling a developer who wrote a piece of code that another developer must deploy it might once have been taken as an insult or at least an unnecessary nuisance, but under SarbOx, it merely becomes the way that things have to be done. IT governance aids such as Mercury Interactive Corp.s IT Governance Center may therefore belong on a development managers next tools budget .
Development teams familiar with the disciplines of projects undertaken for the U.S. Department of Defense have a head start on producing highly structured documentation of application and component interactions. Tools such as Telelogic ABs Tau are well-established in such environments and may find growing interest in mainstream enterprise development organizations as well.
Development managers must be prepared, however, to make the case for investments in security and IT governance training and tools for their teams. Myths abound, said Anitians Plato, that only certain organizations need to worry about attacks. “Most hackers do not care about your systems,” he said. “The fact that you process or store boring or low-priority information does not make you more secure.”
The kind of security that can be added to the outer shell of enterprise IT is, for the most part, in place. It now falls to developers to understand their role and to development managers to provide needed tools to satisfy intensifying demands for the kind of security that has to be embedded in applications.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.