The front door is

By Peter Coffee  |  Posted 2004-12-13 Print this article Print

open"> "People just dont realize how vulnerable their applications are," said Denim Group partner Dan Cornell. "Theyve been looking at the host level so long, and they dont realize that its not their back door—its their front door thats wide open."

Security practices that have grown up from a network-centric view, with a focus on concrete IT assets to be protected, must be turned sideways and inside-out to focus instead on protecting business function and efficiency. Close attention must also be paid to satisfying a growing list of stakeholders, as IT security becomes both a political football and a public relations hot potato.

"Everyone has their own set of security requirements," said Richard Tracy, chief security officer at Xacta Corp., in Ashburn, Va. A modern security posture, Tracy said, differs from mere vulnerability scanning because "it starts with the question, What are you measuring against?" Xactas IA Manager product "forces you to account for requirements: We calculate a risk posture based on a variety of parameters," he said.

Click here to read more about how to secure Web applications. When development teams play expanded security roles, their first obstacle may be as simple as differing definitions of familiar terms.

When a firewall vendor talks about protecting "applications," said John Amaral, chief technology officer at Network Engines Inc., in Canton, Mass., "theyre talking about the seventh layer of the [OSI] model—things like HTTP." To the enterprise developer, those so-called applications are mere protocols, Amaral said. Protecting them does nothing to protect the enterprise against vulnerabilities at the higher levels of business process that a development team seeks to enable.

Protecting the most value-adding levels of the enterprise application stack has to mean something that most network-oriented security tools arent designed to address, Amaral said. "Do they protect what goes in and out? Do they protect the traffic?" he asked. "Or do they protect the sequence of actions or the settings in which the application is conceived or the inherent vulnerabilities in how the application was coded?"

The latter question, he said, is by far the most important to be answered by the security-oriented development team.

When a team allows its focus to drift downward into the plumbing of the network, instead of remaining at the level of the business mission, the result is not merely ineffective but actually detrimental.

"Good security at the application layer knows who you are and where youre supposed to go," said Ken Evans, product management vice president at Fortress Technologies Inc., in Oldsmar, Fla.

Security wrapped around the application can actually have a counterproductive effect, Evans added. When everyone knows that an application is not itself secure, the result is that security is added at the level of the network connection to that application, he said.

When security is defined by the characteristics of the connection rather than by the needs and privileges of the user, then a single user may encounter different application capabilities depending on whats supposed to be a transparent choice among different modes of access.

"This user today is less trusted because theyre coming in on wireless? Thats unnecessary paranoia, and it leads to the user not using the application as it was intended," said Evans.

A user who cant perform data entry from the field without going through a cumbersome added security process may very well decide to wait and perform that task back at the office, said Evans. The result, he suggested, often may be the loss of the improved accuracy or timeliness that was sought by making a wireless investment.

The guiding principle for application architects should be "one system, one security," Evans said.

Based on eWEEK Labs observations of how users behave and how attackers exploit that behavior, we would agree: A properly authenticated user interacting with an application that has properly limited access to enterprise data should have the same privileges regardless of the type of connection being used.

Wireless connections must be adequately secured, to be sure, to offset the ease of access that a potential eavesdropper enjoys without the need to tap a wired link. Perversely, though, said Evans, the awareness of wireless vulnerability often can lead to a situation in which wireless users are more effectively authenticated—and their interactions more carefully bounded—than wired users. "People need to start looking at a converged network," Evans said.

Next Page: Guarding against guided 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