Because perimeter security will never be perfect, experts turn their attention to securing the corporate jewels – the applications.
Your organization understands security. It follows best practices, has the requisite firewalls, anti-virus and intrusion-detection systems in place along the perimeter, and only communicates with mobile users or business partners via secure VPNs.
And when end users enter the network via the VPN they are vetted by a separate security server to ensure their machines are properly configured with the appropriate firewall and anti-virus tools before they’re granted access to core applications.
The company even goes as far as deploying application-specific firewalls and intrusion-prevention systems (IPS) around the most critical application servers, watching for and blocking non-appropriate application calls and traffic. It’s what the pundits call “defense in depth,” and you’ve got it in spades.
But even though the company has probably spent thousands, maybe millions, of dollars on security infrastructure, chances are it will still get hit by the latest virus or worm.
“What’s wrong with this picture?” asks Paul Simmonds, director of global information security at London chemical conglomerate ICI and a co-founder of the Jericho Forum. “What we have is back to front, at the moment. We’re saying that since we can’t secure our applications, we need to put in firewalls and kludges all over the place to make what we have at least semi-secure, and even that’s not working. But why not just go back to first principles and get this secure from the outset, at the application level?”
An applications deployment nightmare
Experts agree that the security focus needs to shift. “For anybody who’s thinking about new hacking techniques, the soft target now isn’t the network or the operating system. It’s the applications,” says Thomas Longstaff, deputy director for technology at security organization CERT . Because no matter how much technology you put in place around applications, in order to use them, you have to open them to end users and other processes.
“It doesn’t make any sense to protect all this information if you can’t get to it,” Longstaff says. “You have to provide access to wherever the clients happen to be. And that means that you’re really relying on the proper configuration and security of not only every application server but also every end user that’s going to use the application.”
Complicating matters is that application vendors implement security measures differently such as authentication and authorization, encryption and so on.
“We’re still pretty much in the Wild West phase of applications security, where everybody who has a good idea goes off and does it their own way,” Longstaff says. “Very few vendors are trying to bring their applications together under a single framework for security.”
That makes it hard for end users to securely deploy and configure their business-critical applications. “When deploying new applications, users are faced with a long list of security check boxes,” Longstaff says. “And the onus is on them to figure out each application’s inherent security problems, how best to shore them up, and then how to make sure the best security configurations for one application don’t interfere or override the security configurations for another.”
That’s now the most daunting area, says Brian Young, vice president of IT at Creighton University in Omaha, Neb. “It’s like you have to be a NASA engineer to make the security pieces work for some applications,” he says. “In many cases, the only folks who know how to work it are the engineers in the company who built it. And that’s not user-friendly. It makes it really difficult to deploy.”
Longstaff says applications vendors will eventually have to rally around standardization, some kind of security middleware that will ensure that every application implements security in a standard way.
“When we have a better layer of middleware out there that the applications developers can begin to use, then this problem will get better,” he says. “We will have tighter application security, a more uniform interface and an easier end-user experience when adjusting the security parameters.”
But all that will take time, and while the industry waits, applications will continue to be soft targets.
Interim solutions
That doesn’t mean today’s organizations can’t keep their applications secure. Experts say the key is to deploy applications-based security strategically, with an eye to the future. Many organizations looking at applications security tend to focus on IP-based solutions such as application-specific firewalls or IPSs . Proponents of these tools tout the fact that they can be deployed around critical applications servers and then outfitted with policies to ensure that only acceptable types of traffic can access the application.
“Rather than identifying and blocking all the bad traffic, we take it from the other perspective and say what traffic should be allowed, what is acceptable to the application,” says Mike Paquette, vice president of marketing and product management at IPS vendor Top Layer Networks. Paquette says tools like his firm’s Attack Mitigator can shore up application defenses, especially in cases where the applications haven’t been configured properly for security.
Say you roll out a Microsoft Web server and enable WebDAV, a Web authoring tool that shouldn’t be turned on in a production environment. “It’s a mistake,” Paquette says, “but you can set up a policy within an IPS to watch every request that comes into that application, and if one contains a command specific to WebDAV, you can block it.” It’s an added layer of protection.
Such tools are helpful but don’t solve the right problem in the long run, some experts say. “You really need to move up the stack,” says Andreas Antonopoulos, senior vice president and founding partner at Nemertes Research. “Using a firewall or IPS that can understand TCP or HTTP isn’t really the right way to do it. You’re peeking up into the application from the network layer, but you’re still very much tied to the IP address, and you’re still very much grounded in the network.”
Such an IP-centric strategy becomes especially problematic when firms begin moving to the concept of the new data center , in which core applications servers are virtualized and applications are provisioned automatically and on demand. Using IP-based security tools in such a flexible environment leads to unnecessary complexity and can hamper the organization’s ability to do business.
“You end up tying your infrastructure down and making it less dynamic,” Antonopoulos says.
This is because such tools tend to associate specific servers at specific IP addresses with specific functions, such as Web serving.
“And that totally negates the idea of any automated provisioning system,” he says. “In that scenario, you have two choices: Either your security infrastructure becomes more flexible and adaptive, or you’re forced to set up a ton of proxies and redirections and things like that to compensate.”
Instead of using the IP address for a Web server, organizations should set up things like DNS to resolve the IP addresses dynamically as they move applications on the fly, he says. “But that’s terribly kludgy,” he says. “For one thing, you’ve introduced a security risk so that if someone rewrites that DNS entry, they can hijack your Web server. And secondly, you’ve added another layer of redirection, which is a nightmare.”
The best approach, Antonopoulos says, is identity management -based security. “With identity management, you ignore the network completely,” he says. “So instead of thinking of the finance department as five IP addresses, it becomes five servers or users. It’s all policy-based, with application domains and organizational domains within the company that are completely disassociated from the underlying network.”
He also says emerging protocols, such as the Security Assertion Markup Language (SAML ), which lets Web services applications exchange authentication information at the middleware layer, are a step in the right direction.
“That stuff is available now, but it’s only happening among the vendors who see it from the application perspective,” he says, adding that the vendors to watch are in the identity-management and Web services realms. “If they support SAML today, they get it.”
Proactive steps
In the end, the best defense is always a good offense. Rather than complacently accepting unsecure applications, experts urge companies to demand better application-level security from the vendors.
Creighton’s Young says he avoids security configuration and interoperability problems by making key stipulations in applications contracts.
“Before we sign a contract to buy an application, I add in clauses for service-level agreements and assurances that the applications’ security levels are both easy to configure and as user-friendly as they were said to be,” Young says. “And if there are conflicting issues between applications, I say it’s their problem and they have to bring about a resolution. We wrap all that into the contract, and it lets us turn the tables on the vendors and make them accountable.”
Similarly, it’s important to demand that applications vendors support secure protocols. ICI’s Simmonds says his business units are continuously pressuring him to make it easier to run applications over the Internet, for flexibility and cost. “But the Internet fundamentally is insecure,” he says. “And you’d be surprised, but a lot of vendors don’t seem to realize that. They still design new applications that use Telnet and FTP.”
One ICI business refused to accept FTP as the default standard in an ERP application. “We told our ERP vendor we were required to use AS2 to communicate with our business partners and asked them how to go about it,” Simmonds says. Little did ICI know, but the vendor already had an AS2 plug-in module available. “We bought the module, plugged it in and a week later, we were up and running.”
“This stuff is possible, and it does exist,” he says. “It’s just that it’s a secret and the default – the accepted way that they tell you to do it – is to use FTP, which is wrong.”
Simmonds says users should demand that application-level security work within your company as well as across companies, customers and business partners.
“Today, Microsoft will say if you buy our latest Office suite and XP, you can do secure digital encryption and management on all your documents,” Simmonds says. “But if you need to do business with a partner on Unix or running an earlier release of Office, it won’t work. Either you don’t do it, or you have to decrypt it when it goes outside your business. That’s not acceptable.”
The key, he says, is to spend less time evaluating and managing interim solutions and more time pushing vendors to shore up applications.
“The danger is that we’re so caught up in all of these wonderful initiatives and the latest black box that we lose sight of the big picture,” he says. “You have to put in these things now because your business still needs to run. But what you need to do is save 15% to 20% of your time to step back and realign your resources to where they’ll do the most good – on the applications end.”
In the rosiest scenario, vendors eventually will produce applications that can run securely over the Internet, without the need for savvy customers implementing the appropriate security via firewalls, VPNs and other devices ad nauseum.
But if that scenario is to approach reality, organizations need to start prodding vendors now. “You have to remember that anything you are getting on the market in two year’s time is in the R&D lab today. So we need to influence that now,” Simmonds says.
Cummings is a freelancer in North Andover, Mass. She can be reached at jocummings@comcast.net.
