Problem solve Get help with specific problems with your technologies, process and projects.

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.

Follow us on Twitter @SearchSOA and like us on Facebook.

This was last published in December 2014

Dig Deeper on Securing services

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What advice do you have for overcoming security problems with middleware tools?
Cancel
Middleware, in my opinion, needs as much or even more focus as any web front end or data bases. Enterprises tend to focus on web front ends, or network, or databases, because they're the things that have the most visibility. But middleware, depending on environment, can open more security holes than any other layer, especially in a service-oriented architecture. And middleware like CORBA, for example, until recently had an atrocious level of security.
Cancel
This is an interesting topic, and I'm not sure there is one approach that necessarily should be followed more than others.  A lot is going to depend on the technology you are using.  For example, in recent memory I've seen applications in Java move from glass fish, to JBoss, now its Wildfly (and while there are similarities in the platforms, security models have changed over time).  

In the Cloud age, now some of these Middleware applications, may in fact have two points where security is important.  at the end points where companies may subscribe to and use varying tool sets in the cloud, and then in the neighborhood, those others who may happen to inhabit the same 'cloud' neighborhood.  I believe a bit part of the current Cloud Race will depend on the security and reputation of the vendors who provide these services, especially in light of recent hacks in the news.
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

Close