1 05/02/2023

InterConnect2017

6893 - Keep Out the Bad Guys by Securing Your MQ Messaging Environment

Robert Parker, IBMT.Rob Wyatt, IoPT Consulting

2 05/02/2023

Please noteIBM’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 inthe 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 05/02/2023

Agenda• Introduction

• MQ Security Features

• Authentication• Authorization• Confidentiality

• Step-by-step case Study

• Useful Links

• Questions

4 05/02/2023

Robert ParkerIBM MQ Development

T.Rob WyattIoPT Consulting

Introduction

5 05/02/2023

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 05/02/2023

Rob ParkerSecurity Features

8 05/02/2023

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”.

9 05/02/2023

Authentication Features – Connection Authentication

Connection authentication changed between releases:

Initial Release

8.0.0.0LDAP

Authorization (UNIX/IBM i)

8.0.0.21. PAM

Integration2. Explorer fix

8.0.0.3

Early Adopt Fix

8.0.0.5

LDAP Authorization

(Windows)

9.0.0.0All before

9.0.1.0

10 05/02/2023

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)

11 05/02/2023

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.

12 05/02/2023

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)

13 05/02/2023

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.

14 05/02/2023

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

15 05/02/2023

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.

16 05/02/2023

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.

18 05/02/2023

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)

19 05/02/2023

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)

20 05/02/2023

Step-by-step Case studyT.Rob Wyatt

21 05/02/2023

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.

22 05/02/2023

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?

23 05/02/2023

Written requirements for security objectivesDecide 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 compromiseMQ API renders to plaintextOS disk I/O renders to plaintext[Other unspecified]

API exits Someone steals the diskOS disk I/O

Data egress in logs, dumps, etc.In-memory compromiseNo protection in memory, logs, dumps, etc.MQ API renders to plaintext[Other unspecified]

MQ AMS Someone steals the diskData egress in logs, dumps, etc.In-memory compromiseOS disk I/OMQ API

[Other unspecified]

24 05/02/2023

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?

25 05/02/2023

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

26 05/02/2023

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.

27 05/02/2023

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.

28 05/02/2023

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.

29 05/02/2023

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

30 05/02/2023

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

31 05/02/2023

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.”

32 05/02/2023

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.

33 05/02/2023

Useful links

34

InterConnect2017

Messaging Sessions at a GlanceMonday

1:00-1:45pm 6880 IBM MQ Appliance: Messaging in a Box6894 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 Appliance6904 Help Shape the Future of IBM MQ

6:00-6:20pm 7441 IBM MQ in the Cloud

Tuesday11:30-12:15pm 1487 IBM MQ Versus Open Source Messaging

6905 Help Shape the Future of IBM Message HubIBM 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 MQ6895 IBM MQ for z/OS: The Latest and Greatest

Wednesday8:00-8:45am 2699 IBM MQ for z/OS: Performance Tuning

6885 Deploying IBM MQ into the Cloud6906A IBM MQ Appliance: Hands-on Lab (8:00-9-45)

10:15-12:00pm 6907 IBM MQ Hybrid Cloud: Hands-on Lab6908 Message Hub and Apache Spark: Hands-on Lab

11:15-12:00pm 6884 Designing MQ for the Cloud Generation6904 Help Shape the Future of IBM MQ

1:00-1:45pm 6903 Share your Experiences with the IBM MQ Experts6883 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 Cloud6893 Keep Out the Bad Guys by Securing MQ

Thursday8: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 Cloud6890 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 Cloud6893 Keep Out the Bad Guys by Securing MQ

35 05/02/2023

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]

InterConnect2017

Thank you

IBM Messaging Developer Centredeveloper.ibm.com/messaging

IBM Messaging Youtubewww.youtube.com/IBMmessagingMedia

LinkedIn ibm.biz/ibmmessaging Twitter@IBMmessagingIBM MQ Facebookfacebook.com/IBMMQ

37 05/02/2023

Notices and disclaimersCopyright © 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.

38 05/02/2023

Notices and disclaimers continuedInformation 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.