In-Depth

Book Excerpt: Securing Web services

• By Bret Hartman, Donald J. Flinn, Konstantin Beznosov, Shirley Kawamoto
• January 31, 2003

The following article is excerpted from Chapter 12 of 'Mastering Web Services Security' by Bret Hartman, Donald Flinn, Konstantin Beznosov and Shirley Kawamoto. Used with the permission of the authors and John Wiley and Sons.

Web services may have great potential, but they also have a huge problem: they are too open. Companies need to limit access to their valuable resources, whether they are patient records, credit card numbers, or manufacturing designs. Enterprises want to collaborate and share information, but not at the expense of giving away their assets. Companies need to keep their guard up and stay suspicious of who they communicate with. They want to share enough information, but not too much.

Before Web services will be successful, security must be in place. Companies will never be willing to open up their internal corporate networks without the proper countermeasures. If companies don't, there are several 'bad things' that can happen:

* External attacks. E-business applications exchange information that is highly valuable -- this isn't about ordering a book from your browser at home. E-business is about companies exchanging thousands of patient records or trading stocks worth millions. For Internet-based Web services, attacks on these systems can be mounted from any desktop machine in the world using very simple software tools.

* Internal attacks. We've known for years that presumed trustworthy insider employees perform most security exploits. They might be setting a trap door so they can access corporate data after they leave the company. They might be committing fraud by creating fictitious customers to trade stocks or order manufactured goods.

What's so tough about security for Web services?
Security architects have known about the vulnerabilities we've described for a long time. What makes Web services different?

* Web services are designed to be open and interoperable. Since firewalls are set up to let HTTP traffic through, Web service requests via HTTP pass through firewalls with ease, leaving the internal network exposed.

* Web services are all about connecting chains of applications together. A Web service client communicates to one application, which proxies (delegates) the request to others downstream. Security technologies based on PKI are point-to-point, which work great for client-server but are completely inadequate for securing chains of applications. Web services require security technology that establishes trustworthy security associations in multitier environments.

* The different companies participating in Web service transactions all use different security products and technologies that don't interoperate. This situation leaves companies with three options: turn off security (too risky), agree on a single security technology (too expensive), or translate and bridge between technologies (not always easy, but the best choice -- more on this later).

EASI principles for Web services
Security could easily be the downfall of Web services. No company will be willing to deploy unsecured Web services, but an approach based on a single security product is inadequate. Where do you go from here?

To solve the problem of Web services security, enterprises need a solid application security architecture in place based on principles of Enterprise Application Security Integration (EASI). We recommend that you follow basic principles of EASI when you define your own Web services security architecture. We've learned these rules over the years as we applied EASI techniques to many large customers' problems in banking, telecommunications, and manufacturing.

Security architecture principles
We begin our list of EASI principles for Web services with some general guidelines for defining Web services security architectures:

Trust no one: Web services applications are implemented by multitier chains of requests, and consequently are much more complex than the client-server model. A client request bounces through many applications, so there are many points of vulnerability. As a result, corporate auditors have difficulty establishing end-to-end system trustworthiness because systems don't match the centralized TCB paradigm we described earlier.

A common simplistic model of trust is to have a security enforcement point at the perimeter firewall, and then assume that all Web services applications are equally trustworthy to protect all data. This approach is a dangerous assumption, since firewalls usually permit Web services HTTP traffic to pass through. If one component is compromised in this scenario, then the entire set of distributed components is vulnerable.

Transport security mechanisms, such as SSL or Internet Protocol Security (IPSEC), and message-oriented mechanisms such as XML Signature are inadequate by themselves in multitier environments because they cannot secure a chain of requests -- they only secure two end-points.

A better approach is to view collections of Web services components as mutually suspicious islands -- if one collection of components is compromised, then others will still be safe. In a mutually suspicious architecture, authentication isn't only for people. Each component that is a part of a request chain should be authenticated on its own.

To secure a multitier architecture, you need end-to-end security that supports passing security credentials across many different applications, and products that securely link users' credentials among systems to establish mutual trust. Defining a security architecture for distributed trust and controlled delegation is an advanced topic, and products that support these abilities are just beginning to enter the market. The best solution we've seen so far is to build Web services security on the combination of WS-Security and SAML, which allows security credentials to be passed and validated at each component in the multitier architecture.

Enable interoperability: You can't pick a single vendor product to solve Web service security because your corporate customers and partners will pick different ones. Your Web services architecture needs to have the ability to interoperate with other Web services even when they use incompatible security technologies.

We've seen that there are many excellent point security solutions, but we're quite confident that no single vendor product will ever satisfy all security requirements and dominate the marketplace. Because there are so many possible vendor security solutions out there, proprietary technologies can make interoperability extremely difficult.

The best way to enable interoperability is to use vendor-neutral standards. Although security standards for Web services are still in progress, they are well on their way. WS-Security and SAML are the key standards in this area. WS-Security provides a standard way to protect Web services message traffic, while SAML standardizes how credentials may be passed across multiple applications. These two complementary standards used together go a long way toward supporting Web services secure interoperability in a vendor-neutral way.

Modularize security: Web service security technology will continue to evolve, so it's important that you don't get roped into one vendor's product. All companies need to have the flexibility to mix and match security technologies without recoding their Web service applications.

Developers have the tendency to write their own security implementation within their application. We think this is a practice that should be avoided whenever possible. Developers cannot easily maintain the fragmented security embedded in each application, and their security tends to be fragile, requiring major rewrites when the security needs change. Look to enforce authentication, authorization, and cryptography at the lowest practical level in the architecture. The least desirable location is within the application, although some policies cannot be enforced anywhere else. By pushing security down to the lower layers of the architecture, you're more likely to produce robust common security mechanisms that can be shared across many applications.

The best approach is for applications to use standard APIs to support modular 'plug-and-play' of security components from different vendors. A standard security API defines a virtual security service that insulates applications from dependencies on any specific vendor product.

Security policy principles
We continue our list of EASI principles for Web services with some security policy guidelines for Web services security architectures:

Authentication: Balance cost against threat. The best authentication isn't for everyone. The most secure authentication, such as public-key certificates on smart cards, is probably too expensive to deploy and manage for many applications. If authentication techniques are too strong, people may just give up and not use the system. It's better to have authentication that people will use rather than building a secure boat anchor. Single sign-on (SSO) is an example of this principle; no one likes to login more than once.

Authorization: Application driven. Authorization policies aren't really to protect URLs or files: They protect business data that resides in those files. A lot of time and money is wasted blindly setting up security products that do little to protect important application data. To secure a system, don't lose sight of the fact that the most important thing to understand is the purpose of the business application. Once you understand what the business application is for and what security failures you are worried about, you can then figure out the best way to protect the data. (Application-driven authorization does not mean that the authorization policy should be implemented within the application.)

Accountability: Audit early, not often. Auditing is expensive in distributed systems, so for performance reasons, it's better to do it as little as possible. Unlike authorization, it's preferable to push the source of an audit event to the upper layers of the architecture near the application. Low-level auditing (e.g., at the OS level) is extremely difficult to analyze because it takes several low-level events to match to a single business transaction. Low-level auditing is fine for discovering an attack on your OS, but correlating low-level audit data across multiple audit logs to detect an application attack can be close to impossible. As a result, the most effective auditing is done as soon as an application recognizes that a potentially dangerous event has occurred.

Security Administration: Collections and hierarchies for scale. Web services applications are all about managing huge numbers: millions of users and resources; thousands of servers. The best way to deal with large numbers is to collect users and resources into groups and make those groups hierarchical. By defining collections, administrators can set policies on lots of users and resources at the same time and delegate security responsibilities across many administrators. Note that collections do not just contain people; services and data also should be grouped to handle scale.

For more on Mastering Web Services Security by Bret Hartman, Donald J. Flinn, Konstantin Beznosov and Shirley Kawamoto, please go to the John Wiley and Sons Web site at http://www.wiley.com/cda/product/0,,0471267163,00.html