Prior to joining IBM I worked at a bank where my team and I were responsible for 24×7 Production support and more than 30 active development projects.  We had over 400 queue managers and we did all this with just 4 guys. If that seems like a lot, let me tell you it surely was.  But we had a guideline that no matter how busy things got everyone was expected to spend 20% or more of their time on strategic activities such as training and problem prevention.  It was this continual skill building on our team and the training we supplied to the project teams that allowed us to cover so much with such a small team.

When I started the team I had four queue managers in Production and an active development project wanting more.  I was the only administrator and I was swamped.  We had different versions of MQ, our channels would not stay running and we had constant poison message problems.  But the bank sent me to the conference and to the formal training sessions and soon I figured out how to tune the channels.  We upgraded everything to MQSeries v2.1, which was brand new at the time, so the whole network was at the same version and fix pack.

The network doubled in size each year and I eventually got to grow the team to three people.  But each year I went to the conference and as soon as we added staff I took one of them with me as well.  Soon we had eliminated poison messages entirely by working closely and early with the project teams to make poison message handling a functional requirement on all projects.  Part of the service agreement with the developers was that my team could at any time drop a message on the queue with a payload of “If found, please call you MQ administrator at…”  The application was required to requeue or consume and log any message it did not understand.  If we didn’t get that call, the app didn’t go to Production.  Period.  No exceptions.

We had quite a number of development standards besides just poison message handling.  There were requirements for reconnect logic, security, exception reporting and more. We also had infrastructure standards such as the names for QMgrs and objects, specific initial settings on the QMgr, certain SupportPacs we always installed, etc.  We had tools to manage the network centrally and to perform ad-hoc queries and global commands.  But my point here is that we would never have known to do all those things if we were not regularly attending training and taking a day a week from tactical tasks to spend on strategic activities.

Stephen Covey (of 7 Habits fame) likens this to logging a forest.  It takes a LOT more effort if you are too busy sawing to stop and sharpen the saw once in a while.  Worse, once you convince yourself that chopping down the forest is more urgent than sharpening the saw, you’ll never complete the job.  You just fall further and further behind.  Most shops try but fail to brute-force themselves out of that hole.  You can’t work at 125% capacity forever and hiring your way out is a stop-gap measure at best.  If all you ever work on is urgent tactical tasks, the work grows to fill the capacity on the team – and then adds 25% more.  Years can go by with no significant improvement in either the number of incidents or the duration of outages.  The only way out is continuous improvement of skill, quality and performance and that requires stopping to sharpen the saw.

The worse things are, the more important it is to make time for strategic activities such as education, tooling, diagnostics and infrastructure.  Being too busy to attend technical education in your specialty is the best possible evidence that you need to attend.

Mon 10:45 – 12:00  1577 – WebSphere MQ: Securing your Queue Manager*
Mon 14:00 – 15:15  1576 – Introduction to WebSphere MQ*
Mon 14:00 – 15:15  1597 – Roundtable: WebSphere MQ Feedback*
Mon 15:45 – 17:00  2255 – WebSphere Connectivity and Integration Feature Session with Q&A Panel
Mon 17:15 – 18:30  1575 – What’s New in the WebSphere MQ Family of Products

Tue 10:45 – 12:00  1579 – WebSphere MQ for Managed File Transfer
Tue 10:45 – 12:00  1592 – WebSphere MQ: Machine 2 Machine Communications using Telemetry
Tue 13:30 – 14:45  1593 – WebSphere MQ: Publish/Subscribe Messaging
Tue 13:30 – 16:30  1595 – Hands-on Lab: WebSphere MQ
Tue 15:15 – 16:30  1581 – Extending WebSphere MQ and WebSphere Message Broker to the Cloud
Tue 15:15 – 16:30  1597 – Roundtable: WebSphere MQ Feedback*
Tue 16:45 – 18:00  1576 – Introduction to WebSphere MQ*

Wed 9:00 – 10:15  1589 – WebSphere MQ: What is your system up to?*
Wed 10:45 – 12:00  1578 – WebSphere MQ: Securing your Messages*
Wed 10:45 – 12:00  1591 – WebSphere MQ for zOS Internals
Wed 13:30 – 14:45  1596 – Meet the Experts: WebSphere MQ*
Wed 13:30 – 14:45  1585 – WebSphere MQ: Connecting to the Internet of Things
Wed 13:30 – 14:45  1586 – Using IBM WebSphere Application Server and IBM WebSphere MQ Together*
Wed 13:30 – 16:30  1594 – Hands-on Lab: WebSphere MQ Security (Distributed Platforms)
Wed 15:15 – 16:30  1584 – WebSphere MQ: Highly Scalable Publish Subscribe using Multicast
Wed 16:45 – 18:00  1588 – WebSphere MQ for Distributed Platforms Performance
Wed 16:45 – 18:00  1597 – Roundtable: WebSphere MQ Feedback*

Thu 8:45 – 10:00  1590 – WebSphere MQ for Distributed Platforms Internals
Thu 8:45 – 10:00  1587 – WebSphere MQ for z/OS Performance
Thu 8:45 – 10:00  1597 – Roundtable: WebSphere MQ Feedback*
Thu 10:30 – 11:45  1596 – Meet the Experts: WebSphere MQ*
Thu 10:30 – 11:45  1586 – Using IBM WebSphere Application Server and IBM WebSphere MQ Together*
Thu 13:30 – 14:45  1589 – WebSphere MQ: What is your system up to?*
Thu 13:30 – 14:45  1580 – WebSphere MQ: Simplifying Migration
Thu 15:15 – 16:30  1582 – WebSphere MQ for z/OS Shared Queues (Advanced)
Thu 16:45 – 18:30  1583 – WebSphere MQ: Clustering update

Fri 08:45 – 10:00  1577 – WebSphere MQ: Securing your Queue Manager*
Fri 10:15 – 11:30  1578 – WebSphere MQ: Securing your Messages*

The problem with the term “persistent queue” is that it leads people to believe that the behavior attaches to the queue itself when in fact with WebSphere MQ message persistence is now and always has been an attribute of the individual message. Because of the widespread use of the term “persistent queue” and an incorrect belief about behavior of the queue based on that, some customers find that WMQ doesn’t behave as they expect, often to their detriment.

There are two rules for persistence:

1. If the quality of message persistence is important, set it explicitly in the application.
2. Whether or not a message is persistent is always important.

The only time that DEFPSIST should be relied on to actually affect message persistence is the odd case that message persistence needs to be externally settable at run time. The reasoning is that persistence (or not) is a design decision driven by a business requirement. The person responsible for implementing those business requirements is the development team manager who has the opportunity to explicitly choose the correct behavior. When that choice is abdicated and placed in the hands of the WebSphere MQ admins, separated by both distance and time from the actual business requirements, it doesn’t get managed to the original business requirements and that results in a brittle system.

One of my first assignments with IBM was a company who had been experiencing a network-wide WMQ outage for a couple of weeks. We determined that someone had changed DEFPSIST on a queue in a network that was tuned and designed for non-peristent messages. The result was an outage lasting almost 3 week. In another case a customer’s entire Message Broker service infrastructure went down in Production because someone decided that the transmit queue should be persistent.  Immediately after the change all replies to TEMPDYN queues were shunted to the DLQ. Fortunately in that case the DLQ messages immediately told us what the problem was so the outage was of short duration.

The pervasive misunderstanding of the queue’s DEFPSIST attribute continues to cause outages and the external symptom of that misunderstanding is the use of the term “persistent queue.” For instance, during debugging people often report the setting of the queue as if that somehow reflects the persistence off the messages in the queue.  “Where did my messages go?  I have a persistent queue!”  Of course there is no direct cause and effect there. The messages may have come through an alias or a QRemote where DEFPSIST(NO) was set.  Or (hopefully) the application explicitly set the persistence that was required.  I climb on this soap box whenever I hear the phrase “persistent queue” during debugging because DEFPSIST tells me nothing about whether the messages in the queue were actually persistent or not.

Many people who understand DEFPSIST quite well also use the term “persistent queue” simply out of convenience – it has entered the culture and it’s easier than saying “DEFPSIST on the queue is on”. It’s worth asking even those people to not use the term so that a) we can identify the people who need education; and b) so as not to perpetuate the misunderstanding of persistence that leads to brittle systems.

So…there is no such thing as a “persistent queue.” Only queues with DEFPSIST(YES), which contain messages that may or may or may not be persistent.  Practice that discipline in your admin and programming teams and and you will find that the reliability of your systems improves over time.

10 – Documented message priorities are 0-9 but there’s an undocumented “Paul” priority.

9 – Paul doesn’t use message selectors. He just thinks about which message he wants and the QMgr delivers it.

8 – There is no message expiry. Only messages that Paul has allowed to live and those he has not.

7 – The signed certs trust the CA but the CAs trust Paul.

6 – Paul used to get terrible service in restaurants so he optimized the put-to-getting-waiter algorithm.

5 – Andy Stanford-Clark’s house has a sign out front that reads “Powered by Paul.”

4 – Paul authenticates to your QMgr with “it’s me.”

3 – When WebSphere MQ was invented they found a message already on the queue with the MQMD.UserID == pclarke.

2 – Paul doesn’t need his passport at customs.  He shows them his identity context.

And the #1 Paul Clarke fact:

Paul can cause a message in a rolled back UOW to be committed *and* still maintain transactional integrity!

A colleague sent an email with the subject “PCI zone and non PCI zone in same DataPower box” today and asks the following question:

I would like to pick your brain regarding a question from customer.  They want to share the same DataPower box for PCI and non PCI data.

The premise of the subject line is wrong.  It is not possible to have the PCI and non-PCI zones in the same hardware or software component.  For purposes of PCI a component is either in scope or not in scope for the assessment.  If PCI data runs through the component in plaintext (or encrypted if the component has access to the keys) then the component is in scope.  So the DataPower box in this scenario would be in scope for the assessment because of the PCI data it handles.  What you actually have here is a question about running non-PCI data through the PCI zone.

What does “in scope” mean?  This is not a comprehensive list but the following apply:

• All points of data ingress or egress must be accounted for and PCI controls applied.  (Shut down unused ports, change default passwords, authenticate users, etc.)
• All legitimate users must be accounted for and role-based access control with least-privileged authorizations applied.
• Adequate controls must exist to assure that PCI data does not leak to unintended destinations.
• Sufficient auditing and monitoring must be in place to verify all of this.
• Monitoring must be able to flag unusual or unauthorized data access.

Any system can be made PCI compliant despite routing non-PCI data through it.  The question is whether the cost of compliance exceeds the cost of segregating the data.  Those costs come in the form of implementing the necessary controls but also there are additional recurring costs because the scope of the assessment is expanded.  For example, if you have an egress route for non-PCI data you must show that sufficient controls exist to GUARANTEE that PCI data will NEVER flow through that path.  Two non-PCI egress routes?  Double that incremental cost.  Ten non-PCI egress routes?  Ten times that incremental cost.  These costs recur at every assessment.

Of all the systems where you might mix PCI and non-PCI data, a DP box is one of the best because it should be relatively easy to inventory data access paths and users, and it has good auditing capabilities built in.  However even with DataPower boxes there is a break-even point where the cost of monitoring, auditing, access controls and assessment on the non-PCI portion of the data exceeds the cost of a second box.  The key is to understand the costs of the controls and the recurring assessment costs against this expanded scope.  As a hardware/software vendor I am sometimes perceived as benefiting by selling two of everything to meet PCI compliance.  However what it really comes down to is that the cost of compliance and recurring assessments is reduced when PCI data is strictly segregated and that cost differential usually exceeds the cost of the extra hardware and software.  But in order to make that decision, you need to be able to do a good assessment of the alternatives and a cost/benefit analysis.

In the end, that’s what I recommend: to closely examine the cost of compliance on an undifferentiated network versus a segregated network and decide for yourself.  When you do buy that extra DataPower box or Broker license it won’t be because I recommended it or because it is a “best practice” but because that approach actually turns out to be less expensive than the alternative.

I gave up and called the number from the voice mail.  It asked me to “speak or enter your credit card number.”  I asked it to “please let me talk to a human.”  After a minute or so of pounding on the 0 key, an actual human responded.

Bank: Hi, can I have your card number please?

Me: No.

Bank: I’m sorry?  I’ll need your card number in order to help you today.

Me: How do I know you are my bank?

Bank: Well, we are alerting you to some suspicious activity on your account.  If you give me your card number, I can look up your account and we can see if the transactions are fraudulent or not.

Me: Well, how about instead I alert YOU to some suspicious activity on my account?  It seems I received a phone call claiming that there is some odd transaction on my account.  But the customer service number that I know is my bank doesn’t know anything about it.  When I do call the unverifiable number, the first thing they want is my card number and presumably some additional identifying information SO THEY CAN STEAL MY IDENTITY AND TAKE OVER MY ACCOUNTS.  Now, I ask you again, do you have any way to identify to me that you are in fact my bank  BEFORE I give you any personal or account information?

Bank: No, not really.

Me: And if you are who you say you are, don’t you have a problem with this?

Bank: Your point is valid but I’ve never heard of anyone objecting to this.  We have a whole department full of operators and this is all we do.  All day long.  Honestly, it’s safe and not a problem.

Me: Then your management are idiots and your customers are all sheep.  This is unreasonable and I won’t comply.  What are my alternatives?

Bank: I guess you could go to your local branch.  They could then verify me by name in the company phone book.

Me: Anything else?

Bank: It’s possible the alert may be posted to your online banking by now.  Do you use online banking?

I do in fact use online banking and the alert was posted there.  So after all was said and done, I found out that the “suspicious transaction” was a disk drive I purchased at my local Best Buy.  I mean, c’mon it’s ME.  Whatever happened to “know your customer”? Buying a disk drive… near my home… on the weekend, should be the least suspicious of my charges.  You see a large celery purchase, then call the cops!

But regardless of the legitimacy of the charge, the customer-side process is an identity theft nightmare just waiting to happen.  They tell you to never give out your information to someone who calls you but to hang up and call back so you know it’s the right company.  But being the one to initiate the call is no protection if you call a number that a stranger provided and which you cannot verify!  The bank should know better.  WE as customers should know better.  If this happens to you, refuse to give your information without the bank verifying who they are.  (Which of course they cannot do without first getting YOUR info so they can tell you something about your account that only they would know and by then it’s too late.)  Insist that the number on the card MUST be the one you can call for things like this and then hold the bank accountable.

Before we get started, let me put some scope on this.  I am NOT talking about password databases here.  Any time that many passwords are stored, they should always be encrypted using individual salt values and iterated hundreds of times with an irreversible hash function.  OWASP has a lot to say on that topic and I won’t attempt to cover it here.  What I am talking about are passwords used to authenticate an application to something else.  Typically in the MQ world these are passwords to a Java keystore and the application needs at most one or two of them.  The question then is how much benefit is derived from encrypting a single password in a configuration file?  Arguably in many cases that achieved benefit is actually a net negative due to weaknesses in password management.

Ultimately, it comes down to this: any system that must boot to operational status unattended must have access to a useable authentication credential.

Let’s examine that in more detail.

“Unattended” means that the system must go from powered down to fully operational without human intervention.  Is it acceptable that after rebooting a server all the applications start up a command prompt waiting for a human user to enter all the passwords?  Usually not.  Overwhelmingly not.  There are some cases where this is true but I don’t have the security clearances to work with those systems and if I did I couldn’t write about it anyway.  For everyone else we all need systems that recover automatically and without human intervention.  Bottom line, “unattended” means that the credentials must be stored where the application can access them at run time, usually in the file system.

“Useable” means that regardless of how and where it is stored, the credential must be capable of authenticating and/or  encrypting and decrypting to and from adjacent systems or applications.  In order to do this the application presenting the credential must be able to render an encrypted credential back to its plain text form.  If the credential can be rendered to plain text using only a defined procedure we say that it is obfuscated.  This is not that much better than a plaintext password since anyone who can read the obfuscated value can derive the plain text password.  If the credential has been encrypted then you need both a defined procedure and a key to decrypt it.  Arguably this is better because the attacker needs both the decryption process and the password decryption key.  But where do you store the password decryption key?  Compile it into the program?  Store it in the filesystem?  You could of course encrypt it, but then you’d be left with yet another key and no place to put it.  Bottom line, “useable” means that no matter how many layers of protection you put on a stored credential, the application must be able to unwind them and render the credential in plain text.

The combination of these requirements for unattended access to usable credentials ultimately means that if an attacker can read the filesystem, compromise the running operating system, or compromise the running application, then the credentials are compromised no matter how many times they’ve been obfuscated or encrypted.

Sure, there are ways to mitigate this risk.  For example, you might store the application credentials remotely, for example on a network hardware security module.  But you don’t access that Network HSM over plaintext do you?  No, you do so using TLS and authenticate with some kind of credential…which is stored on the filesystem.  Perhaps you encrypt the filesystem underneath the application?  OK but then to access that encrypted volume requires a credential…which is stored on the filesystem.  No matter how much obfuscation or encryption is applied to a password, if the application can render it, so too can an attacker.

If I’ve convinced you of anything so far, it is that encrypting individual application passwords doesn’t add to their effective security.  True, it ups the attacker’s skill requirement a bit but that just makes it less convenient for legitimate users.  A deliberate attack by a skilled adversary won’t be slowed down much, if at all.  But does encryption actually make the system less secure?  Perhaps.

To understand why, consider the administration required when passwords are encrypted and let’s use keystore management as our example case.  Legitimate administrators must know the passwords to keystores in order to perform routine maintenance.  If the local password is opaque to the administrator then there must be some means of accessing the plaintext version of it, for example when it is time to renew a certificate.  One approach to this is to use a single password across all systems and that is well-known to all administrators. This tends to lead to short, human-readable passwords that are subject to brute-force attacks, and of course compromise of one node leads to compromise of the entire network.  As bad as this sounds, you might be surprised to know how many shops use something like “mqm2011″ as their password.

So what is the alternative?  Some shops use secure password storage.  This too is usually protected by a human-readable password and again compromise of the password locker can lead to compromise of the entire network.  The main difference is that now the passwords are stored on or accessed from an end-user machine that probably has Internet access, email access and one or more browsers.  In other words, the passwords are now stored on the most vulnerable machines in the network.

Worse, the passwords must still be manipulated by humans so there is still a temptation to use short, human-readable strings that are subject to dictionary attacks.  If we are lucky enough to have a policy that dictates strong, complex and long passwords then there is no hope of getting these typed correctly into the tools where they are used.  Instead, we copy and paste them.  Now the passwords hang around in memory and swap files indefinitely.

Finally, consider that if all the administrators use some kind of password locker then there is a complete copy of the set of keystore passwords for each administrator.  The more administrators there are, the more copies of the password database exist.  As the number of copies expands, the likelihood that one of them will be compromised increases.  Add enough administrators and that probability approaches certainty.  You may be thinking “But T.Rob, we’ll NEVER have that many administrators!”  OK, but consider the corollary: given a small group of administrators over a long enough period of time and the probability also approaches certainty.

Now I’m not saying that there is no value at all in encrypting theapplication  passwords in the configuration files, or in using password lockers or in encrypted file systems.  Far from it, these are all very useful tools.  What I am saying though is that when we make these decisions we must be aware of our biases and attempt to neutralize them.  When it comes to encrypting passwords in configuration files we have a gut instinct which tells us that this is good and we tend to overestimate the incremental security value added.  We employ a mental calculus that tells us decrypting the password is hard and that accessing files is easy when in fact the opposite is true.  Any encryption on those passwords must be reversible and is usually the easy part.  In fact, if I can read your .kdb files I don’t even need to reverse the password since I can fire up my own queue manager of the same name and it can use the .kdb and stash file directly.  Since my queue manager knows how to read the stash file it is not the actual password that is important, just the ability to use it to impersonate you.  The entirety of your application security often comes down to nobody other than administrators being able to read the configuration files of the application.

We also tend to overlook the extent to which distributed management of keystores and passwords weakens security.  All of the management tools for keystores and public/private key pairs are designed to provide security with the assumption that the private key is generated where it will be used and then never moved or copied.  The FIPS-approved modules and algorithms even go so far as to wipe temporary storage before releasing it back to the operating system just to prevent partial artifacts of key generation from leaking out.  But no matter how secure the crypto tools are, they can’t compensate for administrators leaving a trail of passwords in copy/paste buffers and scp temporary files across the network.  I once had a client who actually emailed their kdb files around.  Encrypting the passwords results in a very slight reduction in risk if an attacker gains read access to the configuration files, but it does then require us to manage the passwords elsewhere.  Taking that step opens up a whole new avenue of attack that may be more vulnerable than the risk we intended to mitigate in the first place.

What is the alternative?  Consider a system where the keystores, private keys and their passwords are generated in place and stored locally in configuration files, in plain text.  This has several advantages:

• The passwords need not be human readable.  I typically use 63-character pseudo-random strings that would be impossible to brute-force.  I also wrap the keystore management commands in scripts that extract the password from the configuration file and insert it into the maintenance commands as needed.
• The keys and passwords are never copied or pasted on the workstations of human users, or otherwise shipped around the network, so there is no possibility of leaving a trail of artifacts.
• There is no temptation to use the same password on multiple nodes.  Compromise of one does not lead to any particular advantage in compromising others.
• Keys and passwords are stored only on machines that have tight physical and OS security and do not have access to the Internet.  (None of your servers have unrestricted access to the Internet, right?  RIGHT?!?!)
• There need only be one copy of any private key and keystore password.  The fewer the number of copies, the less chance of compromise.  If there are additional copies, these are on encrypted backup or other controlled media and not on human-user workstations.

The practice of encrypting passwords in configuration files springs from implicit assumptions that someone other than a legitimate user can read those files and that the attacker will not be able to perform the same procedure that the application uses to render the plain text password.  These are very bad assumptions on which to base a security model.  Always assume that anyone who can read the keystore and password file can impersonate the application, even if the password is encrypted, and design the security on that basis.  First and foremost, the operating system, underlying file system permissions and application access must be locked down tight enough so that only the legitimate administrators have read or better access to the configuration files.

Where application passwords must be encrypted or obfuscated, consider how to implement password management so that it does not weaken effective security.  For example, WebSphere MQ expects .kdb passwords to be stored in the stash file and there is no option for the queue manager to use a plain text version.  The level of security achieved then depends on how the administrative passwords are managed and this can range from “no weaker than the OS and filesystem” to “completely exposed on an administrator’s bot-infected laptop.”  Any attacker with read access to the stash file could easily reverse it so there is no additional risk incurred by storing the actual plain text password in the same filesystem with the other kdb files.  Any other measures which require the password or keystore to exist on any other workstation or server node reduce the effective level of security.

To the extent that encrypting passwords in configuration files leads to the implementation of distributed password management schemes, the result is often that the overall level of security is reduced.  If we know this, neutralize our instinctual biases as much as possible and then make a deliberate decision that the increased risk is worth the benefit in convenience, perhaps that is good enough.  But if we encrypt passwords in configuration files because our gut instinct tells us that encrypted passwords are safer, or because our security model is to protect against the threat of non-administrators having read access to configuration files, then the result is likely to be a system that is far less secure than we believe it to be.  That is usually worse than no security at all.

Of course, for this iteration she had written all new content for the conference.  There are so many changes related to security in v7.1 that almost all of the session was devoted to the new features!  There is almost nothing left of my content from the deck but hey, it was pushed out by new features and that’s a problem I love to have.  This blog post is a very high level overview of those new features.

WMQ Configuration backup
Although MS03 is great and the various owners of the SupportPac have been very responsive over the years, customers have long asked for a supported tool to back up their configurations and access control lists.  WebSphere MQ now has such a tool!  Though this may seem like a small detail,my definition of security includes the ability to recover after a breach.  Pulling this tool into the product means that you will now always have this capability, and it will remain current with each new release.

RUNMQSC versions of setmqaut commands
This is related to the previous item in that configuration backups can contain access control lists. The new twist is that you can now define these in the same script where you define the objects they pertain to.  Define a queue, define the access rules for that queue right after it.  Again, this may seem like a small thing but I can’t count the number of shops I’ve visited where the objects were backed up centrally but the setmqaut commands were not captured.  Part of the reason why was complexity and having to deal with two sets of files.  Problem solved.  Next!

Authorization control on non-local cluster queues
Here is where many of you are thinking “things just got interesting.”  Finally! No more QAlias definitions over clustered queues!  You can now define a profile that matches either a non-local cluster queue or even a non-local fully-qualified queue (where both queue and QMgr are specified on the open).  This does not replace security on the receiving end of course, but it sure does make life simpler on the sending side.

Channel Authentication Records
These records provide rules that can reduce or eliminate the need for exits such as BlockIP2.  For example, you can now set up rules that dynamically map an X.509 certificate Distinguished Name to a particular user ID and set the MCAUSER to contain that ID.  You can also have multiple rules with different specificity, for example one to admit connections from all administrators based on the Organizational Unit in the DN and another to deny access to that guy you fired last week based on his fully-qualified DN.  This provides some limited revocation capability in shops that do not enable WMQ’s native CRL or OCSP revocation checking.  There is even an option to ban administrative IDs and WMQ knows on a platform-by-platform basis which IDs are administrative.  That means you can have a baseline QMgr object inventory that includes a read-only Explorer channel, across all platforms, that is guaranteed to not allow administrative access.  Sweet!

Listener Blocking
This is a very useful addition if you have ever had a runaway client or a remote QMgr with a typo in the channel name stuck in a reconnect loop.  This feature doesn’t replace the firewall but sometimes the process of enabling and disabling firewall rules is too heavyweight for a temporary fix that the WMQ administrator needs right now.  The idea is that the listener can now be configured to ignore connections based on their originating IP address.  This happens before any data is read from the socket so is capable of absorbing a lot of connection requests.

Morag tells a story about how someone in Hursley started port-scanning the development servers.  Since WMQ cuts an FDC file when something unknown connects to a listener, the port scanner generated FDC files on all servers, every day.  Since they were in the process of writing this feature at the time, they simply enabled it and configured WMQ to ignore the port scanners.  Problem solved!  Of course if you are using some sort of IP sprayer that needs to know if the listener is up, you are better off configuring it for a TCP half-connect instead.

SSL FIPS and Suite B
Over time some of the ciphersuites that were once considered safe have been superseded by stronger versions.  WMQ needs to stay current with these and so v7.1 now supports newer FIPS-compatible algorithms as well as adding support for Suite B.  If you don’t know what these are then don’t worry about it.   For everyone else, probably a good idea to start planning your upgrade now.

Explorer Role Based Authorities Wizard
In my original presentation I used to have a list of setmqaut commands that would create a read-only Explorer channel.  I’m glad to see these removed and replace with a wizard that does the same thing!  You have a choice to set up either administrator or read-only access and the administrator generates a window with the commands it will run.  You can then copy the commands out or hit OK to have them executed by the wizard.

In the session someone asked whether there would be additional roles defined.  Currently the wizard has only the administrative and the read-only roles.  The thing is, these are the only two roles that are generic.  You know you will need an administrator role.  You probably need a read-only role, just for instrumentation if not for real human users.  But between these two extremes, everything else falls into the “it depends” category.  If you come up with additional roles that you think are generic or at least broadly useful, I’d love to hear about it.

API Exit for clients
The foils say that this is the same interface as the API exit for the QMgr.  If that is true, I’d expect to be able to use MA0W at the client side.  In any case, a client API exit opens up a whole raft of new possibilities, such as the client equivalent of a message exit!

Client version in channel status
From time to time a FixPack will contain a security-related fix.  Any installation prior to that FixPack would then be considered vulnerable and need to be updated.  But how do you know which client version is attached to the QMgr?  As of v7.1, just display the channel status!  As of WMQ v7.1 the client version down to the FixPack level can be determined in the channel status display.

Version coexistence
Last but not least, you can now have WMQ v7.0.1.6 and higher coexisting on the same server as one or more installations at v7.1 or higher.  How many?  I believe someone from Hursley said they’d tested up to 128 installations on one box.  I’m imagining their summer intern saying “you want me to do WHAT?”  Anyway, this is again not strictly a security feature but in the event you wanted to implement v7.1 for it’s security features, you may need a nice migration path.  The coexistence feature lets you do that on the same hardware you are using now.  How sweet is that?

What’s next?
What I’ve listed here are just the security-related items and only a high-level overview.  The next step will be to get a copy after November 11th and actually play around with it a bit.  Between now and then there will be webinars hosted by Global WebSphere Community and I expect maybe a developerWorks article or two.  I’ll be sure to publish the dates and times for these events, links and so forth as they are announced so watch this space!