IBM Business Automation Workflow, Security Vulnerability Analysis Part1: The Method

Published in

IBM Digital Business Automation Tips and Assets

9 min readMay 21, 2020

In this two part article, I will examine the practice of security vulnerability scanning for IBM Business Automation workflow (BAW) projects. I will share my approach and discuss specific vulnerabilities and how to address them.

Protecting computer systems from breaches is a real and constant concern for companies. Today, there is an increasing need to have an eye for protection and defensive strategies. It is no different for IBM BAW projects where it is important to run a rigorous cycle testing to secure the system from known vulnerabilities.

In this article, I will share my experience on the method and steps, while dealing with security vulnerabilities for workflow projects. This will be detailed in two parts. This first part focuses on the procedure and methods, to address vulnerabilities, in order to create a safe and secure system. In the second article of the series, (part 2) based on my experience, I will share common and specific vulnerabilities and how each one was addressed.

Preparing for Security Scanning

IBM BAW (formerly IBM Business Process Manager) releases are
tested/scanned by IBM before it is released, as part of the labs, to support clients in creating secure workflows, that are built using prescribed best practices.

The first step in preparing the environment is to make sure your systems and subsystems are up to date with the latest fixes and patches, especially the ones that are security related. In case, any security vulnerabilities are seen in the product post release, IBM will typically create an Interim Fix (iFix) or add fixes to the closest Cumulative Fix (CF). Recent fixes should be reviewed and applied in the environment as soon as practical.

This applies to relevant fixes and upgrades for IBM WebSphere Application Server (WAS) as well as IBM HTTP Server (IHS), besides IBM BAW.

Few of the fixes on IBM BPM/BAW, that I have applied in my recent customer engagements, are provided in the section “Useful References and links”.

TIP: As a matter of best practice, clients should track fixes and releases and monitor especially for security related fixes. Risk assessment for any Security fixes should be immediate and needed fixes should be applied quickly in environments.

BAW is a platform for workflow applications and as such each business may have some varying security needs. IBM BAW has a number of customisable security hardening settings that should be reviewed and set as appropriate to the environment. These settings include:

i). Response headers can be used to manipulate actions of browsers (allow/block) when handling requests, that may appear to have ill intent.
For example,

XframeOptions can be set to DENY, SAMEORIGIN or ALLOW-FROM to disallow browsers from embedding user interfaces in iframes and thus, mitigating potential clickjacking attacks.
Content Security Policy to instruct browsers to load and run assets in the context of BAW user interfaces only from a set of whitelisted origins.
StrictTransportSecurity to upgrade any http:// link to https://
X-XSS Protection to instruct browsers to enable their built-in cross-site scripting protection.

ii). Requests can be handled, by way of tokens /salts to protect against Cross Site Request Forgery, XSS etc.
For example,

Whitelist set of referers and the origin headers.
Set property CsrfSessionTokenSalt with a value of ‘verySecret’.
Protection of ajax links from coaches and ProcessAdmin console through CsrfSesstionTokenProtectedURI.

NOTE: These properties are not set by default. These can be set using wsadmin commands from the Deployment Manager (Examples of these configurations can be found @ BPM Security Hardening).

Since there is always some element of custom code, that may expose any vulnerability, it is a good practice to have vulnerability scans run on applications regularly. IBM’s customers do have dedicated testing cycles for vulnerability scans using tools that aim at uncovering any vulnerability.

TIP: It was observed, that running these scans can impact system performance if there are a lot of bad requests sprayed in, hence, scans need to be scheduled appropriately, to minimise the impact on business activities and transactions. This can be especially relevant if the plan is to run scans on the production system. My recent client engagement revealed that this can be true even when the scans are claimed to be “non-intrusive”.

Steps for Reviewing Security vulnerability Reports

Speciality products and teams are normally used to execute the security scan. It is our job to review and understand the outcomes . The end state or outcome expected from addressing a security vulnerability could be any of the following

Remediation —An example would be to be a fix pack for a particular vulnerability.
Mitigation — An example would be to apply configuration that alters the system behaviour i.e. block suspicious requests.
Acceptance — This is subject to individual client considerations in occasions of security risks observed.

The flow chart below depicts a methodical approach to assessing vulnerability reports. This captures the sequence of activities I used in addressing identified vulnerabilities.

Figure 1: Methods/steps to address Vulnerability

Scan, Categorize and Prioritize

Firstly, scan the report holistically and then categorize the line items into severity levels of vulnerabilities and Information exposure.
Beware of the tendency to first strike out the obvious ones. Most reports provide possible remedies to what appears to allay the vulnerability (See Figure 2 below).

Figure 2: Sample vulnerability as reported

It is very important to prioritize here and address the critical items.

Know your landscape

Know the overall architecture, this is important as you will need to make decisions and prioritize remediation based on your solution architecture and the role that different components have in the architecture. It is crucial for multiple teams to collaborate in the triage of vulnerabilities to ensure that these are remediated at the right place.

For example, customers using servers accessed from the internet may employ a DMZ that includes firewalls. The DMZ provides passage for all requests flowing in and out of the system. A vulnerability of returning error responses back to the user could be well handled at the Firewall(e.g WAF/F5), where in the response is intercepted and masked indicating a success. Here, it is expected to see collaboration between the firewall and the application teams.

The diagram below depicts a typical layout of components that participate in the request/response handling process for the requests that make up a business transaction.

Similarly, urls could be denied access /whitelisted at the Firewall itself to block out suspicious urls. Customer needs to work with their Firewall team to unblock legitimate requests.

Normal requests which have <script> tags could be formed due to customizations that are done during development. These would need whitelisting.

For example
/rest/bpm/wle/v1/coachflow/instancedata containing <script> tags and other suspicious tags like innerhtml could be allowed, after review,

while URLs like /ProcessPortal/login.jsp?errorMessage=”><script>alert(String.fromCharCode(88,83,83))</script> can be blocked since it is indicative of XSS.

If a vulnerability is accounted to be remediated by another team such as infrastructure or database, it has to be routed accordingly.

Repeat for each vulnerability

Check for known vulnerabilities published based on CVE Details. E.g. IBM BPM Vulnerability-list.

This would uncover any fixes that may be have been published to remediate the vulnerability. Some fixes that address the said vulnerability might be needed for application on WAS or IHS. The IBM Support team may be contacted for any clarification. A few fixes, my customer has applied, are listed in the section “Useful References and links”.
If not found in the known vulnerabilities, look for results published for IBM BAW on the App-scan findings @Interpreting IBM Security appscan findings. Another useful though a bit older publication can be found @Running security Appscan software.
These provide insights into what has been tested and deemed false-positive by IBM and some others that may need more investigation.

For example, a number of vulnerabilities could be reported for cookies used/set in IBM BAW requests and responses. The published findings indicate that Cookies like TeamWorks=8.6.0, isBidi … . can be ignored as they do not carry any sensitive information.

A common practice is to use a privileged user of the system when scanning for vulnerabilities. This can cause a lot of reported information exposure which may also considered a false positive, post verification.
If the line item in question is not listed as a known vulnerability or false positive, it must be analysed further. This may involve testing the URL in question (exact same request with the exact same parameters) and derive decisions from the response.

For example,
SQL injection vulnerabilities for URLs like rest/bpm/wle/v1/coachflow/service/1.. would need inspection of the service flow to determine if the injected code/script could cause issues such as writing to the data store or accessing sensitive information.

Analysis of vulnerabilities, cited for requests that contained /bpm/notification/cometd/ and cookie BAYEUX_BROWSER, indicated that these could be ignored. This is based on how notification, that employ cometd in a transport mode of long polling, works. The mechanism used is described at Cometd-security. It is always a good idea to confirm with the IBM Support team if in doubt. as to whether notifications are followed the same way in IBM BPM/BAW.

I have also had scenarios where configurations done in IHS and WAS had to be disabled, so that tokens that are critical for CSRF filtering could be effectively generated between requests in BPM.

Investigations and analysis could cover different systems/subsystems involved in the request lifecycle. Some of the security breaches are best handled at the firewall or the web server. For example, the Firewall component is known to employ data guards in order to mask what appears to be sensitive information like a credit card pattern.
Ensure configurations are tested completely in a lower environment. While you set a property /configuration for one aspect of security, it may not work in some other use case. Let the application run through rounds of testing before it can be deemed remediated.

In summary

Communication between teams responsible for different sub-systems is very critical so that any aspect of the functionality is not compromised. In situations of uncertainty, the IBM Support team can be engaged to get deeper insight on how the product behaves given certain configurations that are set in IBM HTTP Server(IHS), Websphere Application Server (WAS) and BPM/BAW servers.

Under situations, where security violation possibilities are detected in IBM BAW Solutions, customers may engage IBM Services to provide advisory support.

This concludes the part1 for “IBM Business Automation Workflow, Security Vulnerability Analysis Part1: The Method”.

Acknowledgements

I would like to thank my colleagues Ms. Maya Shenoi (mashenoi@in.ibm.com), Accelerated Value Leader, IBM India Software Services, and Leonard Blunt, Cloud Integration Expert Labs, ASEAN who have been very kind to review this article.