It is not uncommon for large organizations to have relationships with dozens of ASPs - we've worked with some clients that have hundreds. The services these entities provide range from internally consumed services like payroll and benefits management to externally consumed capabilities like credit verification and payment processing on web sites.
While the use of ASPs is proving beneficial at a business level - enabling innovative functionality and reducing time to market, integrating these ASPs into the network and processing environment raises obvious security concerns for organizations and their clients. Does the ASP safeguard your confidential data to the same degree that you do? How would you know? Does the connection to the ASP represent an open back door into your network? Can another customer of that same ASP get at your confidential data? These are obvious questions, yet most organizations can't answer them. If you can't, you don't have an effective ASP security program in place.
Below, we touch on some major ASP security problems and offer a practical approach for structuring an effective ASP security program, one grounded on business risk assessment.
Responsibility for ASP security is not assigned in many organizations. Often particular business units develop a relationship with an ASP and the resulting infrastructure lies outside of the control of the internal security group.
There is no formal process defining how to assess the risks involved in exporting or outsourcing particular functions to an ASP - disclosure of data? Integrity of operations? Reputational risk?
There is no process in place for reviewing the security of an ASP's operations, including the policies, practices, skill level and the impact of the ASP's other relationships on the security of your operations.
There is no agreed upon way to determine how much security is necessary for any particular ASP.
If you don't review the security of ASPs as a matter of course, when you do, you may find that your confidential information is stored in an insecure way at the ASP or that the ASP does not effectively segregate its customers' data; another client may be able to access your data. It is not uncommon to find that the ASP has inadequate logging, auditing and intrusion detection. Simply, you shouldn't assume that the ASP's security standards are the same as yours.
There is no policy controlling the sensitivity of data passed to ASPs or review of data to ensure that only required data is passed.
There is no defined set of approved connection models for ASPs (protocols, authentication, and authorization) so each ASP interaction is designed and implemented in an ad hoc fashion. This leads to a proliferation of unique, often insecure solutions.
Many ASPs have inadequate disaster recovery and incident response plans.
A Proven Approach
There are many measures that you will need to take to properly secure your ASP relationships. Those measures will be driven almost entirely by the nature of the business relationship between your organization and the ASP. For example, you would apply a different security policy to an ASP that has custody of your clients' confidential financial data than to an ASP that provides an online read-only quote service.
Many organizations have well-developed risk assessment processes. They assess the business risk of a particular application, determine appropriate security policies to apply, assess compliance, and remedy deficiencies or institute compensating controls. For some reason, many organizations do not apply this proven approach to their ASPs. They should.
To determine the type, design and strength of security mechanisms that are appropriate for any given ASP, you should ask the following questions:
- How critical is this function to your day-to-day business? Is it a high-risk application?
- If the ASP was compromised and your data disclosed, would your reputation be damaged?
- How does the ASP connection model work? Will the ASP be accessing your critical internal systems to "pull" the data it needs or will you be "pushing" data to it?
- From your customer's perspective, is the ASP visible or invisible?
Going further, you may want to relate your sense of the ASP risk to specific required actions. We show a brief example for a high-risk application below. Corresponding criteria and requirements would apply to medium and low risk applications.
Risk Categories and Security Requirements
ASPs serve different functions and consequently, the data exchange models between you and the ASP and the data protection policies and practices must satisfy differing security requirements. For simplicity, consider three security categories corresponding to high, medium and low security requirements. The risk category for an ASP is a combination of the sensitivity of the data that the ASP handles and the damage that compromise of the ASP would do to your reputation.
The resulting category defines the overall security requirements for the ASP. The requirements drive the processes for evaluating the security policies and practices of the ASP as well as the mechanisms that should be used to protect the data exchanged.
The high risk category includes any ASP that has one of the following characteristics:
- It handles sensitive or proprietary data and its service appears to be offered directly by you.
- It would tarnish your reputation if compromised.
- It has network connections that allow it to gain access to your internal infrastructure and customer data.
A high risk ASP should undergo the following reviews:
- A review of the necessity of sensitive data in the transfer (many organizations pass more information to the ASP than it actually needs).
- A high-level analysis of the data exchange protocol.
- An assessment of the trust relationships involved in the exchange (especially third parties that play a part in the exchange).
Data storage and management
- A review of the ASP's policies and practices related to storage (how it maintains and cares for your data), segregation of partner data, authentication, access control, administration, perimeter defenses, intrusion detection and response. Don't assume that the ASP has the same security policies and practices that you do.
- A review of the quality and quantity of staff dealing with your data and services.
Periodic penetration analysis (at least annually) of the ASP's Internet presence.
- A source code review of security sensitive components.
Data exchange requirements
- All connections must be mutually authenticated, identifying the ASP and you as the principals that are exchanging data.
- All third-party connection models must be reviewed for their impact on the security and integrity of your interactions (e.g., does a weakly secured connection to another party put your data at risk?).
- All session authentication information identifying users of the service must be integrity protected and authenticated.
- All sensitive data must be encrypted as it traverses any medium that may be viewed by a third party.
Business continuity requirements
- A review of disaster recovery and business continuity plans.
- A review of the plan for coordinating security practices and incident response.
As you can see from this high-risk example, when you negotiate with an ASP to use its services, it is critical to reserve certain rights in the contract. These include the right to conduct regular, thorough security reviews, the right to perform periodic penetrations testing, and the right to review security critical code.
Like most organizations, you will likely find that you have some homework to do before you can begin to straighten out your ASP problems. Internally, there are a number of processes you'll need to go through. You should agree on a limited set of secure methods for interacting with ASPs (protocols, authentication approaches, and authorization models that you'll use).
Establish administrative guidelines - what type of system administration access will you allow and under what circumstances? Review the sensitivity of all data being exported to outside parties - can it be sterilized? Often, the data that is passed to ASPs leaks information about how your internal plant is configured (for example, it may be unwise to pass an ASP your internal account IDs or expose the internal keys to your database). Finally, establish a review requirement and process.
For organizations that use many ASPs, building a specialized connection to each one itself creates a security problem; everything is a special case so there is no stable baseline by which to measure the security of the ASP connections. How should you connect to the ASP while simultaneously maintaining your level of security and without subjecting your user community to unnecessary layers of logons?
The answer lies in developing an ASP architecture that provides a handful of well-designed connection models. The various models cover the spectrum of technical requirements, ranging from customer pushing data to the ASP, to the ASP having access to the customer's systems to enable it to pull data itself. Naturally, the types of security controls that are integrated into each connection model correspond to the degree of risk associated with each application and model.
The single biggest problem with ASP security is that it has been neglected. Too many organizations have simply ignored the problem and are now in a deep hole as the number of ASPs they use has exploded. The answer lies in applying the same type of risk assessment and security review process to ASPs as is typical in most companies for internal applications. Further, reducing complexity is crucial. Developing a small number of secure ASP connection models and using them consistently will provide the foundation for a stable, secure, and monitor-able IT environment with ASPs integrated throughout.
Jonathan Gossels is president and Richard Mackey is a principal with SystemExperts Corporation (www.systemexperts.com).