How to address security risks posed by middleware tools
Middleware tools can present a huge vulnerability, enough to offset their benefits. However, with some simple steps you can protect yourself and your data.
Historically, developers exploit OS tools and features to build applications, but most OS tools focus on a single platform and local resources. As applications have developed into networked sets of components, ranging from client/server to distributed multi-component workflows, a new set of tools evolved to help developers establish consistent practices and to facilitate development itself. These tools, called middleware, offer great value, but because they mediate network services to applications they also can create a major security problem.
To address this problem, developers need to know the three primary security properties of applications: establish application lifecycle management (ALM) practices to enforce middleware security, optimize network security as a first line of defense, and add incremental security to specific middleware tools and interfaces.
Users agree that a "secure" application has three properties. First, it provides for access control through authentication of users and control of their privileges. Second, it protects information from interception or viewing while in a workflow, and third it ensures the integrity of transactions and their non-repudiation. You can support each of these properties through broad or specific security measures, so the most important step in securing middleware is the exploration of the possible security measures and the alignment of measures with risks.
Middleware risks are greatest where the applications supported by the middleware are sensitive, or where the middleware is on a platform where sensitive information is processed or stored. In these cases the middleware can create a secondary path for malware, through which applications and data can be compromised. By not mixing sensitive applications and more open (Web) applications on the same platform you can reduce middleware security risks, and also make it easier and less expensive to secure what's important.
Middleware security begins in the ALM process
All middleware security has to begin in the ALM process, where the goal is to ensure that middleware components and application components are fully authenticated before being integrated into a middleware platform or application. No security mechanism will be effective if the elements designed to support it can be contaminated by malware or defeated through unauthorized changes. The first step in securing middleware is to establish deployment practices that incorporate middleware tools and security measures into a common "secure middleware" element, and then require that ALM processes test both functionality and security whenever this element changes in any way.
The most vulnerable middleware tools are those related to workflow/message bus management.
Network security is the first line of defense for middleware. The more open the network, the more insecure the contents and the more important it is to add specific security mechanisms to protect middleware. Obviously, Internet access to applications and platforms creates the most open and risky network framework. Where applications and platforms run inside a VPN with specific access control, the network itself is secure enough to meet some application needs and that simplifies other security measures.
You can augment network security by building application-specific overlay networks to compartmentalize data and access to processes. These networks, usually built on encrypted tunnels, can provide both access protection and interception security, and even reduce the risk that information would be compromised "in flight" between components to assure non-repudiation. However, multiple application networks can complicate worker access to information, so where possible it's most practical to group applications by classification of worker and provide "application class access" rather than mediate per-application access.
Once network security has been exploited as far as is practical, it's time to look at the middleware itself. Experience shows the most vulnerable middleware tools are those related to workflow/message bus management. The goal of middleware security in workflow/message management is to prevent unauthorized introduction or interception of messages.
Add security by using the Web Services framework
One obvious way to secure middleware is to implement more of the Web Services (WS) framework, especially WS-Security between components, and in particular to secure connections to service/message busses. This is easiest to do within a vendor's middleware architecture (e.g., Microsoft's .NET, IBM's WebSphere, Oracle Fusion) because the security tools are integrated and available via standard development tools and practices.
Typically, basic WS processes have a limitation in that they don't address the way work can be distributed among legitimate components, which opens a risk that work steering (usually via BPEL) can send something to an insecure destination. While this mechanism is hard to exploit from the outside, an insider could use it to capture transactions or data that the recipient isn't entitled to see. To avoid this, you'll need to secure BPEL and also perhaps add policy management tools to limit middleware routing of especially critical data. This, again, is something often provided by architected middleware tools such as the ones described.
Most business workflow middleware is based on a message bus, but some applications benefit from a more dynamic structure. Often, a publish/subscribe model is used, but these tools are especially vulnerable if they're implemented incorrectly. It's critical when using such features that the "publishing" of capabilities or interfaces be limited to those who are by policy permitted to access them. Generally, message filtering will be required to enforce the security of publish/subscribe middleware unless the implementation is "inside" a secure network. This is usually applied outside the publish/subscribe middleware, at the level where users and resources are connected.
For all middleware security issues, a good place to start is an examination of the security features of architected middleware suites from major vendors. By looking at all the security features and how they're applied, you can determine if security issues would dictate a particular middleware approach, and also how various middleware elements are typically secured. Even if you don't pick a particular vendor's approach, understanding what that approach offers can guide your own middleware security evolution.
Middleware can present an enormous vulnerability to businesses, enough to offset many of its benefits. Don't let that happen when taking some simple steps in an organized way can protect you and your data.
About the author: Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
