Today more than ever, preventing data security breaches is a toppriority for any business. Recovering from a breach has ameasurable impact on the bottom line. A 2006 study by the PonemonInstitute reported it cost companies $182 for each lost customerrecord in direct costs, lost productivity, and lost customeropportunity. But perhaps even greater is the damage to a company'sreputation. In a survey of consumers, Ponemon found 60 percentterminated or considered terminating business with companies thatnotified them of mishandling their private information.

Of course, information security is nothing new to insurers, butin the past, security has focused on ways to keep people away frominformation and to control access to and connections betweenenterprise applications. Today, that model has been turned on itshead.

"In the good old days, you could batten down the hatches, notallow any communication into your corporate applications, and bereasonably secure people wouldn't hack into your [core] systems.With the explosion of Web services and service-orientedarchitecture, corporate barriers and firewalls are like Swisscheese as the business finds legitimate reasons to exposeapplications to improve efficiency and do things it couldn't dowith tight integration," says Mounil Patel, vice president andresearch director at Aberdeen Group.

In other words, while the good news from a business standpointis Web services has opened access to both data and applications,the bad news from an information security standpoint is Webservices has opened access to both data and applications. SOAPmessages can be hacked or captured by a "man in the middle" and beread or modified. Falsified messages that appear legitimate couldbe sent to a service in order to invoke a function or obtain data.Particularly in insurance, where insurers have realized the valueof Web services to expose mainframe functionality, serviceinterfaces may make previously locked-down legacy systemsvulnerable to one-off attacks on nonmainframe applications that aretrusted by mainframe services.

If you think these risks sound familiar, you're correct. "Tosome degree, the issues related to Web services are no differentthan those associated with the Web or any other distributedcommunication technology," asserts Anne Thomas Manes, vicepresident and research director at Burton Group consultancy.

However, there is a critical difference. Simply providingWeb-based transaction capabilities generally constrains access tocontrolled points of entry, such as a consumer or agent connectingpersonally via a carrier's Web portal. Web services, however, isdesigned to support flexible application-based access where nohuman user needs to be involved.

"You have to keep track of where the request [to invoke a Webservice] came from," Manes says, illustrating this with an exampleof a change request to an insurance policy. "If an agentauthenticates and connects through a browser, the application thatconnects to that browser will know who that person is. But if it'sanother application connecting via a Web service invocation, youdon't necessarily have a user attached to the request, nor do younecessarily know if the invoking application was actually theoriginal source of the request."

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

For instance, Allied Solutions originally had deployed an onlinequotation system, called Internet QuikQuote (iQQ), five years agovia its Web portal. Allied Solutions is owned by Securian FinancialGroup and acts as the sales arm of the company.

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

In 2006, Allied created a Web service API to allow the iQQsystem to connect to a lender's loan origination system (LOS)."This gave us a delivery system for loan officers that wouldintegrate directly with systems they already were using," saysDebbie Price, Allied's director of retail products support. Allieddetermined, since the LOS was a trusted source, its authenticationmeasures and existing Web-message transport security wereadequate.

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

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

Encryption features are particularly important, not just as amatter of good practice in Web services security but also becauseapplying and maintaining encryption is a defense against thenotification requirements of breach disclosure laws. Allied plansto strengthen security further by encrypting the user name andpassword in a packet separate from the message body.

Insurers that deploy Web services externally seriously shouldconsider using hardware-based XML gateways, which typically sitinside the "demilitarized zone," and related software-based Webservices management (WSM) systems behind the firewall. Gateways andWSM systems are useful in performing specific Web services securitytasks that firewalls themselves may not.

"You can use your existing network firewall, but it won't giveyou specialized Web services security. Web application firewallscan parse the WSDL file but don't do the in-depth level of Webservices policy enforcement that XML security gateways do," saysDiana Kelley, vice president and service director at Burton Group.XML gateways can manage message-level security information andenforce security policies for services. They also can perform othertasks such as validating message formats, transforming externalACORD messages into internal specifications and vice versa, androuting messages.

In addition, gateways can perform Web services securityenforcement tasks faster. "One of the most annoying things aboutXML messaging, particularly if you are doing encryption, is itconsumes a huge amount of processing power," Manes says.

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

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

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

Therefore, the "weakest link" principle of security comes intoplay, putting formerly locked-down systems at risk if an insecureservice that is trusted by those systems is part of a compositeapplication. But even if an insurer is using Web services solelyfor point-to-point application integration where security isstraightforward, it should build security with future needs inmind. After all, a motivating factor for building services andextending legacy applications as services today is to make themavailable to more users.

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

Looking to the future is something ICAT (InternationalCatastrophe Insurance) Managers considers in the ongoingdevelopment of its SOA. ICAT specializes in providing commercialcatastrophe insurance coverage to businesses located incatastrophe-exposed regions of the United States.

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

This control has an ancillary security benefit. "Rather thanhaving multiple applications sharing a database where it would bedifficult to control what an application would do with theunderlying data, Web services and the ESB give us a centralsecurity point where we can manage the security of connections toand from the single bus. It also offers a level of abstraction thatgives the appropriate level of access control to provide serviceswhen and to whom they are needed but not beyond," Scriberexplains.

He points to the company's claims administration system,Guidewire Claim-Center, as an example of an application that usesWeb services extensively, both for inbound and outbound internaldata transfer. For instance, to populate policy data on a newclaim, ClaimCenter makes an outbound SOAP call to the policyadministration system to search for the policy being claimedagainst.

Even though these calls are made between systems behind thefirewall, Scriber says, it was important the Guidewire systemsupport 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 commonprotocol, such as SOAP, it is easier to provide consistentsecurity," he says. It also helps ensure when services are extendedto external users appropriate security standards are beingfollowed.

In its overall risk management, ICAT Managers additionally looksat ways in which someone could gain unauthorized access to aservice. "If you have an internal Web service and that serviceprovides access to your policy administration database, you need tomake sure you control who has access to that service just as youwould the database," says Scriber. That may mean applying measuressuch as strengthened authentication or security tokens and creatingnew application-level security to ensure someone won't create aone-off client to execute a service inappropriately.

ICAT Managers' cautious approach when it comes to internalservices is good practice, indicates Kelvin Lawrence, who isco-chair of the Web Services- Secure Exchange Committee atstandards body OASIS and CTO of Emerging Internet SoftwareStandards at IBM. "When you are exposing applications behind thefirewall, you always should question whether there are ways someonecould get into the application that weren't documented. Mostcompanies I've dealt with go just as far [with Web servicesecurity] inside the corporation as they do outside thecorporation," he says.

Although HTTPs, SSL, and other transport-layer security measuresare the most prevalent approaches to securing Web services, theyshare a limitation.

"The basic problem is a lack of message-level security; beingable to protect the message so there is persistence of security,"explains Tony Nadalin, who serves on several OASIS securitycommittees and is chief security architect at IBM. "With transportsecurity, every time a message is received, the security breaksdown."

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

To address this problem and establish standards for securitypersistence, IBM, Microsoft, and VeriSign developed acommunications protocol that since has been codified as the WSSstandard by OASIS, the final version of which was released inFebruary 2006. The WSS protocols define a set of SOAP messageextensions that comprise a security header for the message andinclude details on the use of security tokens and securitycertificate formats. However, WSS is not designed to prescribe aspecific technology for Web services security or to provide acomplete security solution. Several related standards also arestill under development by OASIS, such as WS-Policy, WS-Trust,WS-Privacy, and WS-Secure Conversation.

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

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

WSS "won't be a big leap for them," asserts Andy Labrot, chieftechnology officer for Innovation Group, who has worked withinsurers on system integration and security projects for more than20 years. "As they look at models put out by OASIS, they can extendtheir existing practices into the WSS framework."

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

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

Fortunately, insurers have proven themselves to be adept riskmanagers with a successful track record of addressing informationsecurity challenges, regardless of their source.

"It's fair to say the existing security infrastructure ininsurance is quite good today," Labrot confirms. Insurers "haveproven 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 systemsintegrate with our system, and they are satisfied with the securityit has. We haven't had much pressure to change anything todate."

Even technology vendors haven't been jumping on the WSSbandwagon. "For the moment, the security mechanisms in place forWeb sites and e-mail traffic are proving to be sufficient for Webservice deployments," says James Pasley, chief technology officerfor Cape Clear Software. "These mechanisms are well understood andhave a proven track record for point-to-point or client/serverstyle 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 onepart of an insurer's comprehensive security process. WSS extensionsand transport-level security mechanisms need to be combined withtraditional Web and information security practices such as virusscanning, provisioning and identity/access management, and frauddetection.

Ultimately, the best solution to the security challenges createdby Web services is to understand the risks, assess the strengthsand limitations of a particular risk-management approach, and makean informed decision regarding a strategy to follow.