{"stig":{"title":"IBM MQ Appliance V9.0 AS Security Technical Implementation Guide","version":"1","release":"2"},"checks":[{"vulnId":"V-255775","ruleId":"SV-255775r960864_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must protect against an individual (or process acting on behalf of an individual) falsely denying having performed organization-defined actions to be covered by non-repudiation.","description":"Non-repudiation of actions taken is required in order to messaging service application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. \n\nNon-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. \n\nTypical messaging server actions requiring non-repudiation will be related to application deployment among developers/users and administrative actions taken by admin personnel.","checkContent":"Establish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nTo run the \"runmqsc [queue mgr name]\" command for each running queue manager enter:\nDIS QMGR EVENT\n\nA list of all events will be displayed along with an indication if event logging is enabled. The events are as follows:\n\nAuthority: AUTHOREV, Inhibit: INHIBITEV, Local: LOCALEV, Remote: REMOTEEV, Start and stop: STRSTPEV, Performance: PERFMEV, Command: CMDEV, Channel: CHLEV, Channel auto definition: CHADEV, SSL: SSLEV, Configuration: CONFIGEV\n\nIf AUTHOREV event logging is not enabled, this is a finding.","fixText":"To access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [queue mgr name]\nALTER QMGR [AUTHOREV](ENABLED)\n\nTo exit the MQ Appliance CLI, enter:\nend","ccis":["CCI-000166"]},{"vulnId":"V-255776","ruleId":"SV-255776r960762_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must implement cryptography mechanisms to protect the integrity of the remote access session.","description":"Encryption is critical for protection of remote access sessions. If encryption is not being used for integrity, malicious users may gain the ability to modify the messaging server configuration. The use of cryptography for ensuring integrity of remote access sessions mitigates that risk.\n\nMessaging servers utilize a web management interface and scripted commands when allowing remote access. Web access requires the use of TLS and scripted access requires using ssh or some other form of approved cryptography. Messaging servers must have a capability to enable a secure remote admin capability.\n\nFIPS 140-2 approved TLS versions include TLS V1.0 or greater.\n\nFIPS 140-2 approved TLS versions must be enabled and non-FIPS-approved SSL versions must be disabled.\n\nNIST SP 800-52 specifies the preferred configurations for government systems.\n\nSatisfies: SRG-APP-000015-AS-000010, SRG-APP-000126-AS-000085, SRG-APP-000231-AS-000133, SRG-APP-000231-AS-000156, SRG-APP-000428-AS-000265, SRG-APP-000429-AS-000157, SRG-APP-000441-AS-000258, SRG-APP-000442-AS-000259","checkContent":"Obtain queue security policy requirements from system admin.\n\nTo verify the Advanced Message Security (AMS) policy for a specific queue manager's queues, enter: \nmqcli\n\nTo list the policies for each queue, enter:\nrunmqsc [QMgrName]\n\nTo display all policies, enter:\nDIS POLICY(*)  \n\nIf no security policies are found or the specifics of the security policy does not meet documented queue security requirements, this is a finding.","fixText":"Advanced Message Security can sign and encrypt messages at the point of production, and then decrypt and authenticate them at the point of consumption. At all points in between, the message is protected, either for integrity (using hashing) or for privacy (using encryption).  Steps for setting up AMS are not included here.  Reference vendor documentation for guidance on setting up AMS.\n \nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [QMgrName]\n\nSET POLICY([queue name]) SIGNALG([SHA256, SHA384, or SHA512]) +\nENCALG([3DES, AES128, or AES256]) +\nRECIP(['distinguished name (DN) of the message recipient']) +\nSIGNER(['Signature DN validated during message retrieval'])\nend","ccis":["CCI-001199","CCI-001350","CCI-001453","CCI-002420","CCI-002422","CCI-002475","CCI-002476"]},{"vulnId":"V-255777","ruleId":"SV-255777r961395_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must off-load log records onto a different system or media from the system being logged.","description":"Information system logging capability is critical for accurate forensic analysis. Log record content that may be necessary to satisfy the requirement of this control includes, but is not limited to, time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application-specific events, success/fail indications, filenames involved, access control or flow control rules invoked.\n\nOff-loading is a common process in information systems with limited log storage capacity.\n\nCentralized management of log records provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Messaging servers and their related components are required to off-load log records onto a different system or media than the system being logged.\n\nAn HA configuration provides real-time synchronous replication of the logs to a mirrored MQ Appliance.","checkContent":"Review system categorization to determine if redundancy is a requirement. If system categorization does not specify redundancy, interview system administrator to determine how they have configured the MQ appliance to off-load log files onto a different system.  \n\nPerform on each member of the HA pair.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\ndspmq -s -o ha\n\nOne of the appliances should be running as primary, the other as secondary.\n\nIf HA is not configured with the primary and secondary running, or if there is no mechanism implemented to off-load log records, this is a finding.","fixText":"To configure HA:\n1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3.\n2. Configure the three connected MQ Appliance ports (on both appliances) as follows:\n\nInterface  Purpose                                              IP address/CIDR\neth1           HA group primary interface           x.x.x.x/24\neth2           HA group alternative interface     x.x.x.x/24\neth3           HA Replication interface                x.x.x.x/24\n\nOn the second appliance, enter the following command from the MQ Appliance CLI:\nprepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout]\n\nOn the first appliance, enter the following command from the MQ Appliance CLI:\ncrthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance]\ncrtmqm [HA QM name] –p [port] –sx\n\nNote: The queue manager’s data (queues, queue messages, etc.) is replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).","ccis":["CCI-001851"]},{"vulnId":"V-255778","ruleId":"SV-255778r981686_rule","severity":"low","ruleTitle":"The MQ Appliance messaging server must synchronize internal MQ Appliance messaging server clocks to an authoritative time source when the time difference is greater than the organization-defined time period.","description":"Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events.\n\nSynchronization of internal messaging server clocks is needed in order to correctly correlate the timing of events that occur across multiple systems. To meet this requirement, the organization will define an authoritative time source and have each system synchronize when the time difference is greater than a defined time period.  The industry standard for the threshold is 1ms.","checkContent":"Log on as a privileged user to the WebGUI.\nSelect Network icon. \nInterface NTP Service.\nVerify that refresh interval is set to \"600\" seconds.\n\nIf refresh interval is not set to \"600\" seconds, this is a finding.","fixText":"Log on as a privileged user to the WebGUI.\nSelect the  Network icon.\nInterface NTP Service.\n\nSet refresh interval to \"600\" seconds.\n\nClick \"Save configuration\".","ccis":["CCI-002046"]},{"vulnId":"V-255779","ruleId":"SV-255779r981685_rule","severity":"low","ruleTitle":"The MQ Appliance messaging server must compare internal MQ Appliance messaging server clocks at least every 24 hours with an authoritative time source.","description":"Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events.\n\nSynchronization of system clocks is needed in order to correctly correlate the timing of events that occur across multiple systems. To meet this requirement, the organization will define an authoritative time source and have each system compare its internal clock at least every 24 hours.","checkContent":"Log on as a privileged user to the WebGUI.\nSelect Network icon.\nInterface NTP Service.\n\nVerify: \n- NTP server destinations are configured.\n- \"Enable Administrative state\" box is checked.\n\nIf \"Enable Administrative state\" is not checked or if no NTP servers are defined, this is a finding.","fixText":"Log on as a privileged user to the WebGUI.\nSelect the  Network icon.\nInterface NTP Service.\n\nEnsure the box next to \"Enable Administrative state\" has a check mark.\nPress the \"Add\" button to add multiple NTP servers.\nClick the \"Apply\" button.\n\nAdd one or more additional NTP servers at least one of which is from a different geographic region.\n\nClick \"Save configuration\".","ccis":["CCI-001891"]},{"vulnId":"V-255780","ruleId":"SV-255780r962034_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.","description":"Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data.\n\nNSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as:\n\n\"Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed. Developed using established NSA business processes and containing NSA-approved algorithms are used to protect systems requiring the most stringent protection mechanisms.\" \n\nNSA-approved cryptography is required to be used for classified information system processing.\n\nThe messaging server must utilize NSA-approved encryption modules when protecting classified data. This means using AES and other approved encryption modules.","checkContent":"Check that TLS mutual authentication has been completed successfully by using DISPLAY commands. If the task was successful, the resulting output is like that shown in the following examples.\n\nFor queue manager to queue manager connections:\n\nFrom queue manager [QM1], enter the following command:\n\nDISPLAY CHS(TO.[QM2]) SSLPEER SSLCERTI\n\nThe resulting output should be like the following example:\n\nDISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI\n4 : DISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI\nAMQ8417: Display Channel Status details.\nCHANNEL(TO.[QM2])             CHLTYPE(SDR)\nCONNAME([IP addr QM2])           CURRENT\nRQMNAME([QM2])\nSSLCERTI(\"[distinguished name]\")\nSSLPEER(\"[distinguished name]\")\nSTATUS(RUNNING)             SUBSTATE(MQGET)\nXMITQ([QM2])\n\nFrom the queue manager [QM2], enter the following command:\n\nDISPLAY CHS(TO.QM2) SSLPEER SSLCERTI\n\nThe resulting output is like the following example:\n\nDISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI\n5 : DISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI\nAMQ8417: Display Channel Status details.\nCHANNEL(TO.[QM2])             CHLTYPE(SDR)\nCONNAME([IP addr QM1])           CURRENT\nRQMNAME([QM1])\nSSLCERTI(\"[distinguished name]\")\nSSLPEER(\"[distinguished name]\")\nSTATUS(RUNNING)             SUBSTATE(MQGET)\nXMITQ( )\n\nIn each case, the value of \"SSLPEER\" must match that of the Distinguished Name (DN) in the partner certificate. The issuer name must match the subject DN of the CA certificate that signed the personal certificate.\n\nFor client to queue manager connections:\n\nC1=client1, QM1=queue manager 1\n\nFrom the queue manager [QM1], enter the following command:\n\nDISPLAY CHSTATUS([C1].TO.[QM1]) SSLPEER SSLCERTI\n\nThe resulting output is like the following example:\n\nDISPLAY CHSTATUS([C1].TO.[QM1]) SSLPEER SSLCERTI\n5 : DISPLAY CHSTATUS([C1].TO.[QM1]) SSLPEER SSLCERTI\nAMQ8417: Display Channel Status details.\nCHANNEL([C1].TO.[QM1])           CHLTYPE(SVRCONN)\nCONNAME([IP addr QM1])           CURRENT\nSSLCERTI(\"[distinguished name]\")\nSSLPEER(\"[distinguished name]\")\nSTATUS(RUNNING)             SUBSTATE(RECEIVE)\n\nThe \"SSLPEER\" field in the \"DISPLAY CHSTATUS\" output shows the subject DN of the remote client certificate. The issuer name matches the subject DN of the CA certificate that signed the personal certificate.\n\nIf the connections on each end of the channel are not configured as described above, this is a finding.","fixText":"Devices (endpoints) may connect an MQ Appliance MQ queue manager as either remote MQ queue manager or MQ client. In order to ensure unique identification of network-connected devices, mutual authentication using CA-signed TLS certificates should be configured. \n\n1. Prepare the key repository on each endpoint (client and/or queue manager).\n2. Request a CA-signed certificate for each client and/or queue manager. You might use different CAs for the two endpoints.\n3. Add the Certificate Authority certificate to the key repository for each client and/or queue manager. If the endpoints are using different Certificate Authorities then the CA certificate for each Certificate Authority must be added to both key repositories.\n4. Add the CA-signed certificate to the key repository for each endpoint.\n\nCHOOSE EITHER STEP 5 or 6 BELOW\n\n5. For a queue manager to queue manager connection:\na. On [QM1], define a sender channel and associated transmission queue by issuing commands like the following example:\nDEFINE QLOCAL([QM2]) USAGE(XMITQ)\nDEFINE CHANNEL(TO.[QM2]) CHLTYPE(SDR) TRPTYPE(TCP) +\nCONNAME([QM2 address]) XMITQ([QM2]) SSLCIPH([TLS cipher spec]) +\nDESCR('Sender channel using TLS from [QM1] to [QM2]')\nThe CipherSpecs at each end of the channel must be the same.\n\nb. On [QM2], define a receiver channel by issuing a command like the following example:\nDEFINE CHANNEL(TO.[QM2]) CHLTYPE(RCVR) TRPTYPE(TCP) +\nSSLCIPH([TLS cipher spec]) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS to [QM2]')\nThe channel must have the same name as the sender channel you defined in step 5.a., and use the same CipherSpec.\n\nc. Start the channel.\nRef. Connecting two queue managers using SSL or TLS  https://goo.gl/1GyPRV\n\n6. For a client to queue manager connection:\na. Define a client-connection channel in either of the following ways:\n- Using the MQCONNX call with the MQSCO structure on [client]\n- Using a client channel definition table\n\nb. On queue manager, define a server-connection channel by issuing a command like the following example:\nC1=client 1, MQ1=queue manager 1\nDEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) +\nSSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS from [client name] to [QM name]')\n\nThe channel must have the same name as the client-connection channel you defined in step 6, and use the same CipherSpec.\n\nNote: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp","ccis":["CCI-002450"]},{"vulnId":"V-255781","ruleId":"SV-255781r961521_rule","severity":"medium","ruleTitle":"The MQ Appliance WebGUI interface to the messaging server must prohibit the use of cached authenticators after one hour.","description":"When the messaging server is using PKI authentication, a local revocation cache must be stored for instances when the revocation cannot be authenticated through the network, but if cached authentication information is out of date, the validity of the authentication information may be questionable.","checkContent":"Display the SSL Server Profile associated with the WebGUI using the (CLI).\n\nLog on as an admin to the MQ appliance using SSH terminal access.\n\nEnter:\nco\nshow web-mgmt\n\nTo note the name of the ssl-server, enter:\ncrypto\nssl-server <ssl-server name>\nshow\n\nVerify the following are displayed:\ncaching on\ncache-timeout 3600\n\nIf the ssl-server configuration does not exist, or if caching is \"off\", or if the cache-timeout setting does not equal “3600” seconds (60 minutes),  this is a finding.","fixText":"Display the SSL Server Profile associated with the WebGUI (CLI).\nEnter:\nco\nshow web-mgmt\n\n[Note the name of the ssl-server]\n\nDefine the cache parameters of the SSL Server using the CLI.\nEnter:\nco\ncrypto\nssl-server <ssl-server name>\ncaching on\ncache-timeout <3600>\nexit\nexit\nwrite mem\ny","ccis":["CCI-002007"]},{"vulnId":"V-255782","ruleId":"SV-255782r960891_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must produce log records containing information to establish what type of events occurred.","description":"Information system logging capability is critical for accurate forensic analysis. Without being able to establish what type of event occurred, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible. \n\nLog record content that may be necessary to satisfy the requirement of this control includes time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.\n\nMessaging servers must log all relevant log data that pertains to the messaging server. Examples of relevant data include, but are not limited to, Java Virtual Machine (JVM) activity, HTTPD/Web server activity, and messaging server-related system process activity.\n\nSatisfies: SRG-APP-000095-AS-000056, SRG-APP-000093-AS-000054, SRG-APP-000096-AS-000059, SRG-APP-000097-AS-000060, SRG-APP-000098-AS-000061, SRG-APP-000099-AS-000062, SRG-APP-000100-AS-000063, SRG-APP-000101-AS-000072","checkContent":"Apply the following check to each queue manager on the MQ Appliance.\n\nEstablish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nTo check config for each queue, enter:\nrunmqsc [queue mgr name]\n\nAt the runmqsc prompt, enter:\nDIS QMGR EVENT\n\nVerify the following events are enabled as required.\n\nAUTHOREV, INHIBITEV, STRSTPEV, CMDEV, SSLEV, CONFIGEV, PERFMEV\n\nIf any of the required events are not enabled, this is a finding.","fixText":"Ensure each queue is configured to log the following event names:\n\nAUTHOREV\nINHIBITEV\nSTRSTPEV\nCMDEV\nSSLEV\nCONFIGEV\nPERFMEV\n\nUse the \"runmqsc\" command for each queue manager.\n\nrunmqsc [queue mgr name]\nALTER QMGR [event name](ENABLED)\n\nEnter \"end\" to exit the MQ Appliance CLI.","ccis":["CCI-000130","CCI-000131","CCI-000132","CCI-000133","CCI-000134","CCI-000135","CCI-001462","CCI-001487"]},{"vulnId":"V-255783","ruleId":"SV-255783r961167_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must identify potentially security-relevant error conditions.","description":"The structure and content of error messages need to be carefully considered by the organization and development team. Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The extent to which the messaging server is able to identify and handle error conditions is guided by organizational policy and operational requirements. Adequate logging levels and system performance capabilities need to be balanced with data protection requirements.\n\nThe structure and content of error messages needs to be carefully considered by the organization and development team.\n\nMessaging servers must have the capability to log at various levels which can provide log entries for potential security-related error events.\n\nAn example is the capability for the messaging server to assign a criticality level to a failed logon attempt error message, a security-related error message being of a higher criticality.\n\nInstructions for using the amqsevt sample program to display instrumentation events may be found at the following URL: https://ibm.biz/BdsCzY.\n\nSatisfies: SRG-APP-000266-AS-000168, SRG-APP-000091-AS-000052","checkContent":"Establish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n  \nTo identify the queue managers, enter:\ndspmq\n\nRun the \"runmqsc [queue mgr name]\" command for each running queue manager.  \n\nOnce at the runmqsc prompt, enter:\n\nDIS QMGR AUTHOREV\nAUTHOREV(ENABLED) - should be the result.\n\nIf \"AUTHOREV\" logging is not \"ENABLED\", this is a finding.","fixText":"For each queue manager on the MQ Appliance, enable authority (AUTHOREV) event logging.\n\nFrom the MQ Appliance CLI, enter the following:\n\nrunmqsc [queue mgr name]\nALTER QMGR AUTHOREV(ENABLED)\nend","ccis":["CCI-000172","CCI-001312"]},{"vulnId":"V-255784","ruleId":"SV-255784r961362_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged.","description":"In order to be able to provide a forensic history of activity, the messaging server must ensure users who are granted a privileged role or those who utilize a separate distinct account when accessing privileged functions or data have their actions logged.\n\nIf privileged activity is not logged, no forensic logs can be used to establish accountability for privileged actions that occur on the system.\n\nInstructions for using the amqsevt sample program to display instrumentation events may be found at the following URL: https://ibm.biz/BdsCzY\n\nSatisfies: SRG-APP-000343-AS-000030, SRG-APP-000016-AS-000013, SRG-APP-000495-AS-000220, SRG-APP-000499-AS-000224, SRG-APP-000503-AS-000228, SRG-APP-000504-AS-000229, SRG-APP-000509-AS-000234","checkContent":"For each queue manager on the MQ Appliance for which configuration events logging should be enabled, establish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nTo run the \"runmqsc [queue mgr name]\" command for each running queue manager, enter:\nrunmqsc [queue mgr name]\nDIS QMGR CONFIGEV\nCONFIGEV(ENABLED) - should be the result.\nend\n\nIf \"CONFIGEV\" is not \"ENABLED\", this is a finding.","fixText":"For each queue manager on the MQ Appliance, enable configuration event logging (CONFIGEV).\n\nFrom the MQ Appliance CLI, enter the following:\n\nrunmqsc [queue mgr name]\nALTER QMGR CONFIGEV(ENABLED)\nend","ccis":["CCI-000067","CCI-000172","CCI-002234"]},{"vulnId":"V-255785","ruleId":"SV-255785r960912_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must alert the SA and ISSO, at a minimum, in the event of a log processing failure.","description":"Logs are essential to monitor the health of the system, investigate changes that occurred to the system, or investigate a security incident. When log processing fails, the events during the failure can be lost. To minimize the timeframe of the log failure, an alert needs to be sent to the SA and ISSO at a minimum.\n\nLog processing failures include, but are not limited to, failures in the messaging server log capturing mechanisms or log storage capacity being reached or exceeded. In some instances, it is preferred to send alarms to individuals rather than to an entire group. Messaging servers must be able to trigger an alarm and send an alert to, at a minimum, the SA and ISSO in the event there is a messaging server log processing failure.\n\nIt is the responsibility of the MQ system administrator to monitor the SYSTEM.ADMIN.PERFM.EVENT queue and provide appropriate notification. \n\nAll MQ installations provide a sample program, amqsevt. This program reads messages from event queues, and formats them into readable strings.\n\nAn event logging failure would be indicated by one of the following return codes: MQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, or MQRC_Q_DEPTH_HIGH\n\nNote: Any MQ monitoring solution that connects to MQ as a client may be used to monitor event queues.\n\nSatisfies: SRG-APP-000108-AS-000067, SRG-APP-000360-AS-000066","checkContent":"For each queue manager on the MQ Appliance for which performance events logging should be enabled, establish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nTo run the \"runmqsc [queue mgr name]\" command for each running queue manager identified, enter:\nrunmqsc [queue mgr name]\nDIS QMGR PERFMEV\nDIS QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV\nend\n\nIf \"QDPHIEV\" or \"PERFMEV\" is not \"ENABLED\", this is a finding.\n\nAsk the system administrator to demonstrate how they monitor an alert on MQ failure events.\n\nVerify alarming is set for the following log events:\nMQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH\n\nIf the system admin does not monitor an alarm for the following error codes: MQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, or MQRC_Q_DEPTH_HIGH, this is a finding.","fixText":"For each queue manager on the MQ Appliance, enable performance (PERFMEV) event logging.\n\nFrom the MQ Appliance CLI, enter the following:\n\nrunmqsc [queue mgr name]\nALTER QMGR PERFMEV(ENABLED)\nALTER QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV(ENABLED)\n\nMonitor the logs that send alerts based on the following failure codes: \nMQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH.","ccis":["CCI-000139","CCI-001858"]},{"vulnId":"V-255786","ruleId":"SV-255786r961398_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must provide an immediate warning to the SA and ISSO, at a minimum, when allocated log record storage volume reaches 75% of maximum log record storage capacity.","description":"It is critical for the appropriate personnel to be aware if a system is at risk of failing to process logs as required.  Log processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded.  Notification of the storage condition will allow administrators to take actions so that logs are not lost.  This requirement can be met by configuring the messaging server to utilize a dedicated logging tool that meets this requirement.","checkContent":"For each queue manager on the MQ Appliance for which performance events logging should be enabled, establish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nTo run the \"runmqsc [queue mgr name]\" command for each running queue manager identified, enter:\nrunmqsc [queue mgr name]\nDIS QMGR PERFMEV\nDIS QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV\nend\n\nIf \"QDEPTHHI\" is not \"75\", this is a finding.\n\nAsk the system administrator to demonstrate how they monitor an alert on MQ  failure events.\n\nVerify alarming is set for the following log events:\nMQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH\n\nIf the system admin does not monitor an alarm for the following error codes: MQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, or MQRC_Q_DEPTH_HIGH, this is a finding.","fixText":"For each queue manager on the MQ Appliance, enable performance (PERFMEV) event logging.\n\nFrom the MQ Appliance CLI, enter the following:\n\nrunmqsc [queue mgr name]\nALTER QMGR PERFMEV(ENABLED)\nALTER QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV(ENABLED)\nALTER QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDEPTHHI(75)\n\nMonitor the logs and send alerts based on the following failure codes: \nMQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH.","ccis":["CCI-001855"]},{"vulnId":"V-255787","ruleId":"SV-255787r961620_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must protect against or limit the effects of all types of Denial of Service (DoS) attacks by employing operationally-defined security safeguards.","description":"DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. To reduce the possibility or effect of a DoS, the messaging server must employ defined security safeguards. These safeguards will be determined by the placement of the messaging server and the type of applications being hosted within the messaging server framework.\n\nThere are many examples of technologies that exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the application opens at one time). Employing increased capacity and bandwidth, combined with service redundancy or clustering, may reduce the susceptibility to some DoS attacks.\n\nNote: IBM recommends that neither MQ server nor the MQ Appliance be placed in the DMZ where it could be vulnerable to DoS attacks. IBM recommends that this protection be provided by a firewall: https://ibm.biz/BdraMj\n\nFor internal queue managers, You can restrict the total number of incoming connections by setting the MaxConnectionThreads property: https://ibm.biz/BdraMZ\n\nSatisfies: SRG-APP-000435-AS-000163, SRG-APP-000001-AS-000001","checkContent":"Obtain documentation that specifies operational limits from system admin. Check the \"SVRCONN\" channels of each queue manager to confirm that \"MAXINST\" and \"MAXINSTC\" values are set to a value that reflects operational requirements.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nTo run the \"runmqsc [queue mgr name]\" command for each running queue manager identified, enter:\nrunmqsc [queue mgr name]\n\nTo display available SVRCONN channels details, enter:\nDIS CHANNEL(*) CHLTYPE(SVRCONN) \n\nDisplay values for each channel:\nDIS CHANNEL(Channel Name)\n\nIf the value of either \"MAXINST\" or \"MAXINSTC\" is greater than the organization-defined limit, this is a finding.","fixText":"For each queue manager's server connection (SVRCONN) channel(s):\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc <queue manager name> >>\n\nTo display available SVRCONN channels, enter:\nDIS CHANNEL(*) CHLTYPE(SVRCONN)\n\nALTER CHANNEL(<svrconn channel name>) CHLTYPE(SVRCONN) \nMAXINST(max allowed channel instances)\nMAXINSTC(max allowed channels for same client: less than MAXINST)\nend","ccis":["CCI-000054","CCI-002385"]},{"vulnId":"V-255788","ruleId":"SV-255788r961221_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must automatically terminate a SSH user session after organization-defined conditions or trigger events requiring a session disconnect.","description":"An attacker can take advantage of CLI user sessions that are left open, thus bypassing the user authentication process.\n\nTo thwart the vulnerability of open and unused user sessions, the messaging server must be configured to close the sessions when a configured condition or trigger event is met.\n\nSession termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated.\n\nConditions or trigger events requiring automatic session termination can include, for example, periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.","checkContent":"To access the MQ Appliance CLI, enter:\nmqcli\n\nshow rbm\n\nVerify that the cli-timeout displays the approved timeout value of 600 seconds (10 minutes) or less.\n\nIf it does not, this is a finding.","fixText":"For the CLI used by the administrator, log on to the MQ Appliance CLI as a privileged user.\n\nEnter:\nco\nrbm\ncli-timeout 600\nexit\nwrite mem\ny","ccis":["CCI-002361"]},{"vulnId":"V-255789","ruleId":"SV-255789r961221_rule","severity":"medium","ruleTitle":"The MQ Appliance must automatically terminate a WebGUI user session after 600 seconds of idle time.","description":"An attacker can take advantage of WebGUI user sessions that are left open, thus bypassing the user authentication process.\n\nTo thwart the vulnerability of open and unused user sessions, the messaging server must be configured to close the sessions when a configured condition or trigger event is met.\n\nSession termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated.\n\nConditions or trigger events requiring automatic session termination can include, for example, periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.","checkContent":"Log on to the MQ Appliance CLI as a privileged user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo enter configuration mode, enter:\nco\nweb-mgmt\nshow\n\nIf the idle-timeout value is not \"600\" seconds or less, this is a finding.","fixText":"Log on to the MQ Appliance CLI as a privileged user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo enter configuration mode, enter:\nco\nweb-mgmt\nidle-timeout <600 seconds or less>\nexit\nwrite mem\ny","ccis":["CCI-002361"]},{"vulnId":"V-255790","ruleId":"SV-255790r961521_rule","severity":"medium","ruleTitle":"The MQ Appliance SSH interface to the messaging server must prohibit the use of cached authenticators after 600 seconds.","description":"When the messaging server is using PKI authentication, a local revocation cache must be stored for instances when the revocation cannot be authenticated through the network, but if cached authentication information is out of date, the validity of the authentication information may be questionable.","checkContent":"In the MQ Appliance WebGUI, Go to Administration (gear icon) >> Access >> RBM Settings.\n\nVerify that cache setting is defined and specifies \"600\" seconds.\n\nIf the time period is not set to \"600\" seconds, this is a finding.","fixText":"In the MQ Appliance WebGUI, Go to Administration (gear icon) >> Access >> RBM Settings.\n\nLimit cache settings to \"600\" seconds.","ccis":["CCI-002007"]},{"vulnId":"V-255791","ruleId":"SV-255791r961596_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must only allow the use of DoD PKI-established certificate authorities for verification of the establishment of protected (messaging) sessions.","description":"Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established.\n\nThe DoD will only accept PKI certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates.  The messaging server must only allow the use of DoD PKI-established certificate authorities for verification.","checkContent":"From the MQ Appliance WebGUI, click on the Administration (gear) icon.\n\nClick on Main >> File Management.\n\nClick on the cert directory.\n\nClick on the \"Details\" action to the right of each cert to display its attributes.\n\nVerify that each certificate attribute meets organizationally approved requirements.\n\nIf any certificates have not been issued by a DoD- or CNSS-approved PKI CA, this is a finding.","fixText":"Install certificates that have been issued by a DoD CA.","ccis":["CCI-002470"]},{"vulnId":"V-255792","ruleId":"SV-255792r1001151_rule","severity":"medium","ruleTitle":"The version of MQ Appliance messaging server running on the system must be a supported version.","description":"Security flaws with software applications are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.\n\nOrganization-defined time periods for updating security-relevant software may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw).\n\nThis requirement will apply to software patch management solutions used to install patches across the enclave and also to applications that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality, will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means the time period used must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.\n\nThe application will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).","checkContent":"MQ Appliance messaging server version 9.x is no longer supported by the vendor. If the system is running MQ Appliance messaging server version 9.x, this is a finding.","fixText":"Upgrade to a supported version.","ccis":["CCI-002605"]},{"vulnId":"V-255793","ruleId":"SV-255793r961857_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must use DoD- or CNSS-approved PKI Class 3 or Class 4 certificates.","description":"Class 3 PKI certificates are used for servers and software signing rather than for identifying individuals. Class 4 certificates are used for business-to-business transactions. Utilizing unapproved certificates not issued or approved by DoD or CNS creates an integrity risk. The messaging server must utilize approved DoD or CNS Class 3 or Class 4 certificates for software signing and business-to-business transactions.","checkContent":"From the MQ Appliance WebGUI, click on the Administration (gear) icon.\n\nClick on Main >> File Management.\n\nClick on the cert directory.\n\nClick on the \"Details\" action to the right of each cert to display its attributes.\n\nVerify that each certificate attribute meets organizationally approved requirements.\n\nIf any certificates have not been issued by a DoD- or CNSS-approved PKI CA, this is a finding.","fixText":"Install approved certificates that have been issued by a DoD CA.","ccis":["CCI-002450"]},{"vulnId":"V-255794","ruleId":"SV-255794r981695_rule","severity":"low","ruleTitle":"The MQ Appliance messaging server must accept FICAM-approved third-party credentials.","description":"Access may be denied to legitimate users if FICAM-approved third-party credentials are not accepted.\n\nThis requirement typically applies to organizational information systems that are accessible to non-federal government agencies and other partners. This allows federal government relying parties to trust such credentials at their approved assurance levels.\n\nThird-party credentials are those credentials issued by non-federal government entities approved by the Federal Identity, Credential, and Access Management (FICAM) Trust Framework Solutions initiative.\n\nSatisfies: SRG-APP-000404-AS-000249, SRG-APP-000405-AS-000250","checkContent":"Log on to the WebGUI as a privileged user.\n\nClick on the \"MQ Console\" icon.\n\nClick \"Add\" widget at the top right of the screen.\n\nSelect queue manager intended for OCSP from the drop-down list.\n\nSelect \"Authentication Information\".\n\nVerify that the authentication type is \"OCSP\".\n\nClick on the \"Properties\" button.\n\nClick \"OCSP\" on the side bar to verify that the OCSP responder URL is correct.\n\nIf either the authentication type is not \"OCSP\" or the OCSP responder URL in not correct, this is a finding.","fixText":"Log on to the WebGUI as a privileged user.\n\nClick on the \"MQ Console\" icon.\n\nClick \"Add\" widget at the top right of the screen.\n\nSelect a queue manager from the drop-down list.\n\nSelect \"Authentication Information\".\n\nClick the \"+\" (plus sign) to define the authentication method authentication for this queue manager.\n\nSpecify an \"Authinfo\" name (e.g., USE.OCSP).\n\nSelect \"OCSP\" as the \"Authinfo\" type.\n\nSpecify an OCSP responder URL.\n\nClick \"Create\".\n\nIn the \"Local Queue Managers\" widget, select the OCSP queue manager you just configured.\n\nClick \"More...\" then select \"Refresh Security... \"","ccis":["CCI-002011","CCI-002014"]},{"vulnId":"V-255795","ruleId":"SV-255795r961056_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must provide a log reduction capability that supports on-demand reporting requirements.","description":"The ability to generate on-demand reports, including after the log data has been subjected to log reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents.\n\nLog reduction is a process that manipulates collected log information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad-hoc, and as-needed) reports.\n\nTo fully understand and investigate an incident within the components of the messaging server, the messaging server, when providing a reduction capability, must provide an on-demand reporting capability.\n\nInstructions for using the amqsevt sample program to display instrumentation events may be found at the following URL: https://ibm.biz/BdsCzY\n\nSatisfies: SRG-APP-000181-AS-000255, SRG-APP-000355-AS-000055","checkContent":"Confirm that the following command is available and functioning on an authorized MQ client device:\n\namqsevt -m [queue mgr name] {-q SYSTEM.ADMIN.QMGR.EVENT | -q SYSTEM.ADMIN.CONFIG.EVENT | -q SYSTEM.ADMIN.PERFM.EVENT | -q SYSTEM.ADMIN.CHANNEL.EVENT | -q SYSTEM.ADMIN.COMMAND.EVENT} -c -u [user name]\n\nIf an MQ client application is not enabled to monitor one or more of the above event queues, this is a finding.","fixText":"Log record aggregation and reporting for each event-logging-enabled queue manager on the MQ Appliance may be accomplished by running the following command from an authorized MQ client device:\n\namqsevt -m [queue mgr name] {-q SYSTEM.ADMIN.QMGR.EVENT | -q SYSTEM.ADMIN.CONFIG.EVENT | -q SYSTEM.ADMIN.PERFM.EVENT | -q SYSTEM.ADMIN.CHANNEL.EVENT | -q SYSTEM.ADMIN.COMMAND.EVENT} -c -u [user name]\n\nNote: Any MQ monitoring solution that can connect to MQ as a client may be used to monitor event queues.","ccis":["CCI-001876","CCI-001920"]},{"vulnId":"V-255796","ruleId":"SV-255796r960915_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must be configured to fail over to another system in the event of log subsystem failure.","description":"This requirement is dependent upon system MAC and availability. If the system MAC and availability do not specify redundancy requirements, this requirement is NA.\n\nIt is critical that, when a system is at risk of failing to process logs as required, it detects and takes action to mitigate the failure.\n\nMessaging servers must be capable of failing over to another system which can handle application and logging functions upon detection of an application log processing failure. This will allow continual operation of the application and logging functions while minimizing the loss of operation for the users and loss of log data.\n\nTo ensure proper configuration, system HA design steps must be taken and implemented. Reference vendor documentation for complete instructions on setting up HA: https://ibm.biz/BdicC7\n\nSatisfies: SRG-APP-000109-AS-000070, SRG-APP-000109-AS-000068, SRG-APP-000125-AS-000084","checkContent":"In the event of a MQ queue manager failure, an HA configuration must be used. \n\nObtain system documentation identifying the HA configuration.\n\nEstablish an SSH command line session to either of the pair as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo run the dspmq command, enter:\ndspmq -s -o ha \n\nEach queue manager that is properly configured for HA should show HA(Replicated). \n\nIf it does not, this is a finding.","fixText":"Rudimentary instructions for setting up HA are included here. \n\n1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3.\n2. Configure the three connected MQ Appliance ports (on both appliances) as follows:\n\nInterface Purpose IP address/CIDR\neth1 HA group primary interface x.x.x.x/24\neth2 HA group alternative interface x.x.x.x/24\neth3 HA Replication interface x.x.x.x/24\n\nOn the second appliance, enter the following command from the MQ Appliance CLI:\nprepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout]\n\nOn the first appliance, enter the following command:\ncrthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance]\n\nOn the first appliance, stop the first queue manager to be HA enabled:\nendmqm [name of queue manager]\n\nSet an HA group:\nsethagrp -i [name of queue manager]\n\nNote: The queue manager’s data (queues, queue messages, etc.) are replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).","ccis":["CCI-000140","CCI-001348"]},{"vulnId":"V-255797","ruleId":"SV-255797r1000054_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must uniquely identify all network-connected endpoint devices before establishing any connection.","description":"Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.\n\nFor distributed messaging servers and components, the decisions regarding the validation of identification claims may be made by services separate from the messaging server. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions. Note: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp","checkContent":"Check that TLS mutual authentication configuration is correct by using \"DISPLAY\" commands. \n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nTo display available SVRCONN channels details, enter:\nDIS CHANNEL(*) CHLTYPE(SVRCONN)\n\nNote the names of SVRCONN channels (client channels). \n\nDisplay values for each channel:\nDIS CHANNEL([name of SVRCONN channel])\n\nConfirm that the parameter \"SSLCIPH\" specifies a FIPS approved cipher spec and that the value of \"SSLAUTH\" is set to \"REQUIRED\".\n\nMQ cipher specs are available here: https://ibm.biz/BdrJGp Utilize a FIPS approved cipher when specifying SSLCIPH.\n\nIf either the \"SSLCIPH\" or \"SSLAUTH\" value for each channel is not correct, this is a finding.","fixText":"Run the fix for each affected queue manager and each affected channel. \n\nTo access the MQ Appliance enter:\nmqcli\nrunmqsc [queue name]\n\nALTER CHANNEL([channel name] CHLTYPE(SVRCONN) TRPTYPE(TCP) \nSSLCIPH([Use FIPS Approved cipher specs only]) SSLCAUTH(REQUIRED)\n\nEnter \"end\" to exit runmqsc mode.","ccis":["CCI-000778"]},{"vulnId":"V-255798","ruleId":"SV-255798r961029_rule","severity":"medium","ruleTitle":"Access to the MQ Appliance messaging server must utilize encryption when using LDAP for authentication.","description":"Passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. \n\nMessaging servers have the capability to utilize LDAP directories for authentication. If LDAP connections are not protected during transmission, sensitive authentication credentials can be stolen. When the messaging server utilizes LDAP, the LDAP traffic must be encrypted.\n\nNote: Multiple alternative LDAP hosts may be listed in the CONNAME parameter, separated by commas.\n\nReview IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server.\n\nSee https://ibm.biz/BdiBGu and https://ibm.biz/BdixXz for a detailed description of these options.","checkContent":"To access the MQ Appliance CLI, for each queue manager, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nTo display the active authentication object, enter:\nDIS QMGR CONNAUTH \n\nResult: QMNAME([queue mgr name]) CONNAUTH([auth object name])\n\nDIS AUTHINFO(auth object name)\n\nVerify that \"AUTHTYPE(IDPWLDAP)\", and \"SECCOMM(YES)\" are displayed, and that all parameters are correctly specified to use the organizationally approved LDAP server(s).\n\nIf these parameter values cannot be verified, this is a finding.","fixText":"Specify LDAP as the authentication method for each queue manager.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [queue manager name]\n\nDEFINE AUTHINFO('[Object name e.g., USE.LDAP]') \nAUTHTYPE(IDPWLDAP) \nCONNAME('[ldap1(port),ldap2(port),ldap3(port)]') \nSECCOMM(YES) [Ensures encryption is used]\nSHORTUSR('[short user name]') \nCHCKCLNT(REQUIRED) \nBASEDNU('base user DN') \nREPLACE\n\nALTER QMGR CONNAUTH('[AUTHINFO object name]')\nREFRESH SECURITY TYPE(CONNAUTH)\n\nType \"end\" to exit runmqsc mode.","ccis":["CCI-000197"]},{"vulnId":"V-255799","ruleId":"SV-255799r961044_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must map the authenticated identity to the individual messaging user or group account for PKI-based authentication.","description":"The cornerstone of PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information, but the key can be mapped to a user. Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.\n\nMessaging servers must provide the capability to utilize and meet requirements of the DoD Enterprise PKI infrastructure for application authentication.\n\nNote: Two or more alternative LDAP hosts may be listed, in the CONNAME parameter, separated by commas.\n\nReview IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server.\n\nSee https://ibm.biz/BdiBGu for a detailed description of these options.","checkContent":"To access the MQ Appliance CLI, for each queue manager, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS AUTHINFO(*) AUTHTYPE(CRLLDAP) CONNAME\n\nVerify that an \"AUTHINFO\" definition of \"AUTHTYPE(CRLLDAP)\" is displayed and that the CONNAME in parenthesis is the host name or IPv4 dotted decimal address of an organizationally approved LDAP server.\n\nIf the \"AUTHINFO\" definition is not equal to \"AUTHTYPE(CRLLDAP)\", this is a finding.","fixText":"Specify LDAP as the authentication method for each queue manager.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [queue manager name]\n\nDEFINE AUTHINFO('[Object name e.g., USE.CRLLDAP]') \nAUTHTYPE(CRLLDAP) \nCONNAME('[LDAPhost1(port)]') REPLACE\n\nType \"end\" to exit runmqsc mode.","ccis":["CCI-000187"]},{"vulnId":"V-255800","ruleId":"SV-255800r981681_rule","severity":"medium","ruleTitle":"The MQ Appliance must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.","description":"Inactive identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. \n\nApplications need to track periods of inactivity and disable application identifiers after 35 days of inactivity. \n\nManagement of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual.\n\nTo avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements.\n\nReview IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server.\n\nNote: Multiple alternative LDAP hosts may be listed in the CONNAME parameter, separated by commas.\n\nReview IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server.\n\nSee https://ibm.biz/BdiBGu and https://ibm.biz/BdixXz for a detailed description of these options.","checkContent":"To access the MQ Appliance CLI, for each queue manager, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nTo display the active authentication object, enter:\nDIS QMGR CONNAUTH\n\nResult: QMNAME([queue mgr name]) CONNAUTH([auth object name])\n\nDIS AUTHINFO(auth object name)\n\nVerify that \"AUTHTYPE(IDPWLDAP)\" is displayed.\n\nVerify LDAP server user settings are configured to disable accounts after \"35\" days of inactivity.\n\nIf \"AUTHTYPE(IDPWLDAP)\" is not displayed or if the LDAP server user settings are not configured to disable accounts after \"35\" days of inactivity, this is a finding.","fixText":"Specify LDAP as the authentication method for each queue manager.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [queue manager name]\n\nDEFINE AUTHINFO('[Object name e.g., USE.LDAP]') \nAUTHTYPE(IDPWLDAP) \nCONNAME('[ldap1(port),ldap2(port),ldap3(port)]')  \nSECCOMM(YES)                                 [Ensures encryption is used]\nSHORTUSR('[short user name]') \nCHCKCLNT(REQUIRED) \nBASEDNU('base user DN') \nREPLACE\n\nALTER QMGR CONNAUTH('[AUTHINFO object name]')\nREFRESH SECURITY TYPE(CONNAUTH)\n\nEnter \"end\" to exit runmqsc mode.\n\nConfigure LDAP server to disable accounts after 35 days of inactivity.","ccis":["CCI-000795"]},{"vulnId":"V-255801","ruleId":"SV-255801r960969_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must use an enterprise user management system to uniquely identify and authenticate users (or processes acting on behalf of organizational users).","description":"To assure accountability and prevent unauthorized access, application server users must be uniquely identified and authenticated. This is typically accomplished via the use of a user store which is either local (OS-based) or centralized (LDAP) in nature.\n\nTo ensure support to the enterprise, the authentication must utilize an enterprise solution.\n\nReview IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server.\n\nSee https://ibm.biz/BdsRRk for a detailed description of these options.","checkContent":"To access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS AUTHINFO(USE.LDAP)\n\nVerify that \"AUTHINFO(USE.LDAP)\" is displayed under authentication information details. \n\nIf \"IBM MQ Appliance object USE.LDAP not found\" is displayed, this is a finding.","fixText":"Specify LDAP as the authentication method for each queue manager.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [queue manager name]\n\nDEFINE AUTHINFO(USE.LDAP) \nAUTHTYPE(CRLLDAP) \nCONNAME('[host name1(port)],[host name1(port)]') \n\nALTER QMGR CONNAUTH('USE.LDAP')\nREFRESH SECURITY TYPE(CONNAUTH)\n\nEnter \"end\" to exit runmqsc mode.","ccis":["CCI-000764"]},{"vulnId":"V-255802","ruleId":"SV-255802r960843_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.","description":"Messaging servers are required to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system management interface, providing privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance that states that: \n\n(i) users are accessing a U.S. Government information system; \n(ii) system usage may be monitored, recorded, and subject to audit; \n(iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and \n(iv) the use of the system indicates consent to monitoring and recording.\n\nSystem use notification messages can be implemented in the form of warning banners displayed when individuals log on to the information system. \n\nSystem use notification is intended only for information system access including an interactive logon interface with a human user, and is not required when an interactive interface does not exist. \n\nUse this banner for desktops, laptops, and other devices accommodating banners of 1300 characters. The banner shall be implemented as a click-through banner at logon (to the extent permitted by the operating system), meaning it prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating \"OK\".\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"","checkContent":"Using a browser, navigate to the MQ Appliance logon page as a privileged user. \n\nVerify the logon page displays the Standard Mandatory DoD Notice and Consent Banner:\n\nFor the WebGUI, the banner must read:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\nLogging in signifies acceptance of this agreement.\"\n\nFor the SSH CLI, the banner must read:\n\n\"I've read & consent to terms in IS user agreem't.\nLogging in signifies acceptance of this agreement.\"\n\nIf the standard banner is not displayed in both the WebGUI and CLI interfaces, this is a finding.","fixText":"The custom banner must be set up as follows:\n1. Log on to the WebGUI as a privileged user.\n2. Click on the Administration (gear) icon.\n3. Under Main, click on File Management.\n4. Open the \"Store\" directory.\n5. Scroll down to the file, \"dp-user-interface-demo.xml\".\n6. Click in the box to the left of the file name.\n7. At the top of the page, click on the Copy button.\n8. Select \"local:\" as the New Directory Name.\n9. Enter a New File Name e.g., \"ui-customization.xml\".\n10. Click Confirm copy.\n11. Click Continue.\n12. Edit the \"ui-customization.xml\" file. \n13. Refresh the browser page.\n14. Click \"local:\".\n15. Click the \"Edit\" link to the right of \"ui-customization.xml\".\n16. Click the \"Edit\" button.\n17. Locate the XML Stanza named \"MarkupBanner\".\n18. 'type=\"pre-login\"'. \n19. Replace the existing text with the text of the Standard Mandatory DoD Notice and Consent Banner:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\nLogging in signifies acceptance of this agreement.\"\n\n20. Locate the XML Stanza named \"TextBanner\".\n21. 'type=\"pre-login\"'\n22. Replace the existing text with the text of the Standard Mandatory DoD Notice and Consent Banner: \"I've read and consent to terms in IS user agreement.\nLogging in signifies acceptance of this agreement.\" \n23. Click the \"Submit\" button.\n24. Configure the MQ Appliance to use the customized User Interface Customization file: In the WebGUI, click on Gear icon (Administration) then select Device >> System Settings.\n25. Scroll to \"Custom user interface file\" section at the bottom of the page and select the local:/// directory then the \"ui-customization.xml\" from the drop-down list.\n26. Scroll to top of the page.\n27. Click \"Apply\". \n28. Click \"Save Configuration\".\n\nLog off of the appliance.","ccis":["CCI-000048"]},{"vulnId":"V-255803","ruleId":"SV-255803r960879_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must generate log records for access and authentication events.","description":"Log records can be generated from various components within the messaging server. From a messaging server perspective, certain specific messaging server functionalities may be logged as well. The messaging server must allow the definition of what events are to be logged. As conditions change, the number and types of events to be logged may change, and the messaging server must be able to facilitate these changes.\n\nThe minimum list of logged events should be those pertaining to system startup and shutdown, system access, and system authentication events.","checkContent":"Establish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS QMGR EVENT\n\nA list of all events will be displayed along with an indication of if event logging is enabled. The events are as follows:\n\nAuthority: AUTHOREV, Inhibit: INHIBITEV, Local: LOCALEV, Remote: REMOTEEV, Start and stop: STRSTPEV, Performance: PERFMEV, Command: CMDEV, Channel: CHLEV, Channel auto definition: CHADEV, SSL: SSLEV, Configuration: CONFIGEV\n\nIf and required event logging is not enabled for running queue managers, this is a finding.","fixText":"The following events may be logged for each queue manager on the MQ Appliance:\n\nAuthority (AUTHOREV), Inhibit (INHIBITEV), Local (LOCALEV), Remote (REMOTEEV), Start and stop (STRSTPEV), Performance (PERFMEV), Command (CMDEV), Channel (CHLEV), Channel auto definition (CHADEV), SSL (SSLEV), Configuration (CONFIGEV)\n\nTo enable logging for a queue manager, enter the following from the MQ Appliance CLI for each event for which you wish to enable logging:\n\nTo access the MQ Appliance CLI, enter the following:\nmqcli \n\nrunmqsc [queue mgr name]\nALTER QMGR [event name](ENABLED)\nend\n\nNote: Any MQ monitoring solution that connects to MQ as a client may be used to monitor event queues.","ccis":["CCI-000169"]},{"vulnId":"V-255804","ruleId":"SV-255804r961110_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must ensure authentication of both SSH client and server during the entire session.","description":"This control focuses on communications protection at the session, versus packet level.\n\nAt the application layer, session IDs are tokens generated by web applications to uniquely identify an application user's session. Web applications utilize session tokens or session IDs in order to establish application user identity. Proper use of session IDs addresses man-in-the-middle attacks, including session hijacking or insertion of false information into a session.\n\nMessaging servers must provide the capability to perform mutual authentication. Mutual authentication is when both the client and the server authenticate each other.\n\nSatisfies: SRG-APP-000219-AS-000147, SRG-APP-000223-AS-000150, SRG-APP-000223-AS-000151","checkContent":"Check that TLS mutual authentication configuration is correct by using DISPLAY commands. \n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS CHANNEL(*) CHLTYPE(SVRCONN)\n\nNote the name of SVRCONN channel (client channel) you wish to check.\n\nDIS CHANNEL([name of SVRCONN channel])\n\nConfirm that the parameter \"SSLCIPH\" specifies the desired cipher spec and that the value of \"SSLAUTH\" is \"REQUIRED\".\n\nIf either the \"SSLCIPH\" or \"SSLAUTH\" value is not correct, this is a finding.","fixText":"The most common way devices (endpoints) may connect an MQ Appliance MQ queue manager is as an MQ client. In order to ensure unique identification of network-connected devices, mutual authentication using CA-signed TLS certificates should be configured. \n\n1. Prepare the key repository on each endpoint client.\n2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints.\n3. Add the Certificate Authority certificate to the key repository for each client. If the endpoints are using different Certificate Authorities then the CA certificate for each Certificate Authority must be added to both key repositories.\n4. Add the CA-signed certificate to the key repository for each endpoint.\n\nOn the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example:\n\n[C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM)\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [QM1]\nDEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) +\nSSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS from [client name] to [QM name]')\nend\n\nNote: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp","ccis":["CCI-001184","CCI-001664"]},{"vulnId":"V-255805","ruleId":"SV-255805r961119_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must generate a unique session identifier using a FIPS 140-2 approved random number generator.","description":"The messaging server will use session IDs to communicate between modules or applications within the messaging server and between the messaging server and users. The session ID allows the application to track the communications along with credentials that may have been used to authenticate users or modules.\n\nUnique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers.\n\nUnique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.","checkContent":"Check that TLS mutual authentication configuration is correct by using DISPLAY commands. \n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS CHANNEL(*) CHLTYPE(SVRCONN)\n\nNote the name of SVRCONN channel (client channel) you wish to check.\n\nDIS CHANNEL([name of SVRCONN channel])\n\nConfirm that the parameter \"SSLCIPH\" specifies the desired cipher spec and that the value of \"SSLAUTH\" is \"REQUIRED\".\n\nIf either the \"SSLCIPH\" or \"SSLAUTH\" value is not correct, this is a finding.","fixText":"The most common way devices (endpoints) may connect an MQ Appliance MQ queue manager is as an MQ client. In order to ensure unique identification of network-connected devices, mutual authentication using CA-signed TLS certificates should be configured. \n\n1. Prepare the key repository on each endpoint client.\n2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints.\n3. Add the Certificate Authority certificate to the key repository for each client. If the endpoints are using different Certificate Authorities then the CA certificate for each Certificate Authority must be added to both key repositories.\n4. Add the CA-signed certificate to the key repository for each endpoint.\n\nOn the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example:\n\n[C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM)\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [QM1]\nDEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) +\nSSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS from [client name] to [QM name]')\nend\n\nNote: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp","ccis":["CCI-001188"]},{"vulnId":"V-255806","ruleId":"SV-255806r1000055_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must authenticate all network-connected endpoint devices before establishing any connection.","description":"Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device.\n\nDevice authentication is accomplished via the use of certificates and protocols such as SSL mutual authentication.\n\nDevice authentication is performed when the messaging server is providing web services capabilities and data protection requirements mandate the need to establish the identity of the connecting device before the connection is established.\n\nThe most common way devices (endpoints) may connect an MQ Appliance MQ queue manager is as an MQ client. In order to ensure unique identification of network-connected devices, mutual authentication using CA-signed TLS certificates should be configured. \n\nNote: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp","checkContent":"Check that TLS mutual authentication configuration is correct by using DISPLAY commands. \n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS CHANNEL(*) CHLTYPE(SVRCONN)\n\nNote the name of SVRCONN channel (client channel) you wish to check.\n\nDIS CHANNEL([name of SVRCONN channel])\n\nConfirm that the parameter \"SSLCIPH\" specifies the desired cipher spec and that the value of \"SSLAUTH\" is \"REQUIRED\".\n\nIf either the \"SSLCIPH\" or \"SSLAUTH\" value is not correct, this is a finding.","fixText":"The most common way devices (endpoints) may connect an MQ Appliance MQ queue manager is as an MQ client. In order to ensure unique identification of network-connected devices, mutual authentication using CA-signed TLS certificates should be configured. \n\n1. Prepare the key repository on each endpoint client.\n2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints.\n3. Add the Certificate Authority certificate to the key repository for each client. If the endpoints are using different Certificate Authorities then the CA certificate for each Certificate Authority must be added to both key repositories.\n4. Add the CA-signed certificate to the key repository for each endpoint.\n\nOn the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example:\n\n[C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM)\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [QM1]\n\nReplace the brackets \"[ ]\" with a selected parameter:\nDEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) +\nSSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS from [client name] to [QM name]')\n\nFor example:\nALTER CHANNEL(C1.TO.QM1) CHLTYPE(SVRCONN) TRPTYPE(TCP) +\nSSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS from C1 to QM1')","ccis":["CCI-001958"]},{"vulnId":"V-255807","ruleId":"SV-255807r1000056_rule","severity":"high","ruleTitle":"The MQ Appliance messaging server must authenticate all endpoint devices before establishing a local, remote, and/or network connection using bidirectional authentication that is cryptographically based.","description":"Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device.\n\nBidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk.\n\nDevice authentication is performed when the messaging server is providing web services capabilities and data protection requirements mandate the need to establish the identity of the connecting device before the connection is established.\n\nThe most common way devices (endpoints) may connect an MQ Appliance MQ queue manager is as an MQ client. In order to ensure unique identification of network-connected devices, mutual authentication using CA-signed TLS certificates must be configured. \n\nNote: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp","checkContent":"Review system documentation. Identify all message services hosted on the device(s) and determine if any services are hosting publicly available, non-sensitive data. This requirement is NA for publicly available services that host non-sensitive data if a documented ISSO risk acceptance is presented. \n\nCheck that TLS mutual authentication configuration is correct by using DISPLAY commands. \n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS CHANNEL(*) CHLTYPE(SVRCONN)\n\nNote the name of SVRCONN channel (client channel) you wish to check.\n\nDIS CHANNEL([name of SVRCONN channel])\n\nConfirm that the parameter \"SSLCIPH\" specifies the desired cipher spec and that the value of \"SSLAUTH\" is \"REQUIRED\".\n\nIf either the \"SSLCIPH\" or \"SSLAUTH\" value is not correct, this is a finding.","fixText":"1. Prepare the key repository on each endpoint client.\n2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints.\n3. Add the Certificate Authority certificate to the key repository for each client. If the endpoints are using different Certificate Authorities then the CA certificate for each Certificate Authority must be added to both key repositories.\n4. Add the CA-signed certificate to the key repository for each endpoint.\n\nOn the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example:\n\n[C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM)\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [QM1]\n\nReplace the brackets \"[ ]\" with a selected parameter:\nDEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) +\nSSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS from [client name] to [QM name]')\n\nFor example:\nALTER CHANNEL(C1.TO.QM1) CHLTYPE(SVRCONN) TRPTYPE(TCP) +\nSSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED) +\nDESCR('Receiver channel using TLS from C1 to QM1')","ccis":["CCI-001967"]},{"vulnId":"V-255808","ruleId":"SV-255808r961857_rule","severity":"medium","ruleTitle":"MQ Appliance messaging servers must use NIST-approved or NSA-approved key management technology and processes.","description":"An asymmetric encryption key must be protected during transmission. The public portion of an asymmetric key pair can be freely distributed without fear of compromise, and the private portion of the key must be protected. The messaging server will provide software libraries that applications can programmatically utilize to encrypt and decrypt information. These messaging server libraries must use NIST-approved or NSA-approved key management technology and processes when producing, controlling, or distributing symmetric and asymmetric keys.\n\nThe most common way devices (endpoints) may connect an MQ Appliance MQ queue manager is as an MQ client. In order to ensure unique identification of network-connected devices, mutual authentication using CA-signed TLS certificates should be configured. \n\nNote: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp","checkContent":"Check that TLS mutual authentication configuration is correct by using DISPLAY commands. \n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS CHANNEL(*) CHLTYPE(SVRCONN)\n\nNote the name of SVRCONN channel (client channel) you wish to check.\n\nDIS CHANNEL([name of SVRCONN channel])\n\nConfirm that the parameter \"SSLCIPH\" specifies the desired cipher spec and that the value of \"SSLAUTH\" is \"REQUIRED\".\n\nIf either the \"SSLCIPH\" or \"SSLAUTH\" value is not correct, this is a finding.","fixText":"1. Prepare the key repository on each endpoint client.\n2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints.\n3. Add the Certificate Authority certificate to the key repository for each client. If the endpoints are using different Certificate Authorities then the CA certificate for each Certificate Authority must be added to both key repositories.\n4. Add the CA-signed certificate to the key repository for each endpoint.\n\nOn the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example:\n\n[C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM)\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nrunmqsc [QM1]\n\nDEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) \nSSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) \nDESCR('Receiver channel using TLS from [client name] to [QM name]')\nend","ccis":["CCI-002450"]},{"vulnId":"V-255809","ruleId":"SV-255809r961050_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must utilize FIPS 140-2 approved encryption modules when authenticating users and processes.","description":"Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms. The use of TLS provides confidentiality of data in transit between the messaging server and client. FIPS 140-2 approved TLS versions include TLS V1.0 or greater. \n\nTLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems.\n\nTo achieve FIPS 140-2 compliance on Windows, UNIX, and Linux systems, all key repositories have been created and manipulated using only FIPS-compliant software, such as runmqakm with the -fips option.","checkContent":"To access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS QMGR SSLFIPS\n\nIf the value of \"SSLFIPS\" is set to \"NO\", this is a finding.","fixText":"To access the MQ Appliance CLI, for each queue manager, enter:\n\nmqcli\n\nrunmqsc [queue manager name]\nALTER QMGR SSLFIPS(YES)\nend","ccis":["CCI-000803"]},{"vulnId":"V-255810","ruleId":"SV-255810r961632_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must protect the confidentiality and integrity of transmitted information through the use of an approved TLS version.","description":"Preventing the disclosure of transmitted information requires that the messaging server take measures to employ some form of cryptographic mechanism in order to protect the information during transmission.  This is usually achieved through the use of Transport Layer Security (TLS).\n\nTransmission of data can take place between the messaging server and a large number of devices/applications external to the messaging server.  Examples are a web client used by a user, a backend database, a log server, or other messaging servers (and clients) in a messaging server cluster.\n\nIf data is transmitted unencrypted, the data then becomes vulnerable to disclosure.  The disclosure may reveal user identifier/password combinations, website code revealing business logic, or other user personal information.\n\nFIPS 140-2 approved TLS versions include TLS V1.0 or greater.\n\nTLS must be enabled and non-FIPS-approved SSL versions must be disabled.  NIST SP 800-52 specifies the preferred configurations for government systems.\n\nTo achieve FIPS 140-2 compliance on Windows, UNIX, and Linux systems, all key repositories have been created and manipulated using only FIPS-compliant software, such as runmqakm with the -fips option.","checkContent":"To access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS QMGR SSLFIPS\n\nIf the value of \"SSLFIPS\" is set to \"NO\", this is a finding.","fixText":"To access the MQ Appliance CLI, for each queue manager, enter:\n\nmqcli\n\nrunmqsc [queue manager name]\nALTER QMGR SSLFIPS(YES)\nend","ccis":["CCI-002418"]},{"vulnId":"V-255811","ruleId":"SV-255811r961632_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.","description":"During the initial setup of a Transport Layer Security (TLS) connection to the messaging server, the client sends a list of supported cipher suites in order of preference.  The messaging server will reply with the cipher suite it will use for communication from the client list.  If an attacker can intercept the submission of cipher suites to the messaging server and place, as the preferred cipher suite, a weak export suite, the encryption used for the session becomes easy for the attacker to break, often within minutes to hours.\n\nTo achieve FIPS 140-2 compliance on Windows, UNIX, and Linux systems, all key repositories have been created and manipulated using only FIPS-compliant software, such as runmqakm with the -fips option.","checkContent":"To access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS QMGR SSLFIPS\n\nIf the value of \"SSLFIPS\" is set to \"NO\", this is a finding.","fixText":"To access the MQ Appliance CLI, for each queue manager, enter:\n\nmqcli\nrunmqsc [queue manager name]\nALTER QMGR SSLFIPS(YES)\nend","ccis":["CCI-002418"]},{"vulnId":"V-255812","ruleId":"SV-255812r961635_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must employ approved cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission.","description":"Preventing the disclosure or modification of transmitted information requires that messaging servers take measures to employ approved cryptography in order to protect the information during transmission over the network. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPsec tunnel.\n\nIf data in transit is unencrypted, it is vulnerable to disclosure and modification. If approved cryptographic algorithms are not used, encryption strength cannot be assured.\n\nFIPS 140-2 approved TLS versions include TLS V1.0 or greater.\n\nTLS must be enabled and non-FIPS-approved SSL versions must be disabled.  NIST SP 800-52 specifies the preferred configurations for government systems.\n\nTo achieve FIPS 140-2 compliance on Windows, UNIX, and Linux systems, all key repositories have been created and manipulated using only FIPS-compliant software, such as runmqakm with the -fips option.","checkContent":"To access the MQ Appliance CLI, enter:\nmqcli\n\nTo identify the queue managers, enter:\ndspmq\n\nFor each queue manager identified, run the command:\nrunmqsc [queue name]\n\nDIS QMGR SSLFIPS\n\nIf the value of \"SSLFIPS\" is set to \"NO\", this is a finding.","fixText":"To access the MQ Appliance CLI, for each queue manager, enter:\n\nmqcli\n\nrunmqsc [queue manager name]\nALTER QMGR SSLFIPS(YES)\nend","ccis":["CCI-002421"]},{"vulnId":"V-255813","ruleId":"SV-255813r961122_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must provide a clustering capability.","description":"This requirement is dependent upon system criticality and confidentiality requirements. If the system categorization and confidentiality levels do not specify redundancy requirements, this requirement is NA.\n\nFailure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. When application failure is encountered, preserving application state facilitates application restart and return to the operational mode of the organization with less disruption of mission/business processes.\n\nClustering of multiple messaging servers is a common approach to providing fail-safe application availability when system MAC and confidentiality levels require redundancy.\n\nSatisfies: SRG-APP-000225-AS-000154, SRG-APP-000225-AS-000166","checkContent":"Review system categorization to determine if redundancy is a requirement. If the system categorization does not specify redundancy requirements, this requirement is NA.\n\nOn each member of the HA pair:\nEstablish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo run the dspmq command, enter:\ndspmq -s -o ha \n\nOne of the appliances should be running as primary, the other as secondary.\n\nIf HA is not configured and the primary and secondary running, this is a finding.","fixText":"To configure HA:\n1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3.\n2. Configure the three connected MQ Appliance ports (on both appliances) as follows:\n\nInterface Purpose IP address/CIDR\neth1 HA group primary interface x.x.x.x/24\neth2 HA group alternative interface x.x.x.x/24\neth3 HA Replication interface x.x.x.x/24\n\nOn the second appliance, enter the following command from the MQ Appliance CLI:\nprepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout]\n\nOn the first appliance, enter the following command:\ncrthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance]\ncrtmqm [HA QM name] –p [port] –sx\n\nNote: The queue manager’s data (queues, queue messages, etc.) is replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).","ccis":["CCI-001190"]},{"vulnId":"V-255814","ruleId":"SV-255814r981683_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must provide centralized management and configuration of the content to be captured in log records generated by all application components.","description":"A clustered messaging server is made up of several servers working together to provide the user a failover and increased computing capability.  To facilitate uniform logging in the event of an incident and later forensic investigation, the record format and logable events need to be uniform.  This can be managed best from a centralized server.\n\nWithout the ability to centrally manage the content captured in the log records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack.\n\nThe MQ appliance is designed to be used in a redundant HQ configuration which will provide a means of centralized management of log activity.\n\nRudimentary instructions for determining if HA is set up are included here. To ensure proper configuration, system HA design steps must be taken and implemented. Reference vendor documentation for complete instructions on setting up HA: https://ibm.biz/BdicC7\n\nNote: The queue manager’s data (queues, queue messages etc.) are replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).\n\nRef.: Configuring high availability queue managers  https://goo.gl/xAqNTX","checkContent":"Review system categorization to determine if redundancy is a requirement.  If system categorization does not specify redundancy, interview system administrator to determine how they have configured the centralized log management solution for the MQ appliance.\n\nOn each member of the HA pair:\nEstablish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo run the dspmq command, enter:\ndspmq -s -o ha\n\nOne of the appliances should be running as primary, the other as secondary.\n\nIf HA is not configured and the primary and secondary running, or if there is no centralized management solution in place to manage MQ logs, this is a finding.","fixText":"To configure HA:\n1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3.\n2. Configure the three connected MQ Appliance ports (on both appliances) as follows:\n\nInterface  Purpose                                                 IP address/CIDR\neth1           HA group primary interface          x.x.x.x/24\neth2           HA group alternative interface   x.x.x.x/24\neth3           HA Replication interface               x.x.x.x/24\n\nOn the second appliance, enter the following command from the MQ Appliance CLI:\nprepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout]\n\nOn the first appliance, enter the following command:\ncrthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance]\n\nOn the first appliance, stop the queue manager to be HA-enabled:\nendmqm [name of queue manager]  \nsethagrp -i [name of queue manager]\n\nNote: The queue manager’s data (queues, queue messages, etc.) are replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).","ccis":["CCI-001844"]},{"vulnId":"V-255815","ruleId":"SV-255815r961860_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must, at a minimum, transfer the logs of interconnected systems in real time, and transfer the logs of standalone systems weekly.","description":"Information stored in one location is vulnerable to accidental or incidental deletion or alteration.  Protecting log data is important during a forensic investigation to ensure investigators can track and understand what may have occurred.  Off-loading should be set up as a scheduled task but can be configured to be run manually, if other processes during the off-loading are manual.\n\nOff-loading is a common process in information systems with limited log storage capacity.  \n\nThe MQ appliance is designed to be used in a redundant configuration which will ensure duplicates of log activity are created.\n\nRudimentary instructions for determining if HA is set up are included here. To ensure proper configuration, system HA design steps must be taken and implemented. Reference vendor documentation for complete instructions on setting up HA: https://ibm.biz/BdicC7\n\nNote: The queue manager’s data (queues, queue messages etc.) are replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).","checkContent":"Review system categorization to determine if redundancy is a requirement. If system categorization does not specify redundancy, interview system administrator to determine how they have configured the weekly transfer of logs for the MQ appliance.\n\nFor redundant systems: On each member of the HA pair:\nEstablish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo run the dspmq command, enter:\ndspmq -s -o ha \n\nOne of the appliances should be running as primary, the other as secondary.\n\nIf HA is not configured with the primary and secondary running, or if there is no MQ log transfer taking place on a standalone system on a weekly basis, this is a finding.","fixText":"To configure HA:\n1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3.\n2. Configure the three connected MQ Appliance ports (on both appliances) as follows:\n\nInterface  Purpose                                                 IP address/CIDR\neth1           HA group primary interface          x.x.x.x/24\neth2           HA group alternative interface   x.x.x.x/24\neth3           HA Replication interface               x.x.x.x/24\n\nOn the second appliance, enter the following command from the MQ Appliance CLI:\nprepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout]\n\nOn the first appliance, enter the following command:\ncrthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance]\ncrtmqm [HA QM name] –p [port] –sx\n\nNote: The queue manager’s data (queues, queue messages, etc.) is replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).","ccis":["CCI-001851"]},{"vulnId":"V-255816","ruleId":"SV-255816r960759_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server must use encryption strength in accordance with the categorization of the management data during remote access management sessions.","description":"Remote management access is accomplished by leveraging common communication protocols and establishing a remote connection to the messaging server via a network for the purposes of managing the messaging server. If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. \n\nTypes of management interfaces utilized by a messaging server include web-based HTTPS interfaces as well as command line-based management interfaces.","checkContent":"To access the MQ Appliance CLI, enter:\nmqcli\n\nconfig \ncrypto\nshow crypto-mode\n\nIf the current setting is set to \"permissive\", this is a finding.","fixText":"To set management access to the highest encryption strength, enable FIPS 140-2 Level 1 mode at the next reload of the firmware.\nEnter the following commands:\nconfig\ncrypto\ncrypto-mode-set fips-140-2-l1\nPress \"Enter\"\n\nThe following message will appear:\n\"Crypto Mode Successfully set to fips-140-2-l1 for next boot.\"","ccis":["CCI-000068"]},{"vulnId":"V-255817","ruleId":"SV-255817r961620_rule","severity":"medium","ruleTitle":"The MQ Appliance messaging server, when categorized as a high level system, must be in a high-availability (HA) cluster.","description":"A high level system is a system that handles data vital to the organization's operational readiness or effectiveness of deployed or contingency forces.  A high level system must maintain the highest level of integrity and availability.  By HA clustering the messaging server, the hosted application and data are given a platform that is load-balanced and provided high-availability.\n\nRudimentary instructions for determining if HA is set up are included here. To ensure proper configuration, system HA design steps must be taken and implemented. Reference vendor documentation for complete instructions on setting up HA: https://ibm.biz/BdicC7\n\nNote: The queue manager’s data (queues, queue messages etc.) are replicated from the appliance in the primary HA role (first appliance) to the appliance in the secondary HA role (second appliance).","checkContent":"Request and review system documentation identifying the system categorization level.  If the system categorization is not high, this requirement is NA.  \n\nAsk for and review the HA configuration.\n\nOn the either member of the HA pair:\nEstablish an SSH command line session as an admin user.\n\nTo access the MQ Appliance CLI, enter:\nmqcli\n\nTo run the dspmq command, enter:\ndspmq -s -o ha \n\nEach queue manager that is properly configured for HA should show HA(Replicated). \n\nIf it does not, this is a finding.","fixText":"To configure HA:\n1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3.\n2. Configure the three connected MQ Appliance ports (on both appliances) as follows:\n\nInterface  Purpose                                                 IP address/CIDR\neth1           HA group primary interface          x.x.x.x/24\neth2           HA group alternative interface   x.x.x.x/24\neth3           HA Replication interface               x.x.x.x/24\n\nOn the second appliance, enter the following command from the MQ Appliance CLI:\nprepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout]\n\nOn the first appliance, enter the following command:\ncrthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance]\n\nOn the first appliance, stop the first queue manager to be HA enabled:\nendmqm [name of queue manager]\n\nSet an HA group:\nsethagrp -i [name of queue manager]","ccis":["CCI-002385"]}]}