Presentation delivered at Interconnect 2017. Session ID 6893: Keep out the bad guys by securing your MQ messaging environment. With today's focus on security, ensuring you utilize all of the options available to maximize your systems security is a high priority for many businesses. In this session, we will work through a step-by-step case study that details how you can enhance the security of your Queue Managers using the different features available in IBM MQ.

1. InterConnect
2017
6893 - Keep Out the Bad
Guys by Securing Your MQ
Messaging Environment
Robert Parker, IBM
T.Rob Wyatt, IoPT Consulting
1 3/30/2017

2. 2 3/30/2017
Please note
IBM’s statements regarding its plans, directions, and intent
are subject to change or withdrawal without notice at IBM’s
sole discretion.
Information regarding potential future products is intended to
outline our general product direction and it should not be relied
on in making a purchasing decision.
The information mentioned regarding potential future products
is not a commitment, promise, or legal obligation to deliver
any material, code or functionality. Information about potential
future products may not be incorporated into any contract.
The development, release, and timing of any future features
or functionality described for our products remains at our sole
discretion.
Performance is based on measurements and projections
using standard IBM benchmarks in a controlled environment.
The actual throughput or performance that any user will
experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in
the user’s job stream, the I/O configuration, the storage
configuration, and the workload processed. Therefore, no
assurance can be given that an individual user will achieve
results similar to those stated here.

3. 3 3/30/2017
Agenda
• Introduction
• MQ Security Features
• Authentication
• Authorization
• Confidentiality
• Step-by-step case Study
• Useful Links
• Questions

4. Robert Parker
IBM MQ Development
T.Rob Wyatt
IoPT Consulting
4 3/30/2017
Introduction

5. 5 3/30/2017
MQ Security Features
MQ Security can be split into four major
categories:
• Authentication
• Authorization
• Confidentiality
• Integrity
MQ has the following security features:
• Authority Records
• Channel Authentication Records
• Connection Authentication
• Transport Layer Security (TLS)
• Advanced Messaging Security (AMS)
• Security Exits

6. Rob Parker
6 3/30/2017
Security Features

7. 8 3/30/2017
Authentication Features – Connection Authentication
• Added in MQ v8
• Added the ability for Client’s to supply
credentials to be authenticated with.
• Credentials can be verified against three
different repositories (version dependant)
• OS
• LDAP
• PAM (8.0.0.3 + above)
• Granular Control over Who has to provide
valid credentials
• Local Clients
• Remote Clients
• Channel Authentication records
• Has features to link with Authorization –
ADOPTCTX
• (Platform + version dependant)
• Available in all MQI clients (C, Java, .NET)
• Credentials sent in MQCSP structure
• Be aware of Java Compatibility mode!
• Yes = Send user in MQCD
• No = Send user in MQCSP
• QM.ini EarlyAdopt can be used to change
when Connection Authentication is “actioned”.

8. 9 3/30/2017
Authentication Features – Connection Authentication
Connection authentication changed between
releases:
Initial Release
8.0.0.0
LDAP
Authorization
(UNIX/IBM i)
8.0.0.2
1. PAM
Integration
2. Explorer fix
8.0.0.3
Early Adopt Fix
8.0.0.5
LDAP
Authorization
(Windows)
9.0.0.0
All before
9.0.1.0

9. 10 3/30/2017
Authorization Features – Channel Authentication Records
• Channel Authentication rules are filters
• You create rules to block or allow connections
that match the filter.
• Supports generic and specific filters
• Specific rules have a higher precedence
than generic rules.
• Types of filters:
• SSL Distinguished name (Subject and
Issuer)
• Client User ID (MQCD)
• Remote Queue Manager name
• IP address/Hostname
• Order of rules precedence:
• BLOCKADDR
• SSLPEERMAP
• ADDRESSSMAP
• QMGR/USER MAP
• BLOCKUSER
• When allowing a connection you can use
CHLAUTH to influence Authorization
• Allows you to use a different user for
Authority checks
• Can raise Connection Authentication
requirement for a channel (CHCKCLNT)

10. 11 3/30/2017
Authorization Features – Authority Records
• Authority Records are created to specify who
can access what objects
• Each object in a Queue Manager (included)
can authority assigned to.
• Unless the user has authority, they will be
unable to do any action.
• Any user in the mqm group has full
Administrator access
• Authorities can be given to a group or user*
• Authorities for objects can be given for a
specific or generic list of objects
• Specific authority takes precedence.
• Authority records are your core security
feature:
• They are the last line of defence.

11. 12 3/30/2017
Confidentiality Features – Transport Layer Security
• There are three reasons to use TLS with MQ:
• Confidentiality - Encrypting transmissions
between Clients/QMGR and a QMGR
• Authenticating with a QMGR
• Integrity – Messages are hashed and
rejected if tampered in transit
• TLS uses certificates for identity:
• A TLS Server requires a Certificate
• A TLS Client does not necessarily require
one.
• If a certificate is used it must be trusted by
the other party.
• Certificates are stored in CMS keystores
(.kdb)
• IBM MQ supplies several tools for certificate
management:
• ikeyman
• runmqckm
• runmqakm
• TLS is enabled on a channel:
• Set a valid CipherSpec on a Channel
• Can force clients to supply a credential
• Can set a filter to only allow certain Peers
to connect
• Can change the certificate to use as
identity for the Queue Manager’s (v8)

12. 13 3/30/2017
Confidentiality Features – Transport Layer Security
• CipherSpecs get deprecated as and when
new vulnerabilities come out
• SWEET32 recently removed 3DES
Ciphers
• A single CipherSpec is supplied on a Queue
Manager channel and Client.
• These must match
• Client’s can be enabled for TLS using:
• Code
• MQClient.ini
• Environment Variables (MQSSLKEYR)
• MQ Supports certificate revocation
checking:
• OCSP
• CRL
• Set by hand in AUTHINFO objects or
using certificate information.
• MQ also supports some Cryptographic
Hardware.

13. 14 3/30/2017
Other Security Features – Advanced Message Security
• AMS is used to protect Message Data.
• It can be set up to provide three levels of
protection:
• Integrity
• Encryption*
• Both
• Levels of protection are detailed in policies
which are created specific for one Queue.
• When a message is put to a Queue
protected by a policy its data is protected
as specified in the policy.
• AMS protection is End-to-End
• It can be used to protect data from anyone
who is not supposed to be able to read it
• Even MQ Admins
• It can be used to protect data that falls under
standard compliance (HIPAA, PCI, etc)
• However, AMS does not perform access
control. Only Message data protection.
• Should be used in conjunction with other
security features

14. 15 3/30/2017
Other Security Features - Security Exits
• Security exits are customer-configured code
that MQ forks to during the connection
security handshake.
• Security exits may be bespoke Customer
written code, IBM samples, or commercial
vendor products.
• They use MQ’s Exit API to read data from MQ
and interact with MQ.
• An example would be using a security exit to
return MQRC_NOT_AUTHORIZED unless
the time is within operating hours.
• Before v8, password authentication required
use of channel security exits.
• The template Security exit and details of the
exit API is on the Knowledge Center.

15. 16 3/30/2017
How does it fit together?
• Although each security feature is their own
feature….
• … they can influence other security features.
• When designing a security model you must
consider all features.
• You must also consider the order that security
features are checked in when a client
connects
• This needs to be known for debugging
failed connections
• When a client connects and is blocked by
a security feature one of several return
codes indicates the problem. Normally
this is return code of 2035
MQRC_NOT_AUTHORIZED.
• MQ Administrators can see more
information in the Queue Manager logs.

16. 18 3/30/2017
From the diagram
• But what order are they considered in?
Authority Records
Connection
Authentication
Channel Authentication
Records (BLOCKADDR)
Transport Layer Security
Security exits
Channel Authentication
Records (***MAP)
Channel Authentication
Records (BLOCKUSER)

17. 19 3/30/2017
Early Adopt
• Early Adopt affects when we do the Connection Authentication checks.
• It will be the default in a future version of MQ!
Authority Records
Connection
Authentication
Channel Authentication
Records (BLOCKADDR)
Transport Layer Security
Security exits
Channel Authentication
Records (***MAP)
Channel Authentication
Records (BLOCKUSER)

18. Step-by-step Case study
T.Rob Wyatt
20 3/30/2017

19. 21 3/30/2017
Applying MQ Security Controls
Stick to a process.
Here’s one you can start with.
1. Data classification exercise determines level
of security required.
2. Written requirements for security objectives.
3. Identify security roles.
4. Determine whether principal mapping is
required.
5. Determine what type of authentication will be
used.
6. Define IDs/groups to support the required
roles.
7. Implement policies as CHLAUTH and
AUTHREC rules, SSLPEER, etc.
8. Implement specified authentication.
9. Validate for positive and negative results.
10.Lather, rinse, repeat. Security is an ongoing
discipline, not a 1-time implementation.

20. 22 3/30/2017
Data classification exercise
Many companies have several levels of data
classification.
Examples:
• Public
• Proprietary
• Confidential
• Secret
• Regulatory compliance
The data classification will determine the level of
protection required and inform decisions in the
design of the security model.
Examples:
• Strong or weak authentication?
• Data privacy (encryption)?
• Data integrity?
• Ingress and egress controls?
• Audit and forensic capability?

21. 23 3/30/2017
Written requirements for security objectives
Decide in advance what the requirements of the
security design are and the threats that are to be
addressed.
For example, you often hear a requirement for
“encryption at rest.” There are several possible
solutions:
How Threat mitigated Threat not mitigated
Encrypted file system Someone steals the disk Data egress in logs, dumps, etc.
In-memory compromise
MQ API renders to plaintext
OS disk I/O renders to plaintext
[Other unspecified]
API exits Someone steals the disk
OS disk I/O
Data egress in logs, dumps, etc.
In-memory compromise
No protection in memory, logs, dumps, etc.
MQ API renders to plaintext
[Other unspecified]
MQ AMS Someone steals the disk
Data egress in logs, dumps, etc.
In-memory compromise
OS disk I/O
MQ API
[Other unspecified]

22. 24 3/30/2017
Written requirements for security objectives
Security objectives address different risks at
different points in the lifecycle:
• Intrusion prevention
• Intrusion detection
• Integrity validation
• Incident response and recovery
• Audit and forensic analysis
Lots of focus here
Less so here
Even less
Waiting to be noticed
Gave up hope
A good technique for driving out objectives is to play “what if?” As in “What if…”
• …there was a breach. Would we detect it while it was happening? Which security controls enable that?
• …we detect it late? Have we preserved evidence to allow tracing back a week? A month?
• …we need audit proof that the running system matches spec and has not been changed and restored?
• …we are asked to reconcile defined objects to business requirements?

23. 25 3/30/2017
Identify security roles
Consider the case of a queue manager hosting
multiple applications. Different applications will
require access to different sets of objects.
Each distinct set of objects and access
permissions is a security role.
Make an inventory of security roles required.
Don’t forget the non-user, non-app roles.
Examples:
• Administrator
• Anonymous inquiry of system state
• Anonymous read of data
• Application A
• Application B
• Instrumentation
• Backup
• Monitoring

24. 26 3/30/2017
Determine whether principal mapping is required
Principal mapping is for example “I sign on as
T.Rob but the channel runs as the mqm ID.”
• Often required when no admins are allowed in
the mqm group.
• Can be used for app support personnel to
adopt app credentials.
• Used for Ops team firecall IDs.
• Can be used to map password-enabled login
to non-login service account.
The inventory from the previous step should now
contain…
• All the defined roles.
• The service accounts and groups
representing those roles.
• All the user IDs that map to the roles, if
mapping is required.

25. 27 3/30/2017
Determine what type of authentication will be used
Before authorization can occur, it is necessary to
be able to trust the identity that has been
presented.
The process of establishing that trust is
authentication.
MQ offers varieties of weak and strong
encryption:
• IP/Address filtering (weak)
• User ID filtering (weak)
• Certificate (strong)
• Password (strong)
Some notes:
• Filtering is not appropriate as a stand-alone
control for update operations. May be
appropriate for anonymous inquiry.
• Use of certificate authentication requires the
client to be configured to send a cert in all
cases. Great for service accounts.
• Password authentication is strongest and best
for interactive users. Not great for service
accounts.
• Password authentication (a.k.a. CONNAUTH)
works differently across different versions and
Fix Packs.
USE CONNAUTH WITH CAUTION.

26. 28 3/30/2017
Define IDs/groups to support the required roles
Connections are always based on user IDs
(a.k.a. principals), so these are needed in all
cases.
Access control lists (ACLs) can attach to user
IDs or groups.
Recommendation generally is to attach ACLs to
groups, then enroll IDs to groups. This scales
well and supports separation of duties.
Even service accounts generally get a dedicated
group because if you put different ones in the
same group and someone hangs ACLs off the
group it’s not good. Bad, actually.
Guidelines
• Every security role requires at least one ID
and (hopefully) a group.
• Typically multiple interactive IDs in groups.
• Typically service accounts in dedicated
eponymous groups. These are called “private
groups” in UNIX/Linux terms.
• Follow security principle of Least Privilege
Access in which entities are authorized for the
absolute minimum of permissions required to
perform their functions.

27. 29 3/30/2017
Implement policies
Many controls available.
Each has a specific purpose.
Understand the interactions between them!
The security model is composed of the entire set
of controls to be implemented and the
configurations for each.
Typically, different security models for…
• QMgr-to-QMgr connections
• App-to-QMgr connections
• Interactive user connections
• Instrumentation and monitoring
Controls available include:
• CHLAUTH
• AUTHREC
• CONNAUTH
• CONNAUTH Early Adoption
• SSLPEER
• CRL revocation checking
• OCSP revocation checking

28. 30 3/30/2017
Implement specified authentication
At some point you will need to implement all of
the controls and configure them.
TEST! TEST! TEST!
Did I mention you should test this thoroughly
before implementation?
• VirtualBox is your friend.
• MQ Advanced for Developers is your friend.
• Red Hat Enterprise Server for Developers…
is your friend!
There is now NO license impediment to an MQ
sandbox on the MQ Admin desktop. Local shop
desktop lockdown policies and new app vetting
and packaging lead times are the primary
impediment now.
https://youtu.be/xX6hSGVZ8ds

29. 31 3/30/2017
Validate for positive and negative results
The toughest part is getting the validation right.
Over-authorization fails silently. NOBODY will
scream at you if they get too much access.
• Dishonest users won’t tell.
• Honest users won’t try to exceed their limits
and won’t know.
• Honest users who find out accidentally often
afraid that reporting it will make waves.
Have over the years discovered multiple shops
inadvertently authorizing +all to all QMgrs and
objects to ‘staff’ without discovering it.
Guidelines:
1. Define automated tests for each security
requirement.
2. Make sure these include negative tests
(access fails as expected) as well as positive
tests (access works as expected).
3. You will appreciate at this stage having used
the fewest possible controls and simplest
model that meets the requirements.
4. Automate the tests and run them periodically
to ensure the “as implemented” reconciles to
“as-specified.”

30. 32 3/30/2017
Lather, rinse, repeat
Unaddressed security issues represent unknown
latent risk.
These accumulate over time, even to the point of
becoming “extinction-level” risks.
(Digi-Notar ring a bell?)
The single biggest source of risk I see in my
work, in terms of magnitude and ubiquity, is the
practice of treating security as a 1-time
implementation.
• Security is an ongoing discipline, not an
implementation event.
• There’s a lot more to it than intrusion
prevention.
• The skillset is hierarchical. Many concepts
require mastery of pre-req skills.
• The controls interact. You are building an
assurance framework and need to be able to
identify how each element contributes to the
assurance and how that degrades when the
element fails.
• The framework degrades over time if left
unattended.
The most relentless, most devastating cyber-attack is simply to wait patiently.

31. Useful links
33 3/30/2017

32. InterConnect
2017
Messaging Sessions at a Glance
34
Monday
1:00-1:45pm 6880 IBM MQ Appliance: Messaging in a Box
6894 Messaging APIs
1:30-2:00pm IBM MQ on Containers: Demo, Open Lab area
2:00-2:45pm 6879 IBM MQ Advanced
3:15-4:00pm 6882 What’s New in the World of IBM MQ
4:15-5:00pm 3559 Banrisul Bank’s Migration to the MQ Appliance
6904 Help Shape the Future of IBM MQ
6:00-6:20pm 7441 IBM MQ in the Cloud
Tuesday
11:30-12:15pm 1487 IBM MQ Versus Open Source Messaging
6905 Help Shape the Future of IBM Message Hub
IBM MQ on Containers: Demo, Open Lab area
1:30-2:15pm 1183 IBM MQ Appliance: Best Practices from the Field
2:30-3:15pm 6881 Unlock the data flowing through the infrastructure
3:45-4:30pm 4555 Allstate’s Experience with the MQ Appliance
4:15-4:35pm 7440 Managed Event Streams
4:45-5:30pm 5214 Managing Loyalty Programs with IBM MQ
6895 IBM MQ for z/OS: The Latest and Greatest
Wednesday
8:00-8:45am 2699 IBM MQ for z/OS: Performance Tuning
6885 Deploying IBM MQ into the Cloud
6906A IBM MQ Appliance: Hands-on Lab (8:00-9-45)
10:15-12:00pm 6907 IBM MQ Hybrid Cloud: Hands-on Lab
6908 Message Hub and Apache Spark: Hands-on Lab
11:15-12:00pm 6884 Designing MQ for the Cloud Generation
6904 Help Shape the Future of IBM MQ
1:00-1:45pm 6903 Share your Experiences with the IBM MQ Experts
6883 IBM Message Hub: Cloud Native MQ Messaging
2:00-2:45pm 3695 How Banco Bradesco Manages IBM MQ for z/OS
3:15-4:00pm 6892 Availability and Scalability with MQ Clusters
4:15-5:00pm 6891 Making MQ Resilient across DCs and the Cloud
6893 Keep Out the Bad Guys by Securing MQ
Thursday
8:30-9:15am 6886 Simple, Resilient Messaging with MQ Appliance
9:30-10:15am 6878 You Need MQ Messaging!
6887 Managing MQ Messaging in the Hybrid Cloud
6890 New Tools and Interfaces to Manage IBM MQ
10:30-11:15am 6889 Help! Has Anyone seen my MQ Message?
6906B IBM MQ Appliance: Hands-on Lab (10:30-12:15)
Find us in the EXPO: Hybrid Integration Booth, Messaging Ped
Wednesday
4:15-5:00pm 6891 Making MQ Resilient across DCs and the Cloud
6893 Keep Out the Bad Guys by Securing MQ

33. 35 3/30/2017
Useful Links
Rob’s section
• MQ Explorer Bug (CVE-2015-1967)
• CONNAUTH & CHLAUTH interactions
• Early Adopt APAR IT12825
• MQ Developer works blog
T.Rob’s Section
• Secure by Design: Taking the next steps in
application security
• Security in Development: The IBM Secure
Engineering Framework
• The Deep Queue: MQ and MQ Security blog
• T.Rob’s MQ Security You Tube tutorials
• MQ on Stack Overflow [tag] [info]

34. InterConnect
2017
Thank you
IBM Messaging Developer Centre
developer.ibm.com/messaging
IBM Messaging Youtube
www.youtube.com/IBMmessagingMedia
LinkedIn
ibm.biz/ibmmessaging
Twitter
@IBMmessaging
IBM MQ Facebook
facebook.com/IBMMQ

35. 37 3/30/2017
Notices and disclaimers
Copyright © 2017 by International Business Machines Corporation (IBM).
No part of this document may be reproduced or transmitted in any form
without written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to
products that have not yet been announced by IBM) has been reviewed
for accuracy as of the date of initial publication and could include
unintentional technical or typographical errors. IBM shall have no
responsibility to update this information. This document is distributed
“as is” without any warranty, either express or implied. In no event
shall IBM be liable for any damage arising from the use of this
information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and
services are warranted according to the terms and conditions of the
agreements under which they are provided.
IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been previously
installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or product
plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a
controlled, isolated environments. Customer examples are presented
as illustrations of how those customers have used IBM products and
the results they may have achieved. Actual performance, cost, savings or
other results in other operating environments may vary.
References in this document to IBM products, programs, or services
does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does
business.
Workshops, sessions and associated materials may have been prepared
by independent session speakers, and do not necessarily reflect the
views of IBM. All materials and discussions are provided for informational
purposes only, and are neither intended to, nor shall constitute legal or
other guidance or advice to any individual participant or their specific
situation.
It is the customer’s responsibility to insure its own compliance with legal
requirements and to obtain advice of competent legal counsel as to
the identification and interpretation of any relevant laws and regulatory
requirements that may affect the customer’s business and any actions
the customer may need to take to comply with such laws. IBM does not
provide legal advice or represent or warrant that its services or products
will ensure that the customer is in compliance with any law.

36. 38 3/30/2017
Notices and disclaimers
continued
Information concerning non-IBM products was obtained from the
suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products in
connection with this publication and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not warrant the
quality of any third-party products, or the ability of any such third-party
products to interoperate with IBM’s products. IBM expressly disclaims
all warranties, expressed or implied, including but not limited to, the
implied warranties of merchantability and fitness for a particular,
purpose.
The provision of the information contained herein is not intended to, and
does not, grant any right or license under any IBM patents, copyrights,
trademarks or other intellectual property right.
IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS,
Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document
Management System™, FASP®, FileNet®, Global Business Services®,
Global Technology Services®, IBM ExperienceOne™, IBM SmartCloud®,
IBM Social Business®, Information on Demand, ILOG, Maximo®,
MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower,
PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®,
PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®,
PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®,
SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli® Trusteer®,
Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and
System z® Z/OS, are trademarks of International Business Machines
Corporation, registered in many jurisdictions worldwide. Other product
and service names might be trademarks of IBM or other companies. A
current list of IBM trademarks is available on the Web at "Copyright and
trademark information" at: www.ibm.com/legal/copytrade.shtml.