5 Things to Know about IBM BPM Security
AxelBuecker 270000KUKR Comment (1) Visits (14328)
With so many security breaches making headlines these days, it’s obvious that security is a hot topic. In this blog, we’ll take a look at 5 things you should know about IBM Business Process Manager (BPM) security, and we’ll point you in the direction of some resources that can help you do everything you can to keep your BPM installation safe and secure.
1. Understand why BPM security is important
Consider the fundamental need for securing your BPM systems. First of all, IBM Business Process Manager is based on Java 2 Enterprise (J2E) technologies, and so it has the same security requirements as any other J2E enterprise-ready application. Authentication, authorization, and protection of sensitive data are all topics that are common to any J2E application, and so many casual observers may stop their inquiry there.
However, IBM Business Process Manager — in many ways — is not just another J2E application. When you look at an organization’s existing software systems, you typically find applications that are single-purpose built. The successful hacking of these applications could certainly expose the process’ data, but it is hard to conceive of how such a breach might expose the actual business steps, decision points, or overall operational strategy of a department’s business functions.
This is not true of IBM Business Process Manager. IBM BPM encapsulates more than just a process’ data. IBM BPM process applications capture the very essence and details of a department’s way of doing business. IBM BPM paints easy-to-understand flowcharts of process steps, which employee groups are entitled to execute particular steps, the decision points, and details of how those decisions are evaluated are all stored in the IBM BPM databases.
In addition to these philosophical arguments, there are some practical considerations that need to be addressed with respect to IBM BPM security. IBM BPM is based on a unique hub and spoke deployment model that is built upon the normal J2E deployment model, but extends it in ways that are specific to IBM BPM.
IBM BPM also has a unique instance-based authorization model that adds significant functionality beyond the normal J2E authorization techniques. IBM BPM is delivered on top of IBM WebSphere Application Server, which includes a very sophisticated Virtual Member Manager that can utilize a corporate LDAP (as well as other) user and group repositories. Many applications make use of this group information to perform a high-level authorization, but IBM BPM’s model extends this in ways that need to be understood in order for you to fully evaluate the security implications.
Finally, the ways in which IBM BPM connects to external systems (web services, message queues, and so on) differ depending upon which IBM BPM product you are running (IBM BPM Standard or Advanced), which version you are running (V7.5, 7.5.1, V8.0, V8.0.1, V8.5, and such) and what type of integration you are discussing (outbound versus inbound web service calls). All of these topics are addressed in detail in the IBM Redbooks publication "IBM
2. Harden your IBM BPM installation
IBM BPM is built upon, and is shipped with, IBM WebSphere Application Server, and security considerations span both of these domains, and these domains don’t always share the same terminology. Many security tasks are best thought of from the terminology and perspective of WebSphere, while others from the perspective of IBM BPM.
The basic installation unit in WebSphere Application Server is called a "cell”. A cell includes one or more “nodes”, and each node can host one or more “clusters”. Nodes are independent computers (or virtual machine servers). Clusters are a set of Java Virtual Machine Application Servers, which define the /ContextRoot in which J2E applications execute. Clusters can span nodes for high-availability — meaning that a single J2E application can execute within a cluster of individual nodes. Security and system synchronization is handled through lightweight processes called the Deployment Manager and Node Agents.
The basic installation unit of IBM BPM is called an “environment”. Business process applications are developed within the Process Center (or “development” environment). Once the process application authors are satisfied with their current iteration of the process application, they can take a snapshot of that process application and deploy it to the “testing” environment. Typically, process applications proceed from the development environment, to the testing environment, to a staging environment and finally to the production environment. Each of these IBM BPM environments represent their own WebSphere cell.
In the following diagram, you can see the dotted boxes as defining a cell’s boundary, and you can also see that each cell has a deployment manager and one or more nodes. The deployment manager is a WebSphere Application Server construct that doesn’t map into the IBM BPM lexicon, but the nodes themselves are where the real action occurs. A node contains 1 or more “servers” – which are Java Virtual Machines dedicated to a specific set of IBM BPM tasks. Depending upon the type of IBM BPM topology you choose, each node may have 1 to 5 servers that map directly to the IBM BPM concepts of AppTarget (where the BPM runtime engine executes), Support (which is where the BPM Performance Data Warehouse executes), and others. These servers are then clustered together across node boundaries.
By having each deployment environment hosted within a unique WebSphere Application Server cell, the cell’s security configuration can be leveraged and differentiated from that of other deployment environments or cells. For example, you would almost certainly want the staging LDAP server and the production LDAP server completely isolated from those of the development and testing environments.
In addition, in this diagram we can see that the dev and test environments share a common LDAP server (ldap-dev) – but that staging and production each have their own LDAP servers (ldap-stage and ldap-prod). Furthermore, both staging and production are 4-cluster topologies, where dev and test are only 3-clusters. The production environment also is the only environment where the deployment manager (dMgr) is broken out onto its own server (physical or virtual). This is not a strict requirement, but simply an example. IBM BPM and WebSphere Application Server allow a great deal of flexibility in how you define your BPM environment. For more information on this topic, see the IBM Redbooks publication "IBM
But reality is rarely as pretty as the previous figure would have you believe. The complications multiply when you consider the environment into which IBM BPM is being deployed. Each IBM BPM deployment environment usually has its own database server, typically a front-end web server, hardware load balancers, Single Sign-On solutions (which may be implemented as a hardware appliance), servers that host web services and/or any number of corporate Enterprise Information Systems (EIS) servers, as shown in the following figure.
All of these components talk to each other, and each line of communication introduces another touch point that needs to be scrutinized from a security point of view. Complexity breeds fragility, which in turn breeds opportunity for exploitation.
To combat this complexity, it is essential that you have a well thought-out, clearly understood plan for securing all product touch-points. This plan should include a number of hardening steps, such as:
3. Know who’s connecting to BPM
Authentication is the process of proving the identity of the user who (or even another computer system which) is requesting access to software.
The most common type of authentication is, of course, the userid and password. But there are other methods of authenticating to a server. Here are three categories of authentication:
For each of these types of authentication, one needs to consider the following:
In light of recent research showing the high incidence of security attacks that originate from employees or contractors, the choice of how users authenticate to your corporate systems should be evaluated carefully. Often, the choice of how users authenticate to corporate systems is decades old, and it might well be worth reviewing the policies within your organization.
Regardless of which authentication mechanism (or combination of same) your organization uses, the ensuing steps are the same: the user (or other computer system) presents some authentication information, WebSphere Application Server validates that this information is correct and current, and then WebSphere Application Server creates a security context (a subject and principal) on behalf of the user that accompanies all future requests during the course of the session.
Items to consider include:
4. Cleanly identify user’s roles
Authorization is the process of ensuring that a user (or other computer system) has permission to perform a given action.
In general, authorization can be enforced in a number of ways, including:
By far the most common conceptualization of user authentication that is implemented is based on group membership. Managers are authorized to perform some tasks, sales staff are authorized to view certain reports, purchasing agents are allowed to issue purchase orders. It is easy to conceive of a corporate LDAP with groups for managers, sales, and purchasing, and it is trivial for the business process designers to utilize groups such as these.
However, in a typical organization, there may be tens of thousands, even hundreds of thousands of users, and thousands of groups. These numbers can grow quite large, and so it is common to see an LDAP vendor restrict the number of users or groups returned by generic queries. For example, Microsoft Active Directory only returns the first 4,500 users and/or groups, truncating the rest from the results. This can obviously play havoc upon a business process application that uses LDAP groups for it’s authorization.
In addition, because LDAP products are optimized to handle read-only and static data, it is very common that the structure and content of the LDAP repository be under the strict control of an LDAP administration team. Furthermore, these groups may have been defined for legacy applications, and it is not uncommon for these legacy applications to no longer be in use, and yet their LDAP groups remain. This can run at odds with the core value proposition of the business process management product.
One of the most significant benefits of IBM BPM is its ability to model business processes in order to gain some perspective and, hopefully, to leverage this to effect business process improvement. In fact, the entire approach to IBM BPM – from process documentation, to process application development, to process improvement — is based upon agile principles.
It is quite common for a team of process designers to decide that a process could be improved if the roles were reexamined, possibly creating new roles and combining others. To rely upon the LDAP administration team to make these changes to the corporate LDAP is almost always untenable — untenable from both perspectives: the process designers want immediate turnaround, and the LDAP administrators need to ensure that changes will not break other enterprise applications that rely upon the LDAP structure.
IBM BPM provides extensive mechanisms for identifying which users should have access to which tasks. The IBM Redbooks publication "Bus
Authorization can also be defined for any given application along a continuum of granularity. For example, the following list of theoretical authorizations goes from coarse-grained to fine-grained:
As you can see, IBM BPM defines a very fine-grained authorization model, and does so in product-specific terms (for example, you are not authorized to run this task if you were also the last user to update this task). This is a strong argument for not simply considering the groups defined in your corporate LDAP as a source of user authorization.
Authorization is important because it is commonly overlooked — many organizations believe that since they have groups defined within their corporate LDAP, then that’s all that really needs to be considered.
5. Get expert help
Security is hard, and attackers are tenacious. By partnering with IBM, you can benefit from our multiple-client, broad-based perspective on how to increase your overall IBM BPM security posture. The IBM Redbooks publication "Bus
We encourage architects as well as business and IT management to plan for security from the very beginning of your investigations into a business process management deployment with IBM BPM. We believe that the sensitive nature of your processes represent a high-value target to attackers, and we want you to consider security as important as any other benefit brought to you by using IBM BPM. We want you to consider how the IBM BPM architectures fit into your overall IT infrastructure, and to know where you need to focus your attention on securing intra-product communications. We know that how users authenticate to your IBM BPM servers is a source of attack, and we want to ensure that you clearly understand how IBM BPM integrates into your corporate authentication system. And finally, we encourage you to think beyond the simple "group membership" model of how users are granted access to various business process applications and steps.
Bottom line: Security is hard. It's now up to you to make attacking your IBM BPM environment even harder.
J. Keith Wood is a Systems Architect and Security Team Lead in the IBM Business Process Manager services organization based in Austin, Texas. After 20+ years as a software developer and solutions architect, he now consults with business process management customers to promote more secured installations and environments. Before joining IBM, Keith consulted with a wide variety of clients in the financial services, telecommunications, and retail sectors.