ASP Planning: A Checklist for Security

(1635 total words in this text)
(1020 Reads)  

While renting business application software through an application service provider (ASP) has many advantages over purchasing the software outright (no upfront licensing cost, little IT support burden, etc.), there are security concerns you must consider prior to entering into a purchase agreement.

Security concerns around hosted applications result from two inherent components of the ASP model:

1. The application is installed in a remote facility that's not owned, managed, or protected by the customer's employees.
2. All access to hosted applications occurs over the Internet.

This model is quite different from the standard IT model of installing packaged business applications in a secure data center within the corporate firewall and physically within the corporate campus. Typical concerns shared by IT and business decision makers include loss of critical data, theft of data by competitors, and loss of privacy of confidential information. ASPs are forced to build up a robust security infrastructure to respond to those customer concerns. This has led many hosted vendors to build up world-class security expertise and infrastructure. Many customers evaluating ASP vendors (especially smaller companies) may find that the security policies and security technology of the ASP vendor is more robust than what exists in the customer's IT department.

While security concerns are valid, the good news is you can proactively deal with them if the ASP you work with follows an emerging set of security best practices. If you want to wisely select the right ASP for your outsourcing needs, you must be proactive about evaluating the ASP's security standards. Consider -- and answer -- these questions before signing a contract with an ASP.

Define what's needed

How sensitive is the data?

Different business applications have different security requirements whether they're hosted internally by an IT department or externally through an ASP vendor. While a payroll system demands extremely high security standards to protect both corporate and employee confidentiality, some applications, such as outsourced travel reservations and news services, have much lower data security requirements.

Tip: Keep the scope of security due diligence commensurate with the needs for the business application you're outsourcing. Some of the sensitivity factors to consider are:
Who will be using the application?
How sensitive is the data involved in the application?
Would anyone care if an unauthorized employee saw the data?
Would anyone care if a competitor saw the data?

How do users get into the system?

User authentication is a basic component of any data security model. All users must be authenticated with a unique user name and password before getting into the ASP application. Ask the ASP how it administers user accounts. Look for a documented process for adding, modifying, and deleting user accounts.

While there are several options for managing user accounts, make sure the ASP vendor considers account information confidentiality. They should take active steps to minimize the number of employees involved in managing those accounts (or have authorization to view account data).

Application access must be granted to new employees and quickly disabled for departing employees. It's critical that the ASP encrypts all login and password data transmitted over the Internet. For user management, ASPs usually offer one of three different schemes:

1. User management as a service. Every time a user addition, deletion, or update occurs, an IT resource manually contacts the ASP either through a phone call or e-mail. Caution: This is the least desirable since the customer is at the mercy of the ASP's response time.

2. Customer-side user management tools. Some ASPs provide customer IT departments with user management applications so that access changes can be managed without the manual intervention of the ASP. Heads Up: While this is better than having to contact the ASP vendor each time a new login is needed, it still creates an administrative burden for the IT department.

3. Integrated authentication. Ideally, an ASP-delivered application should be able to authenticate users based on a corporate-standard directory service such as Windows NT Domains, an LDAP-compatible directory database, or Novell Directory Services. This can also be accomplished through an integrated authentication scheme whereby the ASP application uses LDAP or X.500 to piggyback on top of an internal authentication system. Every time a user attempts to login, the ASP application should query the corporate directory service over the Internet and check to see if the user is:
a. logged in to the corporate network; and
b. has access to the hosted application.

Best Bet: Using this scheme means IT administration resources aren't burdened with additional user management tasks and the customer is guaranteed immediate updates to user changes.

Is it safe for my data to travel over the Internet?

All communication to and from the ASP should be over encrypted lines of communication. The most popular method for delivering encrypted Web pages is Secure Sockets Layer (SSL). Check to see that the URL needed to access the hosted application begins with HTTPS and not HTTP. HTTPS indicates the use of SSL encryption.

Caution: If the ASP isn't using encryption, your data is susceptible to being intercepted by competitors or hackers. While data interception isn't likely, implementing encryption is simple enough that every ASP should warrant its use.

How do you prevent other customers from gaining access to my data?

Number One Rule: The ASP should isolate each customer's data. The "sum of all fears" for any ASP is to accidentally send one customer another customer's data. Ask the ASP how they keep different customers' data separated. There are two methods for client data isolation:

1. Physical separation. Each customer's data is placed on physically separate hardware. While this is the most secure technique, it's rarely used. Having to purchase new hardware for each new customer would cause infrastructure scalability issues.

2. Logical separation. While the data of multiple customers is shared on common physical hardware, the data is stored on separate logical databases within a shared physical server and application code handles the client data isolation. This method is a fairly common practice in the ASP industry. While there are no inherent security concerns with this approach, make sure the ASP can walk you through the logic of their client data isolation scheme.

Where is the application hosted?

Is the ASP provider running the hosted application from major co-location vendors such as Exodus, Qwest, or AboveNet? Or is the application running from a server hosted at the customer's site (such as underneath an engineer's cubicle)?

ASPs should use third-party co-location facilities, because this is the most secure way for serious ASPs to protect their customers' data. Co-location vendors are in the business of providing security and redundancy. If the ASP you're considering isn't using the services of a recognized co-location vendor, they're likely not doing enough to secure your data and provide high availability to your data.

Co-location facilities offer physical security such as restricted building access and locked cages, as well as general application uptime services that help ensure maximum availability. Availability services include guaranteed Internet bandwidth connections, backup generators, and fire suppression systems.

How can I integrate a hosted application with my internal enterprise applications?

One of the unique challenges of deploying hosted applications is integrating the hosted application with other enterprise applications. For example, if you're purchasing a hosted sales force automation system, and you have an internally deployed customer service application, you probably want those applications to have some level of integration so you can have a unified view of customer data both pre- and post-sales.

Since ASP applications are accessed over the Internet and internal enterprise applications are installed at corporate data centers behind secure firewalls, there are networking challenges involved in integrating these systems. An emerging standard for integrating and sharing data with different applications over the Internet is XML. Using an XML integration scheme, data can be passed back and forth securely over the Internet between hosted and internal enterprise applications.

Recommendation: If you need to integrate your hosted application, make sure the ASP explains how you can share data over the Internet without exposing your hosted data or your internal enterprise applications to unnecessary security risks.

How safe is my data if your systems fail?

All ASP vendors should provide comprehensive data backup services. This ensures that your data is safe in the event that the ASP's application crashes or a catastrophic failure occurs at the data center facility. Make sure the ASP has a documented plan for backing up your application data according to a schedule that's in line with the periodicity of your data. The more frequently your data changes, the more frequently the ASP should be backing it up.

The backup plan should include regularly scheduled backup and offsite storage of backup tapes. Important: It's advisable that your ASP contract specifies you as the legal owner of the data. If a dispute arises, or the ASP goes out of business, you should be able to recover your data. You should also be able to demand content dumps at regular intervals for secondary backup purposes. Ask the vendor to provide details on the frequency and delivery methods for acquiring dumps of the application data and ensure that they're flexible enough to accommodate your needs.

Security success factors

The service level agreement (SLA) should provide details on the ASP's security policies and procedures. Important: Carefully review the SLA. The SLA contractually obliges the ASP vendor to uphold certain security, performance, and availability requirements. Make sure that the SLA includes the following items: Detailed documentation on physical and application security measures. Financial remedies for security breaches and unscheduled downtime. While downtime penalties are usually minor (proportional fee refunds), security breeches such as loss/theft of data should result in much more serious penalties such as a payment by the vendor to the customer of between one-to-three times the value of the contract.
Guaranteed uptime to match the uptime needs of your application.
Documented encryption standards.
Documented response time to mission critical bugs such as security issues, which should be detailed and described in number of hours/days.
Detailed backup recovery procedures.