IP contact center technology: eliminating the risks (Part X).

Companies Require Absolute Network Security

Over the last year we've looked at a diversity of pitfalls that companies need to address in order to effectively share IP contact center technology resources across locations; particularly when they need to deliver local control over technology-driven business processes to separate business units. (While all "multitenant" solutions generally enable different business units to share common technology resources, it is important to note that not all such solutions deliver comprehensive control to local managers.)

One of those pitfalls is the result of a traditional tension between properly addressing network security issues and the need to avoid sacrificing needed capabilities and benefits. Of course, companies always require absolute network security. That's the potential pitfall on which we'll be focusing this month.

At the root, security concerns for companies that want to share technology across locations can typically be broken down into three core groups: security issues between the different business units that must share common infrastructure; security issues within each of those business units; and security issues vis-a-vis network intruders.

Avoiding The Pitfalls

To determine whether a proposed solution can deliver on requisite levels of network security, companies need to ask their proposed vendors a diversity of architectural questions. Some of those are articulated below:

1. Will all business units be required to share a common domain?

Surprisingly, many multitenant IP contact center solutions will require all business units to share a common domain. This is generally an absolute showstopper for most commercial service providers and it will often be of serious concern to companies with autonomous divisions and sites that are concerned with maintaining their business unit privacy. This is a good example of security issues that can exist between different business units.

2. Does the proposed solution support proxies?

Any solution under consideration by a multisite organization should also support proxies; since many sites will likely rely on proxies as part of their overall approach to network security. (Proxy servers act as middlemen between internal networks and the public Internet. They improve Internet performance for enterprise users by caching often-accessed Web pages in memory to speed local page loads. They can also filter out-bound URL requests (i.e., restrict employee access to certain Web sites). Most relevant from a security perspective, a proxy server may also be configured as an HTTP or HTTPS "anonymous proxy" to hide the identities (IP addresses) of corporate users from the Web sites they visit. If a contact center solution uses the Web to communicate but doesn't offer proxy configurations, you may have to forego corporate security and filtering policies. The best approach is to select a solution that can address the differing needs of all corporate business units that the solution will have to serve.

3. What is the method by which user interfaces communicate with back-end systems?

This is an issue related to security against network intruders that also impacts security between tenants. The need for absolute network security has historically precluded many contact centers from sharing resources across locations at low cost by leveraging the public Internet, particularly when telecommuting agents are involved. The need for VPN access in such circumstances is often a showstopper for many companies both because of the large number of VPN connections required to support a distributed workforce at scale, and because of the security concerns inherent in providing access to a very large workforce of contact center agents that will typically suffer from high employee turnover. The best answer, of course, is to leverage newer technology that is secure by design, without the need for VPN controls. A key attribute of solutions that incorporate security by design is that they don't rely on unencrypted TCP/IP communications for their agent interfaces and back-end systems to communicate with one another.

There are two common firewall ports that let agents use browser-based applications using HTTP and HTTPS. Most Web site communications are in HTTP, but when you need a secure connection, a Web site can establish a secure 128-bit encrypted communication--that's HTTPS. Unfortunately, many contact center Web interfaces use unencrypted TCP/IP to transmit data instead of HTTPS. Of course, encrypted transmission is much more secure and less open to attack. You can even transmit XML over HTTPS (as in Web Services Architectures), so individual applications, clients and servers can communicate securely. You can increase security by sandwiching a hosted Web server or similar application between two firewalls in what's called a secure "DMZ" zone. Larger enterprises and telcos optimize this by putting application servers behind the DMZ and use the Web server in the DMZ to convert HTTPS communications from the Internet (where the agents are) into TCP/IP binary messages. This allows the use of common browsers and Web-based clients at the agent level with no fussing around with firewalls--since HTTP (port 80) and HTTPS (port 443) don't require special programming and permissions from IT security experts.

4. Does the solution require every business unit's historical customer data to be aggregated in a common database?

Many business units will have a security policy that prevents them from allowing their customer data to be housed outside of their own business unit networks. Of course, autonomous business units will have serious and potentially insurmountable objections to aggregating all of their historical customer data with the customer data of other business units in a common database. This is an issue because sharing technology resources across locations will generally require remotely-hosted applications to have access to each business unit's customer data in order to properly prioritize incoming customer requests for service in each business unit's queues. The problem is that such vital data are generally regarded as proprietary resources, and most autonomous business units will require the information to reside in their own data centers.

The answer is "multihost data polling." This lets multitenant solutions maintain call routing and agent data in a hosted, partitioned database while leveraging each business unit's customer priority rankings through firewalls--directly from each business unit being served. The data that drive customer priority routing rules need not be aggregated in a common database. (Of course, the multitenant solution will still require a fully partitioned database in order to segment tenant-specific technology configuration data used to drive routing rules and other technology-driven capabilities.)

This approach can also be used to trigger screen pops from secure, on-site databases for individual business units. To accomplish this, the shared solution can send "trigger information" through a business unit's firewall in order to make screen pops happen for agents sitting behind those firewalls based on local database tables.

Multihost data polling empowers business units to operate in a secure fashion behind their own firewalls but still enjoy the cost savings and efficiencies of shared infrastructure.

How It Works

Here's how it works: "multihost data polling" uses a "translation applet" that lives behind each business unit's firewall. It's called "multihost" because the corporate hosting provider can provision "translation applets" for each individual business unit or site. Based on incoming transactions (with ANI, customer I.D. numbers, tracking numbers, etc.), this "translation applet" can poll the local database(s) of a business unit for the required customer priority data. That same applet acts as a proxy to push the relevant data to local agent screens. In this fashion, secure data need never leave the enterprise. This approach enables autonomous business units to limit access to their customer data on a need-to-know basis. Each business unit has absolute control over its own applet's source code and which data the shared solution can poll from its database. (Example: the shared system doesn't need to know whether a priority-one caller has achieved his or her status because of job title, amount of money spent last year, familial relation or any other confidential factor.) The "translation applet" can deliver dynamically updated customer priority data to the multitenant system without providing access to the data inputs which define it. The context of the data remains confidential and the objection to running a shared solution can be overcome.

Multihost data polling also enables the shared multitenant solution to trigger local screen pop data from secure, local databases without running them through an external network.

Multihost data polling also allows agents working remotely to securely gain access to data from back-end databases through firewalls over the public Internet by leveraging HTTPS encryption--without compromising network security.

5. Can the shared solution deposit each business unit's own records behind their own firewalls?

Most business units won't want their transaction data (i.e., stored call recordings, faxes, e-mail and chat transcripts, etc.) to be aggregated with the records of other business units and stored outside of their own networks. "Secure multihost data streaming" solves this problem by allowing such customer data to be streamed through firewalls into each business unit's data center instead of (or in addition to) being stored at a centralized location. The method works exactly like "secure multihost data polling" described above, only in reverse. HTTPS content is streamed through the firewall and is transformed by the "translation applet" into its original native format(s).

Conclusion

Given the need to maximize network security, multisite organizations as well as those that employ telecommuters would do well to include the questions we've articulated when defining their RFP requirements.

For those who may have missed one or more of our first nine columns, including those on multitenancy, scalability or resiliency and disaster recovery, simply e-mail us and we'll be pleased to send you copies. We'd also love to hear your feedback and the issues you'd like to see dealt with in future columns.

Eli Borodow is the CEO of Telephony@Work, the leading provider of adaptive, multitenant IP contact center technology for contact centers and service providers. He can be reached via e-mail at [e-mail].

Kevin Hayden is the Director of Integrated Contact Center Solutions at TELUS Communications Inc., a tier-1 telecommunications carrier in Canada and the Canadian leader in hosted contact center services. He can be reached via e-mail at [e-mail].

A Special Editorial Series Sponsored by Telephony@Work