Intermediary approach

Organizations today are continually seeking new ways to deliver applications and services efficiently and cost effectively. Many are already using approaches such as service-oriented architecture (SOA) implementations, SOAP based web services, and RESTful web services to provide access to on-premise and off-premise applications, while increasing numbers of these organizations are exploring techniques such as cloud computing, software as a service (SaaS), and smart grid as a delivery platform. These alternatives to traditional IT infrastructures can help reduce IT and application development costs, increase opportunities for collaboration, and drive business growth. At the same time, however, they can create new vulnerabilities, exposing access to applications and services beyond traditional organizational boundaries. Organizations therefore require more than traditional IT security to manage and protect access to these applications and services.

As a result of the transformation of IT and application environments, a large number of such web services (SOAP and REST) are being deployed to support business needs. These web services need to be protected not only from vulnerabilities from externalizing them, but also from the loss of intellectual capital and company specific information. Typically, this protection needs to be achieved without any modification to the service providers. One approach is to intercept these services before the request reaches the service provider to enforce security policy to protect the service. Components such as web services gateways, XML firewalls, web proxies, an enterprise service bus, and others are examples of

intermediaries

, where a service can be intercepted and an

appropriate security policy can be enforced. This approach is called the

intermediary approach

and architecturally, provides a good fit within SOA environments.

Let us review the need for an intermediary based approach through the following utility services example.

2.1.1 Customer example

A utility company with several million customers is in the process of deploying smart meters on their customers’ premises for more efficient and lower-cost operations, because the smart meters can send customer usage data directly to the utility company’s SOA-based IT environment, rather than requiring their employees to physically go out and read the meters. For scalability reasons, the meters send their data to concentrators, which in turn use web service interfaces to transmit this data. Those web services must be secured within the SOA environment.

The key to securing access to both on- and off-premise applications and services in this scenario is to build on the existing identity and access management infrastructure and use it to support a scalable and highly available solution for secure access to transformed resources. A centralized approach for security policy is a good way to maintain overall governance and control. Each additional service offering can then be implemented by simply adding more web services and protecting each service per business needs.

Most of the communication involved in this example has financial implications, so the implementation needs to be tamper resistant, meaning that it requires data integrity. In addition, the data flows over the public network, which is not protected against eavesdropping by nature. Therefore, confidentiality based on data encryption is also important. After the smart meters are in place, it becomes easy to increase the frequency of the read and write operations to enable more business operations, which requires high availability of the entire IT environment. Another important consideration might not be quite as obvious: The amount and nature of the data that gets created in a full-scale smart meter environment is likely to give away personal information about the customers, such as habitual behavior patterns, periods of absence, and cultural attitudes, if it is correlated intelligently. So there may be a need for policies governing the data life cycle, duration of storage, anonymization, and auditing.

2.1.2 Integrating policy at the intermediary level

Let us now take a look at the steps required to establish the intermediary level security policy enforcement approach. The most common implementations of this approach involve SOAP based or RESTful web services; we use SOAP while discussing the intermediary pattern.

Service discovery and service registry integration

A web service typically comes with a formalized, standards-based service description. This description presents a perfect starting point for adding policy management information. However, in application environments with a large number of services, this description might not scale well. To better use the benefits of a formal service description language, organizations typically deploy

service registries

that can assist with finding specific services. These registries can also store policies and metadata, making them available to govern the services.

A security policy management solution can use the registry and repository in two ways:

򐂰 It can use the service registry to discover a service and import not only its description but also any metadata that may be associated with the service. 򐂰 The policies authored by the security policy management solution can be

published back to the registry so that they can be used by other components within the IT environment, which includes web service clients for guidance as to how requests must be built, as well as policy enforcement entities for instructions about the policies they have to enforce.

Service security policy authoring

Industry standards such as

WS-SecurityPolicy

and

XACML

provide a

mechanism to define security policies for message protection, and context level authorization, respectively. These standards based policies can be associated with the web services that need to be protected.

There is, however, a gap that needs to be bridged between the business policies and their representation in IT terminology. At the current state of technology, this is not an automated task. The tools that are available today can assist, but not replace, the human assessment as to how a business requirement formulated in a non-technical language needs to be represented in a formal way. However, the fact that the formal policy languages are being used facilitates the process greatly. It helps in particular to develop a common understanding between the business owner and the enterprise architect. This is also where the need for policy life cycle management as an iterative process becomes important.

Policy configuration and distribution

The formal policies are still an abstraction to a certain extent. The process of converting them into a set of automatically enforceable rules is commonly referred to as

policy configuration

, which usually means binding an abstract policy element, such as a role, to a concrete object, such as a user ID or a group, in a specific registry that can be accessed and enforced at run time.

The defined policies and the associated configuration need to be distributed to various components within an organization so that they can then be enforced. Distribution targets include, but are not limited to, the service registries. In general, policy decision points need to have access to the policies, but whether these PDPs are distributed to them directly or by means of a service registry, is specific to the implementation. In either case, it is important to have a

mechanism in place that can assure that the current version of the policy gets used at any point in time.

Enforcement at the intermediary

Typically, all service requests pass through an intermediate entity (that cannot be bypassed) before reaching the service provider. There are different examples of such intermediaries; they may have been introduced for other purposes and now need to be enhanced for security policy enforcement (XML firewalls, an

enterprise service bus (ESB), business process management servers, or application containers), or they may have been introduced specifically to serve as a policy enforcement point.

Depending on the specific needs (available interception points, performance implications, persistent storage options, and so on) and also depending on the type of policy that needs to be enforced (message protection versus access control), different combinations of policy decision making and policy enforcement are possible. Both tasks can be co-located in a single entity, or they can be separate from each other, in which case the enforcer will have to reach out to the decision point.

Security of runtime information

Complex fine-grained entitlements often require additional data for the decision making process that go beyond the basic

who does what on which target

. This is where the effect of the policy configuration step sets in. Any additional resources, such as directory servers or databases whose contents can influence the authorization decision, must be secured with the same due diligence as the core application environment itself.

Message security, conversely, requires a strong authentication token such as a

Security Assertion Markup Language (SAML)token

and a reliable verification mechanism that must be in place.

Auditing

In this intermediary pattern, we have touched on a variety of good reasons for comprehensive auditing and logging. Let us recap some of them here.

򐂰 In an environment that consists of numerous on-premise and off-premise devices it is paramount to have an early indication of any irregularities. If we look at the example of smart meters, it is unlikely that such a device will ever send a false identification unless it has been tampered with, there is a stealthy attack, or there is a technical problem.

򐂰 We observed that policy authoring is an iterative process involving at least two different groups of people with different skills and backgrounds, which might result in errors when crafting the policies. Audit logs can serve as a means to identify erroneous policies and correct them.

򐂰 We also observed that the data gathered by the business services have the potential to be used for profiling. Audit logs can be used to identify that attempts to perform this action have actually taken place.

More information about the intermediary approach can be found in Chapter 5, “Intermediary level integration” on page 121.

In document IT Security Policy Management Usage Patterns Using IBM Tivoli Security Policy Manager (Page 61-65)