Web Services Problems: Rogue Web Services

Web services problems are not often discussed – against the tide of excitement surrounding SOA and XML-based Web services. Amongst these problems, however, are “rogue” services: Web services that end up deployed on the network without IT being aware of it – without going through the Web services deployment process (silently using up corporate IT resources). Or IT is aware of the presence of the services … but these rogue services are not complying with essential policies and regulations. As such, these rogue services represent a not-so-clear but very present danger to the organization.

Compliance with Privacy and Disclosure Regulations at Risk

A rogue service is a service put into the network without any governance visibility. A rogue service adds significant risk to the viability of the SOA infrastructure:

• A rogue service could expose sensitive data, thereby putting the company at risk from regulations and legal issues. Often regulations such as HIPAA, Sarbanes-Oxley and privacy laws are explicitly runtime requirements.
• Rogue services use capacity without any accountability.
• Rogue services act under the radar of corporate compliance by circumventing the governance system and process.
• Rogue services decrease motivation for complying with governance policies because rogue services cannot be policed.

Automatic Application of Policies to Rogue Services

Actional Web services management software can provide firms with the ability to automatically initiate policy without tying policy to a particular service, eliminating the motivation to evade compliance. Once in place, the policy can be applied broadly, to all services across the network—even those that have not yet been implemented.

Rogue Service Discovery and Policy Application: Securing Critical Data and Applications

For example, say a rogue service is discovered. With Actional, the security policy of "customer data must be encrypted" can be immediately and automatically applied to the rogue service—thereby protecting the company and the customer. The power of this feature is that anyone deploying a service will automatically inherit a baseline governance framework to which the service must comply. Moreover, compliance will never be an afterthought, but will be present from development, through UAT, and on into production.

The Need for Runtime Governance: "A Disaster Waiting to Happen..."

Runtime, of course, is different from simple production. Developers developing a service are in a production situation even though they are in development because, from their perspective, their development activities are their product. And their development activities must be governed. The following example sets forth two situations at a financial institution that illustrates these issues, demonstrating the urgent requirement for runtime governance:

A developer spent an entire day grep-ing log files for IP addresses to see if anyone was using their development server. Now that the development cycle was complete, the development server was being rebuilt, and the developer knew people would complain when the server went away.

Another developer said to himself: "I imagine there are about three or four applications using my service ... I've given the WSDL to a few people, but I think they've shared it." This developer was surprised to find, in fact, that the Actional SOA governance software auto-discovered 34 different applications using this WSDL. And they were all using a development server that was a “cubicle-level” project. Worse, this “innocent” application had employee Social Security numbers embedded in a service that was now being used by 34 different processes. In other words, it was a disaster waiting to happen.

Enterprise-Wide Failures Virtually Inevitable: "Integration Too Easy..."

Even in a development environment, it became critical to manage governance in runtime so that capacity could be planned properly, ROI could be measured and integration catastrophes could be avoided. Not surprisingly, the reason Actional had been contacted by this company in the first place was that, in the words of the CIO: "integration had become too easy."

The Need for Management

The above scenario is increasingly typical. Companies' SOA initiatives can begin to gain so much momentum that enterprise-wide SOA failures become inevitable if the organizations don't take steps to obtain business process visibility by employing Web services management.

For More Information

Find out how to short-circuit Web services problems: download the free white paper, SOA Worst Practices.