Authentication is particularly important in IBM Business Process Manager because it determines who has access to your Business Process Manager applications. Using excerpts from J Keith Wood and Jens Engelke's new IBM Redbooks publication IBM Business Process Manager Security: Concepts and Guidance, here's the top 5 authentication security concerns that you need to consider with Business Process Management today.
1. Weak password policies
When we are asked to create a password, we humans nearly universally create passwords that are easy to remember. Easy to remember nearly always means easy to guess.
Brute force attacks against weak passwords are quick and relatively easy with tools easily downloaded from the Internet. Brute force refers to “just try” as often as you can. One way to prevent brute force attacks is a lock-out policy (lock a user account after x failed attempts). Other approaches slow attackers down by enforcing x seconds of wait time between login attempts or using captcha to verify they are interacting with a human user.
To make matters worse, most people will reuse passwords across multiple web sites. The administrators of these web sites then can (and often do) take this list of freely given user IDs and passwords and attempt to use these same credentials with other web sites. It is incredibly easy and surprisingly effective.
2. Failure to change default passwords
IBM Business Process Manager ships with eight default accounts (tw_admin, tw_author, and so forth), and each of them had as their passwords their usernames (tw_admin + tw_admin, and so forth). We have seen, in the field, that these default passwords are not always changed. Anyone who has any familiarity with IBM Business Process Manager would have a reasonable chance of gaining administrative access, based simply upon the knowledge of the factory-default password. IBM Business Process Manager V7.5.1 improves the situation, in that the main Business Process Manager administrative account name and password are specified at installation time. So, even if someone had intimate knowledge of IBM Business Process Manager, they still would have to guess the administrative account name as well as the password. However, the following default accounts are still created: tw_admin, tw_author, tw_portal_admin, tw_runtime_server, tw_user, tw_webservice, and bpmAuthor. We advise that you remove these default accounts and, instead, map actual users in your organization into the groups and roles which these accounts fill, by default.
3. Unencrypted communications channels
A failure to use Secure Sockets Layer (SSL) over all Business Process Manager-related communications channels is common. A simple network protocol analyzer, which is freely downloadable from the Internet, can be used to eavesdrop on network communications. Encrypt the communications channels and eliminate the possibility of these types of attacks before the opportunity arises.
4. Insecure LDAP connections
A bind account name and password are exchanged at each step of the IBM Business Process Manager to LDAP conversation. The deployment manager and node agents, the IBM Business Process Manager application servers (including /ProcessAdmin, /ProcessCenter and /portal), plus the Process Designer, all communicate with the Lightweight Directory Access Protocol (LDAP) server and issue this same bindRequest. Unless you secure your LDAP server using encryption (SSL), you are leaving your corporate LDAP server open to browsing each and every time an IBM Business Process Manager user logs into their /portal In box. We advise you to enforce encryption using SSL over the communications channel between the IBM Business Process Manager servers and your LDAP servers; be sure to disable non-SSL traffic; and create a specific SSL truststore and alias for the LDAP server.
5. Insecure Single Sign-On (SSO) solutions
Single Sign-On (SSO) is the ability to share credentials across systems. There are many SSO solutions that can be purchased and integrated into IBM Business Process Manager. Many SSO technologies rely upon cookies or HTTP headers to carry the user’s credentials with each HTTP request. Often, these credentials are encrypted. Unfortunately, that fact that these credentials are encrypted does not matter—an encrypted header can still be sniffed, copied, and injected into a hacker’s browser HTTP requests. The fact that the human hacker cannot read the contents of the encrypted header in no way diminishes the opportunity for attack; he/she will just paste into his/her browser the contents of this encrypted header, thereby impersonating the original SSO credentials. We advise that you bring in an outside security professional to review your SSO solution to ensure that it meets all leading security practices before you put any such code into use.
For much more, consult the IBM Redbooks publication IBM Business Process Manager Security: Concepts and Guidance. Do you have any Business Process Manager authentication security tips or experiences to share? If so, comment on this blog entry and we will respond!
Martin Keen is an IBM Redbooks Project Leader. He leads publications on many areas of IBM software, including WebSphere, Messaging, and Business Process Management. Follow Martin on Twitter at @MartinRTP.