Posts Tagged ‘encryption’

Simpler and cheaper – MQ MFT changing for your benefit

June 2, 2015

Change is always with us. IT infrastructure needs are changed. Application needs change. Skills profiles change. Even workloads and expected response times change. These changes we see in the market drive how we view our products. We frequently update MQ products, perhaps too frequently for some of our customers. As well as adding to and updating the functions and capabilities of MQ, we also try to update or change the packaging and the pricing of our various MQ offerings. We do this to try to respond to the changing needs of the market and the feedback we get from our customers.

As a way of describing this process, we have been recently talking about the different deployment choices available for IBM MQ. Check out this recent webcast on this.

The fundamental thought here is that your business should be able to use the value that MQ provides; however you choose to deploy MQ and consume it. The presentation in the webcast highlights a number of different ways in which your business might want to deploy MQ. This could be maybe reviewing the new MQ Appliance as a deployment choice, deploying the complete MQ set of capabilities using MQ Advanced or seeing whether you want to deploy and use IBM MQ in the cloud – whether that is a public cloud like Microsoft Azure or IBM SoftLayer, or a private/hybrid cloud infrastructure running on your own hardware on-premise, using something such as IBM PureApplication.

Manwithfiles

Going back to MQ Advanced, IBM announced on May 26th 2015, slightly new packaging and pricing for MQ Advanced. Included in this announcement were also various MQ Managed File Transfer parts. These parts were updated to reflect the needs of our customers – given their growing use of using Managed File Transfer with MQ.

As Senior Product Manager for IBM Messaging I talk to many customers through the year, and one of the constant pieces of feedback I get is about the ever-present need for better handling of file transfers. This is an area where every business has a solution, or 2, or 3 today. No one is happy with their existing offering, and most, even if they are existing MQ customers, are unaware that MQ can help.

MQMFT image

MQ’s Managed File Transfer solution can read data from a file, and send it as a MQ message over the MQ network. Once received on the remote system, the MQ MFT solution can then recreate the original file, achieving the movement of the file with greater security and reliability thanks to IBM MQ. This can help to address many of the issues businesses have with moving files, while also simplifying their infrastructure and consolidating on MQ. After initially using MQ MFT to move files, many businesses then take the next step to make use of one of the unique points of MQ MFT which is ‘file to message’ movement. As the file contents are moved as MQ messages, this data can then be directly consumed as MQ messages – meaning that the file contents don’t need to be written back as a file, identified, and then read in again. Instead the data can be delivered directly to the application as a MQ message.

The May 26th announcement simplified the packaging and lowered the pricing for how customers could purchase the MQ MFT capability – either as an extension to existing MQ licenses or as part of the MQ Advanced bundle. The MQ Appliance can also be a part of a MQ Managed File Transfer solution – acting as the co-ordination Queue Manager to allow the MQ MFT Agents to send and receive the file data as MQ messages. With  more and more MQ customers choosing to use and deploy MQ MFT we are changing the packaging to ensure they can do this more cheaply by removing the Connect:Direct and Control Center products we had bundled in as they haven’t been used as widely as the MQ MFT capabilities.

ApplianceMFT

Don’t forget that if you buy the MQ Advanced offering you not only get the MQ MFT Service part but also the MQ AMS capability for end-to-end encryption. This has also been a hot topic of conversation with customers and if you want to know more you can read my previous blog about it here.

Did you remember to lock your car?

November 12, 2013

Image

We’ve all done it. You have driven your car to a car park, walked away, and then had a momentary pang of doubt about whether you locked your car. It has become second nature to lock your car. To keep it secure. The car even locks the doors itself when it is in motion. But when you park it and walk away, that’s when the uncertainty comes in, and also when your car is most vulnerable.

It is the same with your enterprise messaging. What happens when you use a product like WebSphere MQ to send a message across your enterprise? Well, of course, what is happening is the application takes some data and packages it in the contents section of a message structure, along with some header information to describe the message and the destination. The message is then dispatched. All in all that’s pretty similar to you getting in your car and driving to the shops to buy something like food for dinner, or presents for a birthday. There is a destination and something of value to be transferred. With a car, you have to park in a space in a car park. With messaging, instead of a car park you have a queue manager and queues.

Messages start in an application and a MQ Client packages the information to be moved into a message. This then is sent to a queue manager, to be written into a queue. According to the destination or other information, the message is then sent on to either another queue, another queue manager, or to the destination client application.

As far as securing the message goes, when the message is moving between the client application and the queue manager, then the MQ resources are secured by MQ built-in security definitions and the message and contents itself is secured while moving over the ‘wire’ by use of SSL. However while the message is encrypted by SSL as it moves, once it reaches the queue manager, and is written to the queue, it is unencrypted and thus sits on the queue without any encryption. Thus if the system with the queue manager is penetrated, the messages on the queues are available in the clear. This is the same as parking your car in a ‘secure car park’ but leaving the car unlocked as the car park is secure. Would you do that? I’m pretty sure I wouldn’t.

Now what would we like to happen? What would be smart would be a routine that ensured our car was locked, pretty much at all times unless people wanted to get in and out of it – subject to key rules – such as ensuring people could actually get out or in when they needed. For messages we would want to make sure the message contents were secure at all times, including when sitting in queues, but would continue to be available to the receiving applications, and of course would still expose the header information needed for routing etc.

What IBM offers for WebSphere MQ is WebSphere MQ Advanced Message Security, which is also available as part of the entitlement of WebSphere MQ Advanced. This is a policy-based encryption capability which allows message contents to be encrypted from sending application to receiving application. So the contents are encrypted while it flows over the network and while it sits in intermediary queues. The applications are unchanged, with just updated client libraries to be used. And the security is based on policies, so different rules might apply for different message contents, or different queue managers. After all there are some times when you have to leave your car unlocked. So I’m pretty sure you have rules for securing your car. Isn’t it about time you had rules for securing your messages?

Image