X
Home & Office

Keys to the kingdom

From a security perspective, signing on with an ASP is much like marrying into a huge, extended royal family. Any or all of those people have potential access to your sensitive data, and possibly to your network, as well.
Written by David Raikow, Contributor
For better or worse, the bulk of the technology we use to secure our computers and networks rely upon isolation and a relatively simple, black-and-white notion of trust. While the security specialists constantly point out the deficiencies of this model, available evidence points to insiders as the source of the vast majority of significant security breaches. For the moment, it remains at the core of standard network defenses. Most businesses simply quarantine their infrastructure, depending on firewalls to keep outsiders out.

Enter the ASP and the rebirth of shared infrastructure. Companies rushing to capitalize on the benefits of distributing the costs of hosting and maintaining expensive apps rarely realize that they may be undermining their own security strategies.

As separate organizations use "trusted connections" like virtual private networks (VPN) and dedicated lines to link their networks to an ASP, they also link themselves to each other. And as they draw upon shared computing resources, they blur the line between trusted insiders and untrusted outsiders. Beyond their control, yet effectively inside their defensive perimeter, the ASP network introduces a very murky shade of gray into a customer’s black-and-white world.

Security problems are an open secret in the ASP world, according to Glenn McGonnigle, Internet Security Systems' VP of business development, and they may be an inevitable part of application outsourcing. "Increased security risks are inherent in the ASP model; sharing infrastructure is always going to introduce vulnerabilities ... this is a very serious problem, and one that the industry has yet to adequately address," he says.

From a security perspective, signing on with an ASP is much like marrying into a huge, extended royal family. A large number of people have access to any ASP’s network, often via trusted connections that bypass firewall protections. Any or all of those people have potential access to your sensitive data, and possibly to your network as well. Like studying up on family politics, it pays to get to know which members of the "ASP family" may be "black sheep."

The Corporate Spy: The most direct and obvious threats to an ASP’s customers are its other customers. These companies are likely to be one another’s partners, competitors, potential partners or competitors, or partners of competitors; in any case, they have ample reason to want access others' networks or data. The legitimate connections they use to access their outsourced apps can be easily converted to illegitimate use.

The Double Agent: An ASP’s employees are in an inherently threatening position. They have administrative access to your data. They have regular and often friendly dealings with people who badly want access to your data, namely, their other customers and potential customers. It is not difficult to imagine a scenario in which such a person might be motivated into attacking you or leaving you vulnerable to attack. Moreover, ASP employees are likely to be particularly susceptible to "social engineering" attacks, in which they are tricked into revealing sensitive information or otherwise violating security policies. Jon Callas, director of engineering at Counterpane Internet Security, asserts that social engineering attacks are more of a threat than most technical attacks. "How does the ASP prevent me from getting interesting information about one of my competitors? Can I call them up, claiming to be from X when I’m from Y, and thus get X’s data?" he asks.

The Traitor: Most security experts agree that any company’s primary security threat is its own employees. Your workers know your business better than anyone else does, and thus are best prepared to locate and make use of your valuable data. Ironically, outsourcing your applications may make it easier for your employees to gain unauthorized access to them. An ASP’s security may be less stringent than your own, or they may not adjust to changes in your company as quickly as you do. A "traitor" may be especially capable of executing social engineering attacks against an ASP.

The Opportunist: Even if an ASP’s customers and employees are entirely trustworthy, others with access to their networks may not be. Any of these businesses may have trusted network connections to partners, telecommuting employees or other ASPs. Even worse, an attacker may have breached their security by another channel (perhaps through one of their trusted partners or employees); once inside one network, such an attacker is unlikely to hesitate when given an opportunity to infiltrate more. "In any ASP, the bad security practices of any one player can impact the others, and can very well impact the entire infrastructure," says McGonnigle.

The Gateway Stepping-Stone Attack: Many ASPs rely extensively on VPN technologies to provide cheap and secure connections with their customers. A VPN client app residing on a customer’s workstation encrypts network traffic bound for the ASP; a VPN gateway sitting just outside the ASP’s firewall decrypts this traffic and passes it through the firewall into the ASP network, where it is treated as if it originated locally. Return traffic is encrypted by the VPN gateway, sent back through the customer’s firewall to the client app, decrypted, and again treated as if it originated locally.

If an ASP has several customers direct their traffic to a shared VPN gateway, that gateway can be used as a "stepping stone" by a corporate spy or opportunist to launch an attack on a customer’s network. Using a trusted VPN connection, the attacker could take advantage of any vulnerability to assume control of the gateway machine. Once inside the gateway, the attacker could use any or all of its trusted connections with other customer networks to pass traffic through their firewalls undetected. The best ways to prevent this type of attack are either to not use VPNs or to have each ASP customer use a separate VPN gateway—the latter approach, however, negates some of the cost benefits of sharing infrastructure.

Because the VPN gateway sits on the edge of the ASP network, firewalls and network intrusion-detection systems (IDS) provide no protection against this kind of attack. That places the entire burden of defense on the security of the gateway’s operating system and VPN software, which often are neglected.

"Ideally, this shouldn’t be possible; traffic should only be allowed to pass through a properly configured gateway," notes Andy Groom, managing security architect at @Stake Security. "Gateways can be tricky to configure, though, and you can never count out software bugs."

The ASP Network Stepping-Stone Attack: In the absence of a shared VPN gateway, a corporate spy or opportunist can use the ASP network itself as a stepping stone into a customer’s network. Any trusted connection—whether a VPN, dedicated line or dial-up—will bypass perimeter firewalls and allow an attacker deep inside an ASP’s network. By compromising appropriate hosts within the ASP, the attacker can gain access to other trusted connections and "ride" them into other customer’s networks.

While perimeter firewalls have no effect on this type of attack, IDS and standard host and application security precautions can provide a measure of protection. Indeed, McGonnigle recommends that ASPs place IDS sensors directly behind the point of entry of any trusted connection as well as sporadically throughout the network. Internal firewalls and careful network segmentation also can limit the effect of this attack by helping to contain any breach, but they also restrict the ASP’s ability to distribute resources among its customers.

The ASP Application Attack: In many cases, an attacker may be less interested in a customer’s network than in its interactions with the ASP. A customer’s e-mail, research and development plans, client lists and financial data may all be stored on ASP servers, and can prove extremely valuable. A sophisticated attacker also may be able to manipulate an ASP customer to his advantage by altering the customer’s apps or data.

An attacker has a wide variety of tactical options available for pursuing this strategy. The application itself may be an easy target—few applications are thoroughly tested for security, particularly Web applications. Apps not originally designed or reengineered for ASP use are particularly likely to be vulnerable. Linked databases are often susceptible to attack, either through holes in the underlying software or poor architecture. A compromised Web server can give an attacker almost complete control over a Web-based application, while well-placed network sniffers can intercept traffic moving between client and server.

Counterpane’s Callas sees the application layer as a large, potential threat. "The application layer is where we’re probably going to see the bulk of attacks on ASPs. There are going to be a lot of these, and they’re going to hit the ASPs where they live. Even systems that are really good on network and host security tend to be wide open on the application later," he states.

The best defense against these attacks is careful examination of application source code and database architecture to weed out buffer overflows and other bugs an attacker may exploit. These procedures require substantial time and money, however, and often are bypassed. "Very few people do the kind of rigorous testing and code auditing necessary to really lock down an application," notes @Stake’s Groom. "It’s just not a priority for most."

Customers also can be kept on separate hosts, and their data and applications can be isolated behind internal firewalls. As mentioned previously, however, that limits the cost benefits of the ASP model—in this respect, customers are likely to get what they pay for. "Medium and large businesses will probably be hosted on their own servers anyway," says Feisal Mosleh, VP of marketing and product management

Editorial standards