Let's play a game of word association. What subject comes to mind with the words “engaging” and “terrifying”? Whatever you are thinking, I suspect it wasn't IT security. Yet those very words describe J Keith Wood and Jens Engelke's new IBM Redbooks publication. In it, they share their experiences of working with IBM customers around the world on securing IBM Business Process Manager solutions. Security pitfalls are everywhere and the stakes could not be higher.

This blog post is part of a series about common Business Process Manager security holes. In this post, we focus specifically on IBM Business Process Manager installation security. Much more information can be found in their Redbooks publication: IBM Business Process Manager Security: Concepts and Guidance.

1. Faith in your firewall

How often have you heard “it is the internal network, so it is secure” ? This is a dangerous posture to take. It is akin to placing all of your eggs in one basket. Can you trust with 100% certainty that your firewall vendors will never release a software update that has a security hole in it? How often is your laptop’s operating system updated with security fixes?

The simple fact is that many studies, from Gartner, Ponemon, the US Federal Bureau of Investigation (FBI), and others, have shown that security breaches are equally likely to be caused by employees as by external agents. Security breaches do not have to be the result of malice. They could be the result of simple, honest mistakes. But in the end, it simply does not matter. The security breach occurred and you have to deal with the consequences. The bottom line on firewall security is this: it is necessary, it is very helpful, but it is not a stand-alone solution to enterprise security.

2. Failure to use SSL between Business Process Manager and the database server

Everyone recognizes that database user accounts should be password protected. What most people fail to recognize is how incredibly easy it is to observe database traffic while it is in transit. The solution to this is simple: SSL. We strongly advise SSL/TLS for the communications link between your Business Process Manager servers and your database servers.

3. Failure to encrypt data at rest

The most powerful argument for encrypting your data is simply this: common sense. If you want to stay out of the security breach headlines, you need to take all elements of security seriously. There are three strategies to consider for the encryption of data at rest: application specific code, database encryption, and operating system and file system encryption. Above all else, do not keep the encryption keys anywhere near the data being encrypted. This is akin to putting bars on your windows, reinforcing door locks, and then leaving the key under the door mat.

4. Failure to use SSL between Process Server and Process Center

During the installation of a Process Server, you specify the host name of the Process Center it will be utilizing as its repository. By default, the protocol used is http://. During Process Server start up, the runtime environment uses this information to communicate back to the Process Center. This communication includes a URL, a user account, and the corresponding password. This information is all an attacker needs to know in order to deploy new snapshots of process applications. An attacker could also deploy his favorite malware application, which monitors the network and carries out denial-of-service attacks. So, take the time to change the protocol to https:// to avoid sending your Business Process Manager admin account name and password in clear text.

5. Overuse of default BusinessProcess Manager accounts

It is common to see one Business Process Manager administrator account used in every place where an account user name and password are created (for example for Administrator, Monitor, and SCA authentication alias roles). We highly advise that you create account names that closely reflect the roles or responsibilities of that account’s intended purpose, and that a human administrator never use an account like bpmAdmin or tw_admin. Every person must have a personal account. Failure to follow this fine-grained approach promotes a loose attitude towards who gets access to the administrator accounts. For example, if a person is given the bpmadmin account simply to deploy a snapshot to a runtime Process Server environment, then that same person now has access to just about everything else in the Business Process Manager universe.

6. Overuse of trust in certificate authorities

We advise that you reduce the number of certificate authorities in use within your organization to just the bare minimum that is needed. This advise includes the WebSphere DataPower certificate that is supplied with Business Process Manager if you are not making use of DataPower. There is no guarantee that certificate authorities fact-check the identity of the parties who purchase certificates from them.

For more on all these topics, consult the IBM Redbooks publication IBM Business Process Manager Security: Concepts and Guidance. Do you have any Business Process Manager installation 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.

Identificações:  bpm martin_keen firewall process websphere manager business ssl encrypt