SOA Security: Simply a Matter of Policy

Policy-based Governance Helps Security Take Its Rightful Place as Just Another Part of Your SOA Infrastructure

Haven’t we all caught ourselves thinking of security as primarily a technical problem? Recall the days when we asked, “How do I implement a PKI to secure my Web applications?” For security folks, those were the days. However, there’s been a sea change in the industry since those simpler times.

Now we are answering different questions, ones that are actually far more complex, like: “How do I enable my business partners to access my services over the Internet, while adhering to our business agreements and complying with relevant regulations?” “How do I ensure that no one is modifying (even inadvertently) messages as they flow through intermediaries that are not under my direct control?” “How do I ensure that my internal administrators are not eavesdropping on corporate financial communications?” “How do I on-ramp my service consumers, business partners, and customers to use my services—and all at the same time?”

No point security solution is going to help you here.

Put simply, security has increasingly become an issue of corporate policy, as industry and government regulations around IT security have not only proliferated but also have been given “teeth” in the form of legal and monetary consequences.

But we’re getting ahead of ourselves. Let’s take a step back to have a brief look at security requirements. To date, three approaches have driven application security:

1. Security in the application. Until recently, there have been few alternatives to implementing security processing directly within application code. There was no clear separation between the functional code (that which processed and displayed data, for example) and the security code (that which verified identity, checked digital signatures, and encrypted data, for example).
2. Security in the application container. Another solution has been to delegate security processing to the application container running the service. Application containers provide platform-specific tools for delegating authentication, authorization, integrity, and confidentiality to the platform itself. This approach may work well in a unified environment. However, in a multiplatform, heterogeneous environment, the complexity of managing and synchronizing configurations for diverse containers can be daunting.
3. Security gateways. Yet another solution to this problem has been to deploy security gateways. A security gateway provides application awareness at the network edge and applies security processing on behalf of back-end services. This relieves developers of the burden of implementing security code and enables security administrators to focus on security configuration. Security gateways in the form of hardware appliances provide the added benefit of wire-speed XML transformations and accelerated cryptographic processing.

The general trend has been to move security out of the application and onto the network. As noted, this is essential for protecting against certain types of attacks, while at the same time gaining the benefits of hardware-based XML processing. The problem, then, becomes how to rationalize and manage the loosely coupled relationship between security-on-the-network and applications themselves.

Clearly we need a new approach. The solution to this problem lies with security policy.

Policy and Governance: Making Your Apps Work for the Business

We’ve established that it’s necessary to approach security holistically—taking into account not only threats, but also the business dimension of corporate security. In many cases, application risk profiles are defined by regulations such as Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA), and the Payment Card Industry Data Security Standard (PCI DSS). Whereas application security was once a “nice-to-have” feature for many organizations, in today’s increasingly regulated environment, security can have a direct financial, not to mention legal, impact.

To achieve the blessed state known as “compliance,” low-level application security policy needs to reiterate high-level corporate policy. For example, a corporate policy might mandate that only administrators and doctors can view electronically protected health information (EPHI) data covered under HIPAA. The embodiment of that corporate policy in an application security policy would express the requirement that specific data fields (that is, EPHI) must be encrypted using a particular algorithm with a particular key size, or it might mandate that specific data must be redacted unless a user has specific permissions in the system.

Compliance refers to how accurately a corporate policy is implemented and enforced by the many security policies deployed through the organization. The challenge for a complex environment lies in knowing to what degree the applications are in compliance with corporate policy. Governance provides a tripartite solution to this problem: central policy management, distributed policy enforcement, and auditing.

What’s a Policy?

Let’s examine in more detail what we mean by a “policy.” In terms of application security, a policy expresses the capabilities and constraints of an application. A policy can be implicit or explicit. For example, if I release an application into production with no password protection, the implicit policy is that anybody can use the application. That implicit policy may be at odds with the explicit corporate policy that states that only authorized users should be able to access the application. Another term for explicit policy is declarative policy. Declarative policy states, as precisely as possible, exactly what constraints the application should enforce.

Codified in specifications such as WS-Policy and XML Access Control Markup Language (XACML), the policy-driven model abstracts the definition of security policy from its enforcement in the system. Simply put, a policy tells an application how to behave. Clear enough. But how are those policies configured? Who configures them? How do you take policies that have been defined and then apply them to the specific applications where they are relevant? In simple terms, how do you take a policy and then enforce it on one .NET application and on another Java application? How do you manage this process over time, through upgrades, software releases, and evolving business requirements?

Crank this example up to an enterprise network where you have hundreds of applications running on five or six platforms and twenty or thirty policies defined by different stakeholders. Then you may begin to sense the frustration experienced by those trying to deploy SOA on a grand scale.

What is Governance?

The set of procedures used to manage IT projects from a business perspective is called “governance.” Governance provides guidelines, control mechanisms, and traceability for policies and the way policies evolve over time. Governance helps you get a handle on your policies.

Basically, governance specifies who defines and reviews policies and when and where those policies are applied. Thinking in terms of security policy, integration with a governance solution is critical to a successful and secure SOA deployment.

While many software security providers are implementing policy-driven security, no one is adequately governing it. SOA policy provisioning and management have traditionally been associated with service registries and repositories, otherwise known as design-time governance solutions. Service provider information is published to a registry, where service consumers can look up and obtain additional information about the service, including interface definitions, endpoints, and policies.

The drawback to design-time governance is that it’s basically manual, an extra-step in the already bureaucratic process of managing application code. In this respect, design-time governance goes against the grain of human nature. Developers will simply seek the path of least resistance, and this often leads them to bypass processes that have no associated intrinsic value or incentive.

The alternative, runtime SOA governance, performs these functions in a “hands-off” fashion, leaving developers to focus on business logic. Runtime governance provides a real-time picture of the world as it is—rather than as we would like it be. In real-world deployments, the rose-tinted glasses of design must, at some point, defer to the cold, hard facts of the runtime.

A Policy-based Approach to SOA Security

To provide true runtime governance, a solution must support security-related scenarios, such as:
 

• For all logistics services in QA, use testing cryptographic credentials.

Or

• For external procurement services consumed by platinum customers, require the “Platinum” role, require a strong authentication, and forward the user’s credentials to the back-end service.

Such a policy-based approach has the added benefit of easing integration with existing infrastructure. First, register all security-related infrastructure with the governance system: identity management systems, user stores, keystores. Then, transparently leverage the registered infrastructure within higher-level security policies for authentication, authorization, integrity, confidentiality, and non-repudiation.

To avoid inconsistent policy enforcement and unmanaged endpoints, policy must automatically and continually synchronize with the appropriate service endpoints. In such a system, changes in metadata result in changes to applied policies. Move a service from QA to production and the system will automatically provision that service with a new set of production policies, while deprovisioning the set of policies designated for QA services.

Runtime governance delivers value not only by decoupling security coding from application development, but also by decoupling policy definition from its implementation or configuration in the infrastructure.

Intelligent policy provisioning makes it possible to rationalize security policy across a heterogeneous (and therefore normal) SOA.

Secure SOA Endpoints: Last-mile Security

“Last-mile security” refers to communication between a management intermediary and a service endpoint—the final “leg” of an SOA transaction. Last-mile security protects the service where it is most vulnerable—at the endpoint—as the last line of defense. A key concept here is defense in depth: If all has failed, last-mile security means that your service is never without protection.

Last-mile security is hard. Why? Well, you are asking the endpoint itself—the terminus of the transaction, which should be focused on business logic—to perform some sophisticated security processing. Like, check with the IMS for the user’s role, make sure the user is the proper role to access this operation, decrypt the sensitive data, encrypt or redact sensitive data on the response, and transform a digital signature into a username/password that the legacy application understands.

With a plug-in agent architecture, you can easily secure the endpoint. The plug-in does the security processing on behalf of the application on-board, leaving the application to do its business work. In this architecture, it’s the plug-in agent that receives and enforces the policies. The application doesn’t need to be the least bit policy-aware. Instead, the plug-in agent must keep track of what services are deployed on the endpoint, and what policies apply to each service.

Likewise, security policies on outbound messages are enforced before the message hits the network. Sensitive data can be stripped or encrypted before it is exposed on the network. In the absence of last-mile security, messages must be sent across the network to the management intermediary before any security processing takes place. This leaves the message vulnerable from the time it leaves the endpoint until it is processed by the intermediary.

As the industry moves toward a world where SOA components are increasingly policy-aware, the necessity for deploying plug-in agents will wane. Instead of plug-in agents, the platform itself will enforce the policies as dictated by the SOA governance system. As the WS-PolicyFramework is implemented in interoperable fashion by vendors, this “agentless” policy enforcement will become increasingly common.

While last-mile security is a critical piece of the SOA security puzzle, it does not, in itself, provide end-to-end security. To account for the initial leg of an SOA transaction, where the key issue is client enablement, we introduce the concept of first-mile security.

Trust Your Service Consumers: First-mile Security

Service consumers, or SOA client applications, are often overlooked as more attention is paid to creating sophisticated composite services. Yet who will make use of SOA services if SOA clients are neglected? An oft-overlooked fact in policy-driven systems is that enforcing security policy on the service immediately places a burden on the client to implement corresponding security features.

You want your consumers to follow certain rules to meet the security requirements for using your service. Yet how do you tell your clients how to behave? You need a mechanism that lets them know what kinds of tokens are acceptable—for example, username/password, X.509 digital signature, or SAML assertion. Of course, you want an agent to handle this on behalf of any human user (if a human user is involved). You can’t ask a human being for an SAML assertion.

Apart from simply on-ramping your consumers, you also need to insulate them from service and policy updates of any kind. You might have to update your policies because a new threat or a regulation has emerged. Financial institutions will vividly recall the FFIEC guidelines of 2006. These guidelines gave financial institutions around twelve months to implement “strong authentication” for consumers of financial services. With this sudden requirement came the need to update policies for service providers. Imagine if it had been as simple as pushing out new policies to the services and having the clients dynamically update themselves to provide strong authentication?

To support dynamic client enablement, a service must be able to communicate its policy requirements to prospective service consumers. The client application must then be able to execute those requirements. Additionally, there is a need for policies that divulge only the information needed by the client, keeping secret additional processing, such as auditing, that may be taking place on the enforcement point. This policy “conversation” must occur between products from heterogeneous vendors, and should therefore be formatted according to the WS-Policy and WS-MetadataExchange specifications, enabling clients to consume this policy in a standards-based, interoperable fashion.

A client agent must be able to dynamically consume some form of policy description from a managed service. The policy indicates what security processing should be performed on the request, and what security features to expect on the response. The client agent then executes policy automatically on behalf of the client application, seamlessly providing the client application with secure access to the target service.

By providing support for multiple authentication methods on a single request, client-side agents enable “trusted clients.” A client policy can specify both username/password and a digital signature. The username/password identifies the user, while the key used to generate the signature may be bound to a specific machine. This strong authentication ensures that a stolen password cannot be used from an unmanaged computer.

The Power of Policy

While SOA is creating many new security challenges, it is at the same time providing the means for solving some age-old security problems. By fostering the environment where policy-based governance is becoming the norm, SOA has created the conditions whereby, with the right tools, all application security can be centrally managed and enforced on the diverse and distributed technologies and platforms that typify today’s network environment. You can’t have governance without security, and you can’t have security without governance. This change signals that security is, as long promised, perhaps finally beginning to take its place as just another part of the infrastructure.

Andrew Brown has more than ten years of experience in developing and marketing enterprise security solutions and is the director of Security Product Strategy at AmberPoint (abrown@amberpoint.com).