When you ran automated security vulnerability test tools to scan your IBM Business Automation Workflow applications (as you should) before V20.0.0.1, there were several findings that can be addressed by configuration.

The technote Interpreting IBM Security AppScan findings for IBM Business Automation Workflow provides guidance on interpreting these findings and which configuration needs to be applied for better protecting against possible attacks.

The Knowledge Center chapter on Security-hardening properties has all details on the various settings. Over the past several years, more and more settings were added to the product (and documentation), but they all started "off by default". All of them imply restrictions to what browsers can and cannot do and thus have a risk of breaking existing applications. With IBM Business Automation Workflow 20.0.0.1, we decided that the risk is sufficiently small and is outweighed by the benefits of enabling these protection features by default for new installations and during upgrade.

The knowledge center documents a small script that everyone should run to confirm a current environment configuration:

de = 'De1'

def printSetting(propertyName):
  value = AdminTask.getBPMProperty(['-de', de, '-name', propertyName])
  if value:
    print propertyName+': ' + value
  elif propertyName == 'Security.XFrameOptionsHeaderValue':
    print propertyName + ' is not set, it is obsolete, use CSP frame-ancestors instead.'
  else:
    print propertyName + ' is not set.'

print 'Security hardening settings:'
printSetting('Security.CsrfProtectionRefererWhitelist')
printSetting('Security.CsrfProtectionOriginWhitelist')
printSetting('Security.XFrameOptionsHeaderValue')
printSetting('Security.ContentSecurityPolicyHeaderValue')
printSetting('Security.StrictTransportSecurityHeaderValue')
printSetting('Security.XXssProtectionHeaderValue')
printSetting('Security.XContentTypeOptionsHeaderValue')
printSetting('Security.CsrfSessionTokenSalt')
printSetting('Security.CsrfSessionTokenProtectedUris')
printSetting('Security.AllowedHttpMethods')

Running the script in a default V20 environment results in surprisingly little output:

Most of the settings are "not set", so how is the system hardened?

Defaults for each setting are documented in the Knowledge Center. Note that for V20, there are default values:

This was not the case in earlier versions. What this means is, when no value is set in configuration, the documented default applies. Indeed, when you can review the result by inspecting HTTP responses, all these headers are present:

If you paid very close attentions, you noticed that there is a setting Security.CsrfTokenSalt which does have a value. The value of this settings must be the same in the whole cluster, but should not be the same across installations of the product. That's why a random value is generated during install (or upgrade to V20) and stored in configuration.

How can I "unset" a parameter?

As described above:

1. Each of the hardening settings has a small risk of breaking existing applications that relied on lax browser behavior
2. Not setting a value will cause default header values to be returned in HTTP responses

Setting a specific header value is easy and documented, but how can you avoid a specific header like Strict-Transport-Security? There is a special keyword of "unset" that can be applied to the following settings:

Security.AllowedHttpMethods
Security.ContentSecurityPolicyHeaderValue
Security.CsrfSessionTokenProtectedUris
Security.StrictTransportSecurityHeaderValue
Security.XContentTypeOptionsHeaderValue
Security.XXssProtectionHeaderValue

For example, the following command passes the value "unset" for Security.StrictTransportSecurityHeaderValue via wsadmin scripting:

wsadmin.bat -lang jython -conntype SOAP -c "AdminTask.setBPMProperty(['-de', 'De1', '-name', 'Security.StrictTransportSecurityHeaderValue', '-value', 'unset']); AdminConfig.save()"

These settings take effect without restart, it just takes up to one minute by default until config changes propagate from deployment manager to each node. You will see log output like the following indicating that that values reached a given AppServer JVM:

[12/22/20 14:16:33:626 CET] 0000006b BPMConfigComp I com.ibm.bpm.config.util.ws.BPMConfigComponent onChangeCompletion Resetting BPM custom properties cache
[12/22/20 14:16:33:626 CET] 0000006b BPMConfigComp I com.ibm.bpm.config.util.ws.BPMConfigComponent onChangeCompletion Resetting BPM endpoint service cache

The next HTTP response will not have this header set.

Stay tuned for future blog posts on the exact effect of these settings and more hardening tips.