Internet facing deployment of IBM Business Process Manager

Cause

Introduction
IBM Business Process Manager includes IBM Process Designer, a powerful process development platform that allows both non-technical users, such as business analysts, and technical users, such as programmers, to model process flows and user interface elements. To cater for these different types of users, there must be compromises, for example, in the underlying functional scope and programming model. This means that while most business analysts are happy not to deal with the complexities of software development, programmers will likely see a lack of control in certain areas. Similarly, while business analysts can create coaches by dragging reusable components onto a canvas, coaches do not provide the level of control that a UI designer expects for pixel-perfect user interfaces.

The simplified programming model allows you to build applications that have a reasonable level of security. However, the level of security the model provides is not the same as you get with a lower level application development environment, which gives you, for example, full control over HTTP requests. Also, the simplified programming model allows you to take shortcuts to build functional, but less secure applications.

Security requirements in contemporary internet facing web applications

When you host an internet facing application, you should follow a set of good security practices to keep your users safe. These practices include:

1. Keep your software up-to-date
2. Limit the attack surface to the bare minimum required for running your application
3. Harden your infrastructure
4. Harden your application
5. Separate application tiers to add resilience
6. Regularly test for vulnerabilities (ideally, hire penetration testers)

The following sections discuss the challenges that each of these practices brings and what you can do to mitigate them.

Practice #1: Keeping your software up-to-date
The importance of keeping IBM BPM up-to date and how to subscribe to security fixes is described in this blog post. If you delay in applying patches, you are putting both you and your customers at risk.

Practice #2: Limiting the attack surface
You can build many different types of applications with the IBM BPM APIs. The various user interfaces that target end users, developers, administrators, and operators use the generic APIs to trigger actions. If you expose all of IBM BPM on an internet facing web server, this results in a very large attack surface. However, limiting access to only a set of user interfaces and "relevant" APIs is also impractical as there is no list of required APIs for coaches, human services, Ajax services, Process Portal, and so on.

Practice #3: Hardening the infrastructure

Infrastructure hardening is vital when hosting anything close to the internet. As IBM BPM is based on WebSphere Application Server, the WebSphere Application Server hardening recommendations apply, see: Advanced security hardening in WebSphere Application Server V7, V8 and V8.5, Part 1: Overview and approach to security hardening and Advanced security hardening in WebSphere Application Server V7, V8 and V8.5, Part 2: Advanced security considerations
In very few cases, some hardening settings might conflict with legacy applications that connect to IBM BPM, so you should plan for this step.

Practice #4: Hardening your application
There are many aspects to hardening applications. These include executing code with minimal privileges, authorization, avoiding information leakage, avoiding common weaknesses, such as cross-site scripting, cross-site request forgery (CSRF), and injection attacks.

Because IBM BPM is a general-purpose process modeling platform, you cannot apply "tailored" protection mechanisms to fit your application. For example, Content Security Policy is a mechanism by which web developers can control the origin of resources that a page fetches or executes. If you use coaches in heritage human services without Process Portal, you can specify that a coach must not be embedded in an iframe. Because of Process Portal, client side human services and many custom clients, IBM BPM cannot enforce such restrictions in the same way as a purpose-built web application can.

IBM BPM REST APIs are used for interacting with browser users and for system-to-system interactions. They were introduced in IBM BPM before the OAuth 2.0 standard was finalized, and as a result, the APIs are not as browser friendly as APIs offered by a purpose-built web application. To protect against CSRF, many web applications enforce a session-specific token with every state-changing request in addition to cookie-based authentication. Because token enforcement would break many existing (in particular non-browser) clients, IBM BPM uses the weaker HTTP referer header check instead.

IBM BPM is often used in highly collaborative environments. Process participants are expected to work towards a common goal. For seamless collaboration, IBM BPM ensures that a process participant (that is, a user who works on a task of a given process instance) can see all the data for this process instance, including the data for all other tasks and attached documents. Assuming "internet-facing" implies B2C (business to consumer) scenarios, this authorization model can be a concern. Where possible, we are tightening security in IBM BPM (for example, context-sensitive authorization for Ajax services and user and group related APIs was added in 8.5.6 and 8.5.7). However, there are many customer deployments that rely on existing behavior and make it hard to change.

As stated earlier, there are compromises and shortcuts in the programming model to enable less technical users to build collaborative workflows. In particular, the following elements can be easily misunderstood and lead to insecure process applications.

· For a cleaner user interface or to save screen real estate, you can hide business object fields in the UI by using the field-level visibility settings. However, the field values are still transmitted to the browser and they can be viewed in the page source.

· You can build custom coach views and let them set server-side variables without using sophisticated binding declarations. However, many developers don’t realize that all heritage human service variables can be set by boundary events, regardless of how the variables were bound to the user interface controls.

While you can address such issues by carefully scoping business objects and nesting coaches into dedicated nested human services, exposing a heritage human service is probably a security risk. Consider using client side human services instead of heritage human services. The client side human services programming model separates client side from server side code more clearly.

Practice #5: Separating application tiers
By separating a dedicated user interface application from the business process logic implemented in IBM BPM, you allow business processing while locking out end users while being under attack.

Practice #6: Testing for vulnerabilities

Prior to shipment, IBM BPM is tested with IBM Security AppScan Standard Edition for typical web vulnerabilities. However, the security of your solution depends not only on the IBM BPM product, but also on your infrastructure hardening and the code you built on top of IBM BPM.

To assess the security of your solution, we strongly recommend that you run automated vulnerability tests. Such automated tests generate reports that identify vulnerabilities, weaknesses, and many potential issues. We publish a list of tips for interpreting IBM Security AppScan results when scanning IBM BPM (see 8.5.6.0 and 8.5.7.0). In addition to automated scans, many vendors also offer external penetration tests.