When working with MQ day to day supporting various flavors of IBM MQ users, the question arises; Security, so what?
One of the key things to remember as MQ administrator is that we need to be on our toes all the time and that the intruder/hacker have all the time and only need to be lucky once to make the catastrophe, so we should expect to see the auditors now and then.
When we're lucky we might see an Auditor, asking in-depth questions about the MQ installation.
How often have you as MQ Professional been asked: Is your IBM MQ infrastructure secure?
Many times the answer is: Yes. And the auditor is happy. And signs a clean sheet report.
Another message from MQ administrators is; if the right security is in place, it is too hard and costly to maintain and validate the security.
Security is not a thing or a product that can be bought and installed, it is a continuous process at the heart of the business itself.
There are many layers of security flavors to consider when dealing with IBM MQ Security:
- Is there a MQ Security standard?
- Is the MQ infrastructure vital for the business?
- Is Security disabled?
- Is CHLAUTH enabled?
- Is CONNAUTH enabled (MQ v8)?
- Is the environmets securely separated?
- Is privileged users prompted for authentication (MQ v8)?
- Is sensitive data like credit card info, Social Security number, etc. encrypted?
- Is the IBM MQ Infrastructure live monitored?
- Is the level of availability of Hardware (SLA), CPUs, DASD, Network, power correct?
- Is hardware and software current, so the company can get vendor support in case of problems?
- Is the IBM MQ software regular patched?
- Is the IBM MQ Infrastructure regular backed up, and is the backup/restore tested?
- Are the logs and error files kept for problem determination/intrusion investigations?
- Can there be sensitive IBM MQ data in Queue Managers in DMZ queue managers?
- Are there regulatory requirements like PCI-DSS you shall fulfill?
- Is external communication secured using TLS certificates?
- Is the TLS keystore secured according to best practices (also for MQ Client applications)?
- How many Queue Managers is there in your MQ network?
- Is IBM MQ queue manager internet facing?
- How many external connections are there in the MQ systems?
- Does MQ Clustering include external partners?
- Has MQ Security been tested/reviewed?
- Has a Security assesment been done?
- Have auditors requested a explecit display of the profiles(z/OS)?
- How many have adminstrative access to your IBM MQ infrastructure?
- Is your internet facing IBM MQ infrastructure DoS resilient?
- Is the same certificate installed on multiple queue managers?
Did Auditors check or ask questions about some of the topics above? My experience from 20 years with WebSphere MQ now IBM MQ: Yes, but just one or two times....
Is Channel Authentication (CHLAUTH) enabled?
It's strongly recomended that CHLAUTH always is enabled to help secure your MQ environment against entrusion.
Check if CHLAUTH has been disabled:
You can also check the value by issueing this command using runmqsc to see it:
DIS QMGR CHLAUTH
C:\Windows\system32>runmqsc MRMQDK81 |
The following 3 CHLAUTH is created by default when a new queue manager is created (with MQ version 7.1+):
They serve three purposes, prevent administrative access, block the SYSTEM.* channels and open for access to channel SYSTEM.ADMIN.SVRCONN.
Collection of goodies regarding: CHLAUTH - Secure MQ connections
Is Security disabled?
Did the security adminstrator define qmgr.NO.SUBSYS.SECURITY or qsg-name.NO.SUBSYS.SECURITY in MQADMIN class on z/OS to elimenate the CSQH024I message:
CSQH024I %CSQ1 CSQHINSQ SUBSYSTEM security switch set
ON, profile 'CSQ1.NO.SUBSYS.SECURITY' not found
Sometimes this happens as part a upgrade of z/OS or other parts. This should be monitored.
IBM MQ tell you when security is switch off:
CSQH021I %CSQ2 CSQHINSQ SUBSYSTEM security switch set
OFF, profile 'CSQ2.NO.SUBSYS.SECURITY' found
Now you have a problem!
This article on getting security back on z/OS might help you get back in control: Security: a userid is checked when it should not be or is not checked when it should
Is CONNAUTH enabled?
This is for MQ version 8.0 and newer.
Connection authority (CONNAUTH) is used for controlling authentication requirements, it is recomented to authenticate any user who try to access production systems. The requirements can vary depending on company policies, some have a strong need other not.
The easy way to see if CONNAUTH has been disables is to look on the CONNAUTH attribute of the queue manager:
DIS QMGR CONNAUTH
|
C:\Windows\system32>echo display qmgr connauth| runmqsc MRMQDK80 5724-H72 (C) Copyright IBM Corp. 1994, 2014. Starting MQSC for queue manager MRMQDK80.
1 : display qmgr connauth AMQ8408: Display Queue Manager details. QMNAME(MRMQDK80) CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.
C:\Windows\system32> |
In this case; CONNAUTH is enabled and authenticate against the operating system.
Then we need to see what type of checking that is active:
|
C:\Windows\system32>runmqsc MRMQDK80 5724-H72 (C) Copyright IBM Corp. 1994, 2014. Starting MQSC for queue manager MRMQDK80.
dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) all 5 : dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) all AMQ8566: Display authentication information details. AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) ADOPTCTX(YES) DESCR( ) CHCKCLNT(NONE) CHCKLOCL(NONE) FAILDLAY(1) ALTDATE(2015-10-17) ALTTIME(11.40.19) |
This shows us that checking is switched off!
A great article on the subject from IBM : Getting going without turning off MQ Security
Article on various z/OS MQ security switch profiles: Analyzing MQ security with zSecure 2.1.1
Is the Environmets securely separated?
Has the environments been separated:
- differnt networks
- different intermediate, root certificates
- different domains
- no crossing connections
By enforcing separation using the options above you will be pretty sure that you can prevent mixing the environments and assure that simple configuration mistakes can jepadise your environments and sending testdata into production and visa versa.
By using the same intermediate and root certificates in test and production, you will rely on CHLAUTH and SSLPEER to assure mixing the environments. If you use different intermediate, root certificates you prevent TLS connections. This also cover external connections.
If you are using for example Symantec certificate you can use different type for test and production environments. You will ofcause use the most secure certificates in your production environemt.
Is the same certificate installed on multiple queue managers?
A TLS certificate is similar to a Passport, and you can normally have only one Passport, and therefore only use it in one place¹.
When using the same certificate in multiple servers we're missing the ability to assure we're connected to the right queue manager, we cannot use SSLPEER to assure it as they are presenting the same certificate.
¹) There are nothing that prevent using a certificate on multiple servers. Queue Sharing Groups (QSG) on z/OS can share same certificate with a good reason because the QSG name represents one queue manager.
Have auditors requested a explecit display of the profiles(z/OS)?
Have you as Auditor requested the following displays from z/OS Security specialists:
RL MQADMIN <mqsubsys>.RESLEVEL
and check the accesses to the profile covering MQADMIN <mqsubsys>.RESLEVEL?
By not understanding or not monitoring the access to this profile, bad configuration can lead to disabling security. Meaning that anyone can do anything to a queue manager including administration, deletion and inserting messages.
From IBM RedBooks "Secure Messaging Scenarios with WebSphere MQ" page 78.
|
7.1.8 RESLEVEL security Define an hlq.RESLEVEL profile and set the UACC to NONE, rather than have no RESLEVEL profile at all. Have as few users or groups in the access list as possible. For further details, see the WebSphere MQ Information Center: |
The full IBM Redbooks is available here: http://www.redbooks.ibm.com/abstracts/sg248069.html
To be continued with comments and descriptions on the topics above.