Today more than ever, preventing data security breaches is a top priority for any business. Recovering from a breach has a measurable impact on the bottom line. A 2006 study by the Ponemon Institute reported it cost companies $182 for each lost customer record in direct costs, lost productivity, and lost customer opportunity. But perhaps even greater is the damage to a company's reputation. In a survey of consumers, Ponemon found 60 percent terminated or considered terminating business with companies that notified them of mishandling their private information.

Of course, information security is nothing new to insurers, but in the past, security has focused on ways to keep people away from information and to control access to and connections between enterprise applications. Today, that model has been turned on its head.

"In the good old days, you could batten down the hatches, not allow any communication into your corporate applications, and be reasonably secure people wouldn't hack into your [core] systems. With the explosion of Web services and service-oriented architecture, corporate barriers and firewalls are like Swiss cheese as the business finds legitimate reasons to expose applications to improve efficiency and do things it couldn't do with tight integration," says Mounil Patel, vice president and research director at Aberdeen Group.

In other words, while the good news from a business standpoint is Web services has opened access to both data and applications, the bad news from an information security standpoint is Web services has opened access to both data and applications. SOAP messages can be hacked or captured by a "man in the middle" and be read or modified. Falsified messages that appear legitimate could be sent to a service in order to invoke a function or obtain data. Particularly in insurance, where insurers have realized the value of Web services to expose mainframe functionality, service interfaces may make previously locked-down legacy systems vulnerable to one-off attacks on nonmainframe applications that are trusted by mainframe services.

If you think these risks sound familiar, you're correct. "To some degree, the issues related to Web services are no different than those associated with the Web or any other distributed communication technology," asserts Anne Thomas Manes, vice president and research director at Burton Group consultancy.

However, there is a critical difference. Simply providing Web-based transaction capabilities generally constrains access to controlled points of entry, such as a consumer or agent connecting personally via a carrier's Web portal. Web services, however, is designed to support flexible application-based access where no human user needs to be involved.

"You have to keep track of where the request [to invoke a Web service] came from," Manes says, illustrating this with an example of a change request to an insurance policy. "If an agent authenticates and connects through a browser, the application that connects to that browser will know who that person is. But if it's another application connecting via a Web service invocation, you don't necessarily have a user attached to the request, nor do you necessarily know if the invoking application was actually the original source of the request."

When it comes to using Web services to provide information to external users, insurers are aware of the need, at a minimum, to secure the integrity and confidentiality of the message in transport, just as they would do for any Web-based transaction. Whether additional security beyond the transport layer is needed depends upon a company's evaluation of risk.

For instance, Allied Solutions originally had deployed an online quotation system, called Internet QuikQuote (iQQ), five years ago via its Web portal. Allied Solutions is owned by Securian Financial Group and acts as the sales arm of the company.

"We provide iQQ to quote credit insurance, debt protection, guaranteed asset protection, and mechanical breakdown," notes Denise Lynch, senior vice president of Allied's retail products division.

In 2006, Allied created a Web service API to allow the iQQ system to connect to a lender's loan origination system (LOS). "This gave us a delivery system for loan officers that would integrate directly with systems they already were using," says Debbie Price, Allied's director of retail products support. Allied determined, since the LOS was a trusted source, its authentication measures and existing Web-message transport security were adequate.

"In many ways, the API is not much different from accessing a Web site, except instead of a human reading the API, it's another application," explains Ryan Hartstein, CTO, Virtual Interface, Inc., which developed the iQQ API for Allied. Since the service is not dynamically discoverable, Allied can control the integration point and security as it would portal-based access.

Allied secures the connection between an LOS and the quote application using Secure Sockets Layer (SSL) over HTTP. "The iQQ system of course uses quite a bit of application-level security, most of which is proprietary to Allied," adds Hartstein. "We also have done things that are standard in the industry, such as always storing passwords in hashed, encrypted forms, so they are not useful to anyone if the database would, in fact, be hacked."

Encryption features are particularly important, not just as a matter of good practice in Web services security but also because applying and maintaining encryption is a defense against the notification requirements of breach disclosure laws. Allied plans to strengthen security further by encrypting the user name and password in a packet separate from the message body.

Insurers that deploy Web services externally seriously should consider using hardware-based XML gateways, which typically sit inside the "demilitarized zone," and related software-based Web services management (WSM) systems behind the firewall. Gateways and WSM systems are useful in performing specific Web services security tasks that firewalls themselves may not.

"You can use your existing network firewall, but it won't give you specialized Web services security. Web application firewalls can parse the WSDL file but don't do the in-depth level of Web services policy enforcement that XML security gateways do," says Diana Kelley, vice president and service director at Burton Group. XML gateways can manage message-level security information and enforce security policies for services. They also can perform other tasks such as validating message formats, transforming external ACORD messages into internal specifications and vice versa, and routing messages.

In addition, gateways can perform Web services security enforcement tasks faster. "One of the most annoying things about XML messaging, particularly if you are doing encryption, is it consumes a huge amount of processing power," Manes says.

"XML gateways have accelerators in them that know exactly how to process XML quickly–as much as 40 times faster than if you were trying to do it on a general-purpose machine. If you're doing [digital] signature processing, which takes even more power, they can reduce your processing overhead by an order of magnitude. Particularly if you're dealing with large volumes, gateways are worthwhile," she affirms.

In insurance, the use of Web services within the walls of the organization dwarfs the deployment of services for external use. However, security still is a concern in internal use of Web services, particularly as the complexity of a company's SOA increases.

For instance, a composite application may consist of different services, written in various languages, deployed on different platforms, and invoked in various sequences. They may include "modern" services or wrapped legacy applications. Message traffic may travel directly between services, or it may be routed through an enterprise service bus (ESB).

Therefore, the "weakest link" principle of security comes into play, putting formerly locked-down systems at risk if an insecure service that is trusted by those systems is part of a composite application. But even if an insurer is using Web services solely for point-to-point application integration where security is straightforward, it should build security with future needs in mind. After all, a motivating factor for building services and extending legacy applications as services today is to make them available to more users.

"You never know when someone wants to extend an internal service to the outside world," Manes points out.

Looking to the future is something ICAT (International Catastrophe Insurance) Managers considers in the ongoing development of its SOA. ICAT specializes in providing commercial catastrophe insurance coverage to businesses located in catastrophe-exposed regions of the United States.

"We're trying to use Web services wherever possible," says Brian A. Scriber, chief architect and development manager at ICAT Managers. "Using Web Services Reliable Messaging [protocols] and having SOAP messages travel over an ESB rather than point to point get us to economies of scale we wouldn't have if we had to make 50 individual connections to an individual service. The ESB also helps us monitor and control message traffic."

This control has an ancillary security benefit. "Rather than having multiple applications sharing a database where it would be difficult to control what an application would do with the underlying data, Web services and the ESB give us a central security point where we can manage the security of connections to and from the single bus. It also offers a level of abstraction that gives the appropriate level of access control to provide services when and to whom they are needed but not beyond," Scriber explains.

He points to the company's claims administration system, Guidewire Claim-Center, as an example of an application that uses Web services extensively, both for inbound and outbound internal data transfer. For instance, to populate policy data on a new claim, ClaimCenter makes an outbound SOAP call to the policy administration system to search for the policy being claimed against.

Even though these calls are made between systems behind the firewall, Scriber says, it was important the Guidewire system support authentication via Web Services Security (WSS) extensions, based on the OASIS WSS framework (which will be discussed later). "To the extent all of the enterprise systems can share a common protocol, such as SOAP, it is easier to provide consistent security," he says. It also helps ensure when services are extended to external users appropriate security standards are being followed.

In its overall risk management, ICAT Managers additionally looks at ways in which someone could gain unauthorized access to a service. "If you have an internal Web service and that service provides access to your policy administration database, you need to make sure you control who has access to that service just as you would the database," says Scriber. That may mean applying measures such as strengthened authentication or security tokens and creating new application-level security to ensure someone won't create a one-off client to execute a service inappropriately.

ICAT Managers' cautious approach when it comes to internal services is good practice, indicates Kelvin Lawrence, who is co-chair of the Web Services- Secure Exchange Committee at standards body OASIS and CTO of Emerging Internet Software Standards at IBM. "When you are exposing applications behind the firewall, you always should question whether there are ways someone could get into the application that weren't documented. Most companies I've dealt with go just as far [with Web service security] inside the corporation as they do outside the corporation," he says.

Although HTTPs, SSL, and other transport-layer security measures are the most prevalent approaches to securing Web services, they share a limitation.

"The basic problem is a lack of message-level security; being able to protect the message so there is persistence of security," explains Tony Nadalin, who serves on several OASIS security committees and is chief security architect at IBM. "With transport security, every time a message is received, the security breaks down."

In other words, for a multihop transaction, transport-level security would have to be applied at each stop in the process. "How does the third or fourth application know the request came from the original authenticated user?" Manes illustrates.

To address this problem and establish standards for security persistence, IBM, Microsoft, and VeriSign developed a communications protocol that since has been codified as the WSS standard by OASIS, the final version of which was released in February 2006. The WSS protocols define a set of SOAP message extensions that comprise a security header for the message and include details on the use of security tokens and security certificate formats. However, WSS is not designed to prescribe a specific technology for Web services security or to provide a complete security solution. Several related standards also are still under development by OASIS, such as WS-Policy, WS-Trust, WS-Privacy, and WS-Secure Conversation.

WSS message extensions do provide insurers a framework for persistence of security. WSS headers remain with the SOAP message regardless of the number of intermediaries in the message path. These headers can be appended to at each "hop," as well, to provide message-life-cycle security and auditing. In addition, WSS provides fine-grained control. For example, while an insurer can use SSL to encrypt an entire message, WSS allows it to encrypt only selected portions of a message.

Also important for budget-conscious insurers, WSS was designed to allow companies to leverage their existing security technology investments in a platform- and language-neutral manner.

WSS "won't be a big leap for them," asserts Andy Labrot, chief technology officer for Innovation Group, who has worked with insurers on system integration and security projects for more than 20 years. "As they look at models put out by OASIS, they can extend their existing practices into the WSS framework."

Despite its benefit of persistent security, WSS has been slow to gain a foothold in insurance in favor of more traditional transport security technologies.

"For the near future, HTTPs, SSL, or secure FTP will prevail," predicts Craig Weber, senior analyst in the insurance practice at Celent. For insurers, the WSS protocol "may not even matter yet, because the direct proprietary connections still typically are how insurers are sending and receiving data," he claims.

Fortunately, insurers have proven themselves to be adept risk managers with a successful track record of addressing information security challenges, regardless of their source.

"It's fair to say the existing security infrastructure in insurance is quite good today," Labrot confirms. Insurers "have proven themselves to have a good security mindset."

Release of the WSS protocol "hasn't had a significant impact," Hartstein admits. "We have had several loan origination systems integrate with our system, and they are satisfied with the security it has. We haven't had much pressure to change anything to date."

Even technology vendors haven't been jumping on the WSS bandwagon. "For the moment, the security mechanisms in place for Web sites and e-mail traffic are proving to be sufficient for Web service deployments," says James Pasley, chief technology officer for Cape Clear Software. "These mechanisms are well understood and have a proven track record for point-to-point or client/server style interactions. As Web service deployments become more complex, the Web Service Security standards [will] come into play."

As its usage becomes more prevalent, WSS still will be just one part of an insurer's comprehensive security process. WSS extensions and transport-level security mechanisms need to be combined with traditional Web and information security practices such as virus scanning, provisioning and identity/access management, and fraud detection.

Ultimately, the best solution to the security challenges created by Web services is to understand the risks, assess the strengths and limitations of a particular risk-management approach, and make an informed decision regarding a strategy to follow.

Special Reports /

The Dark Side of Web Services

Related Stories

Recommended For You