News Stay informed about the latest enterprise technology news and product updates.

Applying security protocols to business

This week the Liberty Alliance announced the availability of its version 1.0 specifications for open federated network identity, and Sun Microsystems in a carefully choreographed launch delivered its platform supporting the specification. This is a significant step towards solving a crucial part of the web services security puzzle.

Market Analysis

Applying security protocols to business
There are several important initiatives in process that are working to deliver standards and open protocols that establish a secure environment for Web service execution. Regular readers of this newswire will be familiar with WS-Security, SAML and the Liberty Alliance, addressing specific aspects of a security architecture that hopefully will provide a framework for a consistent, collaborative solution. This week the Liberty Alliance announced the availability of its version 1.0 specifications for open federated network identity, and Sun Microsystems in a carefully choreographed launch delivered its platform supporting the specification. This is a significant step towards solving a crucial part of the Web services security puzzle.

But we need to sound a note of caution that the protocols, together with the tools the vendors will deliver, are not a complete solution in themselves. If you listen to most industry pundits right now, you would conclude that Web services are not being widely adopted because security concerns are predominant. More to the point, that the security protocols and associated tools will be the answer to the metaphorical maiden's prayer and resolve all the concerns with the wave of a magic wand. Well excuse us for being blunt - what a load of rubbish.

Of course security is a critical issue, but standards, protocols and tools are just that - tools. But tools need to be used in an appropriate and practical process, and the real challenge for Web services security is understanding how current practices need to evolve and adapt to respond to new types of threats. The security protocols represent a technical infrastructure that allow us to have a common approach to security functions such as token passing, authentication, managing security context and so on. They allow you to have some degrees of certainty about who is using, and how the application is being used. The application architecture and business design must then use that infrastructure to establish reasonable defensive mechanisms, and these will generally be application specific. The reason that there's so much fuss about security and Web services is obvious, we are exposing core business transactions outside the firewall, and we are all rightly paranoid about minimizing risk. So you have to start off by analyzing the potential threats and your response to them. So how are Web services different?

Web services impacts on security
Web services affect security in (at least) three key ways.

  1. First, by making computer to computer automation the de facto method of business transaction, there is great potential for finding and exploiting loopholes before they are closed. Example the Kodak case which found itself obliged to fulfill a large number of online customer orders for digital cameras at the wrong price, because (we assume) an administrative error caused an incorrect price which was massively exploited in a very short period of time before the company realized its mistake.

    The key point here is the current focus of security tools and protocols would NOT have stopped this. All the users had valid ids, their credit cards were authorized, and there was no reason to suspect any of the users. But this was an attack on Kodak, coordinated via newsgroups that alerted thousands of people to Kodak's error. Exploiting their automated e-Commerce system, users quickly placed valid orders that were authorized, and accepted.

    So when processes are automated, business processes can fail for unforeseen reasons that automation actually exacerbates. Web services take the level of automation much further, and consequently the potential risk.

  2. Separating service provision and consumption and making them platform independent requires a substantially new security infrastructure that is not based on physical boundaries such as firewalls. The fortress approach is still essential, but must be progressively supplemented by security devices that emulate immune systems. However strong your fortress walls are, they will get breached at some time. Then how do you deal with the intruder that is inside the fortress walls and any consequent impacts? And how do you not just identify the incursion, but limit adverse impacts and deal with it, automatically?

    With Web services, consumers and providers need to be treated asymmetrically, the provider needs to identify users - the consumer needs to identify providers and each party to the exchange needs to operate on highly defensive principles. And as Web services consumers and providers are implemented as automated exchanges between computers the principles of defensive components is highly relevant. A technical viewpoint might be that providing consumers are authorized, the service may be provided. But the Kodak case suggests otherwise. In fact last year the world learned the hard way that individuals with intent to do harm to a system are usually in possession of valid authorization. This is not to say that all perpetrators are intent on dramatic actions, and the recent advert from Computer Associates makes this clear by alerting us to be on guard for "Rose in Accounts" suggesting that a lowly administrator or bookkeeper, can do just as much damage to an enterprise as a terrorist.

    In this litigious age, we also need to be acutely aware of corporate liability. Does a consumer have the authority to enter into a specific transaction? Are there complementary business transactions in place that take authentication beyond simple identification?

  3. Run time behavioral change driven by business rules allows dynamic change and potentially much more flexibility of business process. Collaborations with third party web services introduce elements that are not completely under the control of the primary transacting organization. Business and application design needs to comprehend the range of differentiated services available to/from customers and business partners, to ensure vulnerabilities are not exposed by accident. Vulnerabilities introduced by greater flexibility and more third party dependencies might include:
    - Customers get services to which they are not entitled, or for which they haven't paid the proper price.
    - Employees execute transactions without proper authority.
    - Third-party services providers charge excessive amounts for inadequate or unwanted services.
    - Valuable assets (including information) are degraded or stolen.
    - And many more . . .

The Web services security stack
In decomposing different aspects of achieving a secure Web services system, there are different levels of business abstraction that it is useful to pay attention to. The conventional definition of security needs to be widened beyond the technical issues to include business security concerns. It is inevitable that as we all go through a learning and evolutionary process with web services, that our attention should be focused on the technical infrastructure layers of the stack. However the danger for everyone is that we focus on the mechanics of security without looking at the business problem.

To help address this issue and appropriately focus attention, we use the notion of a stack to convey that the higher levels of abstraction rely on the services provided by the lower levels, and that all the levels of the stack are important to integrity, even if the implementation as components combines some of them.

It is almost inevitable that at some stage there will be many high profile events where Web service based transactions provide access for fraudulent transactions. It is equally likely that the perpetrators will be fully authorized and gain access through the front door. Make sure your security plans encompass the technical AND the business layers.

CBDi Report - Component based security for Web services
by Richard Veryard and Aidan Ward

The ideas and concepts outlined in this article are examined in a very comprehensive manner in a major new report from CBDi. This report is available for online and immediate purchase from CBDi.

Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and Web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.

For More Information:

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.