Using an application service provider means your computer application is running on someone else’s server. Is the provider’s security up to snuff? Better know which questions to ask.
Instead of buying licences to run software on their own computers, a growing number of businesses are “renting” software hosted by application service providers (ASPs). That means the business is running on systems managed by a third party and accessed over a VPN or over the Internet. The upside: a generally accepted lower cost of ownership. Pay for what you need, when you need it, and let the ASP worry about pesky issues such as software upgrades. The downside? Potential security holes. Are the external servers and network links as secure as your own systems? If you are outsourcing an application that trucks in sensitive data — credit card numbers or consumer credit histories, say — that’s a most critical question.
According to Mike Arnavutian, head of security strategy at BT Global Services (an arm of the company formerly known as British Telecom), any ASP his company would consider needs to meet some basic security standards — secure firewalls, authentication systems, antivirus software and a secure architecture. Physical aspects of security, such as a robust and well-practised disaster plan, are also important, he adds. But it’s the policies underpinning those security issues that are the most important — and most overlooked — potential security loopholes, Arnavutian says.
“Most ASPs are weakest on the development and maintenance of security policies,” he says. But he doesn’t blame the ASPs so much as the companies that use them. “A lot of the time, companies are being sold what they ask for — and if they don’t ask about security policies, then they aren’t going to be sold them,” says Arnavutian. “If you don’t have a security policy, you have no rules and procedures by which you can shape the behaviour of people and control access to the network.”
Typical of the details that probing an ASP about its security policies should reveal, he says, are such things as employee background checks. “It’s not just asking, Are they carried out? but instead asking: What checks are carried out on the people who might have access to my data?” he says. BT, Arnavutian points out, must carry out positive security background investigations on all employees with access rights who work in data centres handling government projects. But the private sector doesn’t automatically benefit from such checks: “We don’t have the same level of vetting for all our data centres,” he notes.
These days, throughout the world of business, managers in functions as diverse as accounting, human resources and marketing are seeing ways to boost their departments’ productivity — and cut costs — by outsourcing some aspect of their operations to an ASP. But in the process, they’re opening the door to potential security breaches. Is data held at one or more third-party locations as secure as data held on your own systems? How secure is the link between the ASP and your own systems? And are the people looking after your data doing it as diligently as would your own people? Those broad, high-level questions are easily posed. The detailed questions underpinning them, though — together with the answers — are much trickier. And by not asking their ASPs for enough details, many companies are in danger of seriously flubbing Infosecurity 101.
ASP, and Ye Shall Receive a Project
In autumn 2001, Paul Saunders, a credit manager at The National Magazine Company in London, complained to his bosses about the level of control that the company was able to exercise over the management of employee expenses. The result: He got handed a project to figure out if the company could outsource expense management to a third party instead, via an ASP.
Saunders reviewed the market and quickly identified a potential solution. Parent company The Hearst Corporation of New York City — publisher of magazines such as Cosmopolitan, Country Living, House Beautiful and Good Housekeeping — already used an expense-management application from Concur Technologies. While Hearst licensed the application, Concur also offered the capability on an ASP basis.
Security, though, was a major concern. As a matter of policy, Saunders explains, Hearst generally tries to limit the extent of external access to its systems. For example, he says, the London subsidiary “has only one modem on the network — and the only people dialling in are programmers that we’ve dealt with for years.” The Concur application would not only involve British credit card company Barclays uploading details of employees’ charged expenses but also employees using the Internet to enter expense claims. The potential for abuse — and fraud — was obvious.
Recognising that crucial point, Saunders called in the experts from Hearst and National Magazine’s own IT departments. “I was asking basic questions about firewalls but wasn’t technically qualified to understand the answers that I was getting,” he recalls.
The success of the Concur implementation — begun in February 2002 and completed with a “go-live” in August 2002 — indicates that Concur passed such tests. “In order to access the expense management system from the Internet, you need to enter a company name code made up of 15 jumbled characters, as well as a user profile and a password which aren’t ‘saveable’, but which must be re-entered each time a user logs in to the system,” says Andrew Tunley, National Magazine’s group director of information services.
And from the security perspective, it was this issue of Internet access that had been the major concern, he explains: Concur’s facilities and own security practices came in for rather less scrutiny. “We didn’t go in and do an assessment,” says Tunley. “We were satisfied with their explanation of how secure their system was, which appeared to us to be as secure as you could make it.”
For its part, Concur has become accustomed to helping its potential customers appraise its security. But the nature of that help isn’t what might be imagined. “Often, customers don’t actually know what questions to ask us,” says Senior Director of Product Marketing Chris Juneau. “Their level of security awareness is enormously varied.” There’s a distinct difference between the larger and more sophisticated customers that opt to license Concur’s product, and the smaller organisations that choose to go the ASP route. The smaller ones, Juneau observes, “tend to ask simplistic questions and are often fairly quickly satisfied with the answers they get”.
Evidently proud of Concur’s multilevel security systems and dedicated ISO 17799 infosec team, which helps protect the expense management data of more than a thousand corporate customers, Juneau wryly observes that in the past year, no US-based customer of the company’s hosted applications has asked to visit and audit the third-party facility in which Concur’s servers sit in secure cages. And the London building owned and managed by Cable and Wireless in which the server hosting National Magazine’s application resides, he adds, have been visited just once. Indeed, just 10 percent of Concur’s British ASP customers even bother to visit the company’s Old Amersham European headquarters, where servers that host their applications are housed in a secure room to which only three staff members have access.
A massive blind spot — or not? Juneau points out that the host environments in question are SAS 70-certified (SAS 70 being a Statement of Auditing Standards issued by the American Institute of Certified Public Accountants), which precludes the possibility that the hosting is actually being carried out by Joe Sixpack in his garage. And ISO 17799 compliance adds even greater assurance. But by demonstrating such a relaxed attitude to critical security concerns, companies fail to appreciate — and test — what ought to be a major argument in favour of using ASPs: the opportunity that they offer to buttress a company’s security provisions cheaply and effectively. “It’s not just cost-effectiveness that should drive ASP use, it’s also security,” says Chad Cook, CTO of security software company Black Dragon Software, and a contributing author to the third and fourth editions of the book Maximum Security Pearson, 2002, $99.95 . “The ASP model is a one-stop shop for cost-effectiveness and security — provided that you und erstand it properly.” And especially for smaller organisations that lack the heavyweight security teams that bigger businesses can afford, Cook believes choosing an ASP makes sense.
But the trouble is, he adds, “many ASPs have a cookie-cutter approach to security.” Ask about security, in other words, and you’ll generally hear a standard recitation of firewalls, intrusion detection, antivirus and user-authentication capabilities.
“All these things are important, but they are only a part of the overall security picture,” says Greg Gianforte, CEO of RightNow Technologies, an ASP that hosts customer service and support applications for more than a thousand companies worldwide. “It’s the questions that don’t come up that can often matter more,” asserts Gianforte, who has actually created a list of precisely those questions (see “What to Ask an ASP”, page 23). Take, for example, the internal network inside a firewall. Especially with the new breed of ASPs offering a Net-native, multitenant architecture, it’s important to explore the mechanisms through which different customers’ data held on the same server is kept separate. “You can have literally hundreds of customers on the same box, and you need to be sure that your data isn’t going to show up on someone else’s Web site.”
Another often overlooked area of potential weakness, Gianforte believes, is when companies use applications that in effect link several ASPs together over supposedly secure SSL connections — a particularly likely vulnerability for global businesses with widely dispersed operations.
Send an e-mail or a Web inquiry to British Airways, says Gianforte, and there’s a fairly good chance that the application the agent uses to respond is hosted by RightNow Technologies. But not all the data the agent needs is stored at RightNow: Some may have come directly from the airline’s own servers, and some could have come from accounting applications running on another ASP. The bottom line: The more ASP-connected applications there are, the greater the potential for a weak link in the communications chain.
Finally, says Gianforte, blind spots over policy issues are common. “People typically don’t ask questions about policy issues — they seem more interested in technology,” he observes. But it’s the answers to those unasked policy questions that determine how effective that technology will be. How long are the logs retained for? Does anyone actually look at the logs? How many characters must a password have? How frequently must it be changed? Questions such as those are fundamental, he insists.
Even employee background checks aren’t as meaningful as might be imagined. They might provide potential customers with a “feel good” factor, certainly, but the fact remains that someone with a clean past isn’t necessarily guaranteed to have a clean future. As at least one anonymous ASP provider concedes, he’s not even certain exactly what a “social security check” comprises, even though his company proudly boasts to customers that every job applicant must pass it.
So while not protecting against every eventuality, one solution is to at least encrypt data so that malign individuals within an ASP — as well as outsiders able to gain access to the ASP data — cannot meaningfully interpret it. That way, data can be damaged or destroyed — but not stolen. Example: SwapDrive, an ASP offering remote backup services to 150,000 customers around the world, uses a security appliance from Decru for encryption. Says SwapDrive CEO David Steinberg of the encryption: “It’s so strong that even we can’t view the data.”
The Perplexing Problem of Proliferating Providers
Encryption, background checks, auditing, password policies — all good sensible measures, certainly, but do they collectively add up to a secure way of doing business with an ASP? As a way of doing business with just one ASP, maybe. But what worries Jonathan Gossels, president of network security consultancy SystemExperts, is that many companies now do business with multiple ASPs — hundreds in the case of the very largest US corporations.
“Over time you wind up with an enormous number of one-off security solutions, each of which is evolving dynamically as the nature of the business relationship between the two parties itself evolves,” he says. “How do you ensure that each of these relationships is operating securely — or was even designed to operate securely? You can’t. Things change.”
The solution, he believes, is to assess the security requirements of each ASP relationship at the outset and force it into one of a handful of standard approaches. An ASP handling event registration for an employee conference, for example, would be put under a less strict security regime than an ASP that handles sensitive customer information. “You’re driving the cost down while increasing the security — and reducing the time-to-market,” Gossels says.
Certainly, it’s an approach that makes sense to Jim Hyatt, principal at the Information Security and Contingency Services Group of The Vanguard Group. Vanguard has more than a hundred ASP relationships, he says, ranging from payroll processing to online training and external Web hosting. What’s more, it’s a number that’s set to grow. “It’s a very common situation,” says Hyatt. “When contemplating a new application or service, we find ourselves saying: Should we build it, or should we buy it? And most times, subject to proper security and controls, it’s cheaper to buy it.”
At which point, it falls to Hyatt’s 11-strong information security team to contact the ASP in question — usually by phone — and take them through a basic question-and-answer session. Is what is being proposed a core competence, or something special that you’d be doing for Vanguard? What is your architecture? What are your procedures for access control, data security and disaster recovery? How is data stored? How is it transmitted? The overarching question, according to Hyatt, is Are we engaging with someone who knows what they are doing and who has a good feel for security?
And assuming the answer is yes, what happens next depends on the nature of the IT outsourcing that is being proposed — and the risk that it entails. Around 50 percent of the time, if the risk is low, the ASP won’t even be visited. If all the ASP is doing is hosting publicly available Vanguard investment reports for investors to access over the Internet, for example, the consequences of a security breach are minor. But, cautions Hyatt, “if any Vanguard client data or [employee] data is going to interact with an entity outside Vanguard, then there’s no question that we are going to do a site visit”. The purpose of the visit is to examine the risks more incisively, and determine which of the handful of ASP security models should apply in this particular instance. After that, says Hyatt, “it’s the responsibility of someone from the IT organisation to be accountable for monitoring what’s going on”.
For Hyatt, the bottom line is that Vanguard may have more than a hundred ASP relationships — but only a handful of ways of handling those relationships from the security perspective, with the relevant contractual obligations of the ASP in each instance carefully defined. That, he says, “is a huge benefit”. Across corporate America, there are plenty of CSOs who would agree with that assessment. w
What to Ask an ASP
Ask potential application service providers the following questions, supplied by Greg Gianforte, CEO of ASP RightNow Technologies. There isn’t a single set of correct answers; the point is that a few simple yes and no questions won’t generally get you enough information to know whether the ASP offers an appropriate level of security for your particular application.
- Describe the physical security and disaster recovery and prevention features of the ASP’s data centre.
- Who (including data centre staff, other employees and vendors) has physical access to the host servers?
- Are industry-standard firewalls deployed? Where are they deployed? How does the ASP keep the software for the firewalls current? Is administrative access to firewalls and other perimeter devices allowed only through secure methods or direct serial port access?
- What protocols and ports are allowed to traverse the network and firewall?
- Does the ASP use intrusion detection systems (IDSs)? How long are IDS logs kept?
- Are formal incident-response procedures in place? Are they tested regularly?
- Does the ASP engage third-party security services providers to perform ongoing vulnerability assessments?
- Are ongoing vulnerability assessments performed against the systems?
- Are file permissions set on a need-to-access basis only?
- How are operating systems kept up to date? How does the ASP keep abreast of software vulnerabilities? What is the procedure for installing software updates?
- Are audit logs implemented on all systems that store or process critical information? Are root commands logged?
- What change management procedures are in place?
- What are the credentials of the systems administration staff?
- Has the systems administration staff undergone complete background and criminal checks?
- Are hosting staff onsite or on-call 24/7?
- Describe the user account and password policy.
- Are screen-blanking mechanisms deployed on all employee workstations?
- Do sessions automatically time out after an idle period?
- Are user accounts for contract personnel created with expiration dates? How are user accounts closed after termination?