DoD Compliance · STIG

IBM MQ Appliance V9.0 AS Security Technical Implementation Guide

V1R2 · · 1.8 years ago · Released 24 Jul 2024 · 43 rules

Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.

Digest of Updates vs. V1R1 · 05 Jun 2017 +43 −43

Comparison against the immediately-prior release (V1R1). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Added rules 43

V-255775 Medium 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.
V-255776 Medium The MQ Appliance messaging server must implement cryptography mechanisms to protect the integrity of the remote access session.
V-255777 Medium The MQ Appliance messaging server must off-load log records onto a different system or media from the system being logged.
V-255778 Low 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.
V-255779 Low The MQ Appliance messaging server must compare internal MQ Appliance messaging server clocks at least every 24 hours with an authoritative time source.
V-255780 Medium 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.
V-255781 Medium The MQ Appliance WebGUI interface to the messaging server must prohibit the use of cached authenticators after one hour.
V-255782 Medium The MQ Appliance messaging server must produce log records containing information to establish what type of events occurred.
V-255783 Medium The MQ Appliance messaging server must identify potentially security-relevant error conditions.
V-255784 Medium 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.
V-255785 Medium The MQ Appliance messaging server must alert the SA and ISSO, at a minimum, in the event of a log processing failure.
V-255786 Medium 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.
V-255787 Medium 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.
V-255788 Medium The MQ Appliance messaging server must automatically terminate a SSH user session after organization-defined conditions or trigger events requiring a session disconnect.
V-255789 Medium The MQ Appliance must automatically terminate a WebGUI user session after 600 seconds of idle time.
V-255790 Medium The MQ Appliance SSH interface to the messaging server must prohibit the use of cached authenticators after 600 seconds.
V-255791 Medium 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.
V-255792 Medium The version of MQ Appliance messaging server running on the system must be a supported version.
V-255793 Medium The MQ Appliance messaging server must use DoD- or CNSS-approved PKI Class 3 or Class 4 certificates.
V-255794 Low The MQ Appliance messaging server must accept FICAM-approved third-party credentials.
V-255795 Medium The MQ Appliance messaging server must provide a log reduction capability that supports on-demand reporting requirements.
V-255796 Medium The MQ Appliance messaging server must be configured to fail over to another system in the event of log subsystem failure.
V-255797 Medium The MQ Appliance messaging server must uniquely identify all network-connected endpoint devices before establishing any connection.
V-255798 Medium Access to the MQ Appliance messaging server must utilize encryption when using LDAP for authentication.
V-255799 Medium The MQ Appliance messaging server must map the authenticated identity to the individual messaging user or group account for PKI-based authentication.
V-255800 Medium The MQ Appliance must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.
V-255801 Medium 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).
V-255802 Medium The MQ Appliance messaging server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
V-255803 Medium The MQ Appliance messaging server must generate log records for access and authentication events.
V-255804 Medium The MQ Appliance messaging server must ensure authentication of both SSH client and server during the entire session.
V-255805 Medium The MQ Appliance messaging server must generate a unique session identifier using a FIPS 140-2 approved random number generator.
V-255806 Medium The MQ Appliance messaging server must authenticate all network-connected endpoint devices before establishing any connection.
V-255807 High 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.
V-255808 Medium MQ Appliance messaging servers must use NIST-approved or NSA-approved key management technology and processes.
V-255809 Medium The MQ Appliance messaging server must utilize FIPS 140-2 approved encryption modules when authenticating users and processes.
V-255810 Medium The MQ Appliance messaging server must protect the confidentiality and integrity of transmitted information through the use of an approved TLS version.
V-255811 Medium The MQ Appliance messaging server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.
V-255812 Medium The MQ Appliance messaging server must employ approved cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission.
V-255813 Medium The MQ Appliance messaging server must provide a clustering capability.
V-255814 Medium 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.
V-255815 Medium 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.
V-255816 Medium The MQ Appliance messaging server must use encryption strength in accordance with the categorization of the management data during remote access management sessions.
V-255817 Medium The MQ Appliance messaging server, when categorized as a high level system, must be in a high-availability (HA) cluster.

Removed rules 43

V-74727 Medium 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.
V-74729 Medium The MQ Appliance messaging server must implement cryptography mechanisms to protect the integrity of the remote access session.
V-74741 Medium The MQ Appliance messaging server must off-load log records onto a different system or media from the system being logged.
V-74743 Low 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.
V-74745 Low The MQ Appliance messaging server must compare internal MQ Appliance messaging server clocks at least every 24 hours with an authoritative time source.
V-74747 Medium 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.
V-74749 Medium The MQ Appliance WebGUI interface to the messaging server must prohibit the use of cached authenticators after one hour.
V-74801 Medium 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.
V-74805 Medium The MQ Appliance messaging server must automatically terminate a SSH user session after organization-defined conditions or trigger events requiring a session disconnect.
V-74813 Medium The MQ Appliance must automatically terminate a WebGUI user session after 600 seconds of idle time.
V-74815 Medium The MQ Appliance SSH interface to the messaging server must prohibit the use of cached authenticators after 600 seconds.
V-74831 Medium The MQ Appliance messaging server must install security-relevant software updates within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).
V-74835 Medium The MQ Appliance messaging server must use DoD- or CNSS-approved PKI Class 3 or Class 4 certificates.
V-74847 Medium The MQ Appliance messaging server, when categorized as a high level system, must be in a high-availability (HA) cluster.
V-74849 Medium The MQ Appliance messaging server must use encryption strength in accordance with the categorization of the management data during remote access management sessions.
V-74851 Medium 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.
V-74853 Medium 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.
V-74859 Medium The MQ Appliance messaging server must employ approved cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission.
V-74861 Medium The MQ Appliance messaging server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.
V-74863 Medium The MQ Appliance messaging server must protect the confidentiality and integrity of transmitted information through the use of an approved TLS version.
V-74877 Medium The MQ Appliance messaging server must produce log records containing information to establish what type of events occurred.
V-74879 Medium The MQ Appliance messaging server must identify potentially security-relevant error conditions.
V-74883 Medium The MQ Appliance messaging server must alert the SA and ISSO, at a minimum, in the event of a log processing failure.
V-74885 Medium 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.
V-74887 Low The MQ Appliance messaging server must accept FICAM-approved third-party credentials.
V-74889 Medium The MQ Appliance messaging server must provide a log reduction capability that supports on-demand reporting requirements.
V-74891 Medium The MQ Appliance messaging server must be configured to fail over to another system in the event of log subsystem failure.
V-74893 Medium The MQ Appliance messaging server must provide a clustering capability.
V-74895 Medium The MQ Appliance messaging server must ensure authentication of both SSH client and server during the entire session.
V-74897 Medium The MQ Appliance messaging server must uniquely identify all network-connected endpoint devices before establishing any connection.
V-74899 Medium Access to the MQ Appliance messaging server must utilize encryption when using LDAP for authentication.
V-74901 Medium The MQ Appliance messaging server must map the authenticated identity to the individual messaging user or group account for PKI-based authentication.
V-74903 Medium The MQ Appliance must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.
V-74905 Medium 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).
V-74907 Medium The MQ Appliance messaging server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
V-74909 Medium The MQ Appliance messaging server must generate log records for access and authentication events.
V-74911 Medium The MQ Appliance messaging server must generate a unique session identifier using a FIPS 140-2 approved random number generator.
V-74913 Medium The MQ Appliance messaging server must authenticate all network-connected endpoint devices before establishing any connection.
V-74915 High 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.
V-74917 Medium MQ Appliance messaging servers must use NIST-approved or NSA-approved key management technology and processes.
V-74919 Medium The MQ Appliance messaging server must utilize FIPS 140-2 approved encryption modules when authenticating users and processes.
V-74921 Medium 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.
V-75029 Medium 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.

Sort by

Expand all

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.

AU-10 - Medium - CCI-000166 - V-255775 - SV-255775r960864_rule

RMF Control

AU-10

Severity

CCI

CCI-000166

Version

MQMH-AS-000010

Vuln IDs

V-255775
V-74727

Rule IDs

SV-255775r960864_rule
SV-89401

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. Non-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. Typical messaging server actions requiring non-repudiation will be related to application deployment among developers/users and administrative actions taken by admin personnel.

Checks: C-59448r875928_chk

Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq To run the "runmqsc [queue mgr name]" command for each running queue manager enter: DIS QMGR EVENT A list of all events will be displayed along with an indication if event logging is enabled. The events are as follows: Authority: 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 If AUTHOREV event logging is not enabled, this is a finding.

Fix: F-59391r875929_fix

To access the MQ Appliance CLI, enter: mqcli runmqsc [queue mgr name] ALTER QMGR [AUTHOREV](ENABLED) To exit the MQ Appliance CLI, enter: end

The MQ Appliance messaging server must implement cryptography mechanisms to protect the integrity of the remote access session.

SC-28 - Medium - CCI-001199 - V-255776 - SV-255776r960762_rule

RMF Control

SC-28

Severity

CCI

CCI-001199

Version

MQMH-AS-000020

Vuln IDs

V-255776
V-74729

Rule IDs

SV-255776r960762_rule
SV-89403

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. Messaging 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. FIPS 140-2 approved TLS versions include TLS V1.0 or greater. FIPS 140-2 approved TLS versions must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. Satisfies: 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

Checks: C-59449r875931_chk

Obtain queue security policy requirements from system admin. To verify the Advanced Message Security (AMS) policy for a specific queue manager's queues, enter: mqcli To list the policies for each queue, enter: runmqsc [QMgrName] To display all policies, enter: DIS POLICY(*) If no security policies are found or the specifics of the security policy does not meet documented queue security requirements, this is a finding.

Fix: F-59392r875932_fix

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. To access the MQ Appliance CLI, enter: mqcli runmqsc [QMgrName] SET POLICY([queue name]) SIGNALG([SHA256, SHA384, or SHA512]) + ENCALG([3DES, AES128, or AES256]) + RECIP(['distinguished name (DN) of the message recipient']) + SIGNER(['Signature DN validated during message retrieval']) end

The MQ Appliance messaging server must off-load log records onto a different system or media from the system being logged.

AU-4 - Medium - CCI-001851 - V-255777 - SV-255777r961395_rule

RMF Control

AU-4

Severity

CCI

CCI-001851

Version

MQMH-AS-000150

Vuln IDs

V-255777
V-74741

Rule IDs

SV-255777r961395_rule
SV-89415

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. Off-loading is a common process in information systems with limited log storage capacity. Centralized 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. An HA configuration provides real-time synchronous replication of the logs to a mirrored MQ Appliance.

Checks: C-59450r875934_chk

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. Perform on each member of the HA pair. To access the MQ Appliance CLI, enter: mqcli dspmq -s -o ha One of the appliances should be running as primary, the other as secondary. If 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.

Fix: F-59393r875935_fix

To configure HA: 1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3. 2. Configure the three connected MQ Appliance ports (on both appliances) as follows: Interface Purpose IP address/CIDR eth1 HA group primary interface x.x.x.x/24 eth2 HA group alternative interface x.x.x.x/24 eth3 HA Replication interface x.x.x.x/24 On the second appliance, enter the following command from the MQ Appliance CLI: prepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout] On the first appliance, enter the following command from the MQ Appliance CLI: crthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance] crtmqm [HA QM name] –p [port] –sx Note: 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).

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.

AU-8 - Low - CCI-002046 - V-255778 - SV-255778r981686_rule

RMF Control

AU-8

Severity

CCI

CCI-002046

Version

MQMH-AS-000160

Vuln IDs

V-255778
V-74743

Rule IDs

SV-255778r981686_rule
SV-89417

Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events. Synchronization 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.

Checks: C-59451r875937_chk

Log on as a privileged user to the WebGUI. Select Network icon. Interface NTP Service. Verify that refresh interval is set to "600" seconds. If refresh interval is not set to "600" seconds, this is a finding.

Fix: F-59394r875938_fix

Log on as a privileged user to the WebGUI. Select the Network icon. Interface NTP Service. Set refresh interval to "600" seconds. Click "Save configuration".

The MQ Appliance messaging server must compare internal MQ Appliance messaging server clocks at least every 24 hours with an authoritative time source.

AU-8 - Low - CCI-001891 - V-255779 - SV-255779r981685_rule

RMF Control

AU-8

Severity

CCI

CCI-001891

Version

MQMH-AS-000170

Vuln IDs

V-255779
V-74745

Rule IDs

SV-255779r981685_rule
SV-89419

Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events. Synchronization 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.

Checks: C-59452r875940_chk

Log on as a privileged user to the WebGUI. Select Network icon. Interface NTP Service. Verify: - NTP server destinations are configured. - "Enable Administrative state" box is checked. If "Enable Administrative state" is not checked or if no NTP servers are defined, this is a finding.

Fix: F-59395r875941_fix

Log on as a privileged user to the WebGUI. Select the Network icon. Interface NTP Service. Ensure the box next to "Enable Administrative state" has a check mark. Press the "Add" button to add multiple NTP servers. Click the "Apply" button. Add one or more additional NTP servers at least one of which is from a different geographic region. Click "Save configuration".

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.

SC-13 - Medium - CCI-002450 - V-255780 - SV-255780r962034_rule

RMF Control

SC-13

Severity

CCI

CCI-002450

Version

MQMH-AS-000180

Vuln IDs

V-255780
V-74747

Rule IDs

SV-255780r962034_rule
SV-89421

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. NSA 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: "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." NSA-approved cryptography is required to be used for classified information system processing. The messaging server must utilize NSA-approved encryption modules when protecting classified data. This means using AES and other approved encryption modules.

Checks: C-59453r875943_chk

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. For queue manager to queue manager connections: From queue manager [QM1], enter the following command: DISPLAY CHS(TO.[QM2]) SSLPEER SSLCERTI The resulting output should be like the following example: DISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI 4 : DISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(TO.[QM2]) CHLTYPE(SDR) CONNAME([IP addr QM2]) CURRENT RQMNAME([QM2]) SSLCERTI("[distinguished name]") SSLPEER("[distinguished name]") STATUS(RUNNING) SUBSTATE(MQGET) XMITQ([QM2]) From the queue manager [QM2], enter the following command: DISPLAY CHS(TO.QM2) SSLPEER SSLCERTI The resulting output is like the following example: DISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI 5 : DISPLAY CHSTATUS(TO.[QM2]) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(TO.[QM2]) CHLTYPE(SDR) CONNAME([IP addr QM1]) CURRENT RQMNAME([QM1]) SSLCERTI("[distinguished name]") SSLPEER("[distinguished name]") STATUS(RUNNING) SUBSTATE(MQGET) XMITQ( ) In 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. For client to queue manager connections: C1=client1, QM1=queue manager 1 From the queue manager [QM1], enter the following command: DISPLAY CHSTATUS([C1].TO.[QM1]) SSLPEER SSLCERTI The resulting output is like the following example: DISPLAY CHSTATUS([C1].TO.[QM1]) SSLPEER SSLCERTI 5 : DISPLAY CHSTATUS([C1].TO.[QM1]) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) CONNAME([IP addr QM1]) CURRENT SSLCERTI("[distinguished name]") SSLPEER("[distinguished name]") STATUS(RUNNING) SUBSTATE(RECEIVE) The "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. If the connections on each end of the channel are not configured as described above, this is a finding.

Fix: F-59396r875944_fix

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. 1. Prepare the key repository on each endpoint (client and/or queue manager). 2. Request a CA-signed certificate for each client and/or queue manager. You might use different CAs for the two endpoints. 3. 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. 4. Add the CA-signed certificate to the key repository for each endpoint. CHOOSE EITHER STEP 5 or 6 BELOW 5. For a queue manager to queue manager connection: a. On [QM1], define a sender channel and associated transmission queue by issuing commands like the following example: DEFINE QLOCAL([QM2]) USAGE(XMITQ) DEFINE CHANNEL(TO.[QM2]) CHLTYPE(SDR) TRPTYPE(TCP) + CONNAME([QM2 address]) XMITQ([QM2]) SSLCIPH([TLS cipher spec]) + DESCR('Sender channel using TLS from [QM1] to [QM2]') The CipherSpecs at each end of the channel must be the same. b. On [QM2], define a receiver channel by issuing a command like the following example: DEFINE CHANNEL(TO.[QM2]) CHLTYPE(RCVR) TRPTYPE(TCP) + SSLCIPH([TLS cipher spec]) SSLCAUTH(REQUIRED) + DESCR('Receiver channel using TLS to [QM2]') The channel must have the same name as the sender channel you defined in step 5.a., and use the same CipherSpec. c. Start the channel. Ref. Connecting two queue managers using SSL or TLS https://goo.gl/1GyPRV 6. For a client to queue manager connection: a. Define a client-connection channel in either of the following ways: - Using the MQCONNX call with the MQSCO structure on [client] - Using a client channel definition table b. On queue manager, define a server-connection channel by issuing a command like the following example: C1=client 1, MQ1=queue manager 1 DEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) + SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED) + DESCR('Receiver channel using TLS from [client name] to [QM name]') The channel must have the same name as the client-connection channel you defined in step 6, and use the same CipherSpec. Note: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp

The MQ Appliance WebGUI interface to the messaging server must prohibit the use of cached authenticators after one hour.

IA-5 - Medium - CCI-002007 - V-255781 - SV-255781r961521_rule

RMF Control

IA-5

Severity

CCI

CCI-002007

Version

MQMH-AS-000190

Vuln IDs

V-255781
V-74749

Rule IDs

SV-255781r961521_rule
SV-89423

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.

Checks: C-59454r875946_chk

Display the SSL Server Profile associated with the WebGUI using the (CLI). Log on as an admin to the MQ appliance using SSH terminal access. Enter: co show web-mgmt To note the name of the ssl-server, enter: crypto ssl-server <ssl-server name> show Verify the following are displayed: caching on cache-timeout 3600 If 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.

Fix: F-59397r875947_fix

Display the SSL Server Profile associated with the WebGUI (CLI). Enter: co show web-mgmt [Note the name of the ssl-server] Define the cache parameters of the SSL Server using the CLI. Enter: co crypto ssl-server <ssl-server name> caching on cache-timeout <3600> exit exit write mem y

The MQ Appliance messaging server must produce log records containing information to establish what type of events occurred.

AU-3 - Medium - CCI-000130 - V-255782 - SV-255782r960891_rule

RMF Control

AU-3

Severity

CCI

CCI-000130

Version

MQMH-AS-000210

Vuln IDs

V-255782
V-74877

Rule IDs

SV-255782r960891_rule
SV-89551

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. Log 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. Messaging 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. Satisfies: 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

Checks: C-59455r875949_chk

Apply the following check to each queue manager on the MQ Appliance. Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq To check config for each queue, enter: runmqsc [queue mgr name] At the runmqsc prompt, enter: DIS QMGR EVENT Verify the following events are enabled as required. AUTHOREV, INHIBITEV, STRSTPEV, CMDEV, SSLEV, CONFIGEV, PERFMEV If any of the required events are not enabled, this is a finding.

Fix: F-59398r875950_fix

Ensure each queue is configured to log the following event names: AUTHOREV INHIBITEV STRSTPEV CMDEV SSLEV CONFIGEV PERFMEV Use the "runmqsc" command for each queue manager. runmqsc [queue mgr name] ALTER QMGR [event name](ENABLED) Enter "end" to exit the MQ Appliance CLI.

The MQ Appliance messaging server must identify potentially security-relevant error conditions.

AU-12 - Medium - CCI-000172 - V-255783 - SV-255783r961167_rule

RMF Control

AU-12

Severity

CCI

CCI-000172

Version

MQMH-AS-000450

Vuln IDs

V-255783
V-74879

Rule IDs

SV-255783r961167_rule
SV-89553

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. The structure and content of error messages needs to be carefully considered by the organization and development team. Messaging servers must have the capability to log at various levels which can provide log entries for potential security-related error events. An 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. Instructions for using the amqsevt sample program to display instrumentation events may be found at the following URL: https://ibm.biz/BdsCzY. Satisfies: SRG-APP-000266-AS-000168, SRG-APP-000091-AS-000052

Checks: C-59456r875952_chk

Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq Run the "runmqsc [queue mgr name]" command for each running queue manager. Once at the runmqsc prompt, enter: DIS QMGR AUTHOREV AUTHOREV(ENABLED) - should be the result. If "AUTHOREV" logging is not "ENABLED", this is a finding.

Fix: F-59399r875953_fix

For each queue manager on the MQ Appliance, enable authority (AUTHOREV) event logging. From the MQ Appliance CLI, enter the following: runmqsc [queue mgr name] ALTER QMGR AUTHOREV(ENABLED) end

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.

AC-17 - Medium - CCI-000067 - V-255784 - SV-255784r961362_rule

RMF Control

AC-17

Severity

CCI

CCI-000067

Version

MQMH-AS-000480

Vuln IDs

V-255784
V-74921

Rule IDs

SV-255784r961362_rule
SV-89595

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. If privileged activity is not logged, no forensic logs can be used to establish accountability for privileged actions that occur on the system. Instructions for using the amqsevt sample program to display instrumentation events may be found at the following URL: https://ibm.biz/BdsCzY Satisfies: 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

Checks: C-59457r875955_chk

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. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq To run the "runmqsc [queue mgr name]" command for each running queue manager, enter: runmqsc [queue mgr name] DIS QMGR CONFIGEV CONFIGEV(ENABLED) - should be the result. end If "CONFIGEV" is not "ENABLED", this is a finding.

Fix: F-59400r875956_fix

For each queue manager on the MQ Appliance, enable configuration event logging (CONFIGEV). From the MQ Appliance CLI, enter the following: runmqsc [queue mgr name] ALTER QMGR CONFIGEV(ENABLED) end

The MQ Appliance messaging server must alert the SA and ISSO, at a minimum, in the event of a log processing failure.

AU-5 - Medium - CCI-000139 - V-255785 - SV-255785r960912_rule

RMF Control

AU-5

Severity

CCI

CCI-000139

Version

MQMH-AS-000610

Vuln IDs

V-255785
V-74883

Rule IDs

SV-255785r960912_rule
SV-89557

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. Log 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. It is the responsibility of the MQ system administrator to monitor the SYSTEM.ADMIN.PERFM.EVENT queue and provide appropriate notification. All MQ installations provide a sample program, amqsevt. This program reads messages from event queues, and formats them into readable strings. An 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 Note: Any MQ monitoring solution that connects to MQ as a client may be used to monitor event queues. Satisfies: SRG-APP-000108-AS-000067, SRG-APP-000360-AS-000066

Checks: C-59458r875958_chk

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. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq To run the "runmqsc [queue mgr name]" command for each running queue manager identified, enter: runmqsc [queue mgr name] DIS QMGR PERFMEV DIS QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV end If "QDPHIEV" or "PERFMEV" is not "ENABLED", this is a finding. Ask the system administrator to demonstrate how they monitor an alert on MQ failure events. Verify alarming is set for the following log events: MQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH If 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.

Fix: F-59401r875959_fix

For each queue manager on the MQ Appliance, enable performance (PERFMEV) event logging. From the MQ Appliance CLI, enter the following: runmqsc [queue mgr name] ALTER QMGR PERFMEV(ENABLED) ALTER QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV(ENABLED) Monitor the logs that send alerts based on the following failure codes: MQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH.

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.

AU-5 - Medium - CCI-001855 - V-255786 - SV-255786r961398_rule

RMF Control

AU-5

Severity

CCI

CCI-001855

Version

MQMH-AS-000640

Vuln IDs

V-255786
V-74801

Rule IDs

SV-255786r961398_rule
SV-89475

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.

Checks: C-59459r875961_chk

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. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq To run the "runmqsc [queue mgr name]" command for each running queue manager identified, enter: runmqsc [queue mgr name] DIS QMGR PERFMEV DIS QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV end If "QDEPTHHI" is not "75", this is a finding. Ask the system administrator to demonstrate how they monitor an alert on MQ failure events. Verify alarming is set for the following log events: MQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH If 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.

Fix: F-59402r875962_fix

For each queue manager on the MQ Appliance, enable performance (PERFMEV) event logging. From the MQ Appliance CLI, enter the following: runmqsc [queue mgr name] ALTER QMGR PERFMEV(ENABLED) ALTER QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDPHIEV(ENABLED) ALTER QLOCAL(SYSTEM.ADMIN.PERFM.EVENT) QDEPTHHI(75) Monitor the logs and send alerts based on the following failure codes: MQRC_Q_FULL, MQRC_Q_MGR_NOT_ACTIVE, MQRC_Q_DEPTH_HIGH.

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.

AC-10 - Medium - CCI-000054 - V-255787 - SV-255787r961620_rule

RMF Control

AC-10

Severity

CCI

CCI-000054

Version

MQMH-AS-000650

Vuln IDs

V-255787
V-74885

Rule IDs

SV-255787r961620_rule
SV-89559

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. There 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. Note: 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 For internal queue managers, You can restrict the total number of incoming connections by setting the MaxConnectionThreads property: https://ibm.biz/BdraMZ Satisfies: SRG-APP-000435-AS-000163, SRG-APP-000001-AS-000001

Checks: C-59460r875964_chk

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. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq To run the "runmqsc [queue mgr name]" command for each running queue manager identified, enter: runmqsc [queue mgr name] To display available SVRCONN channels details, enter: DIS CHANNEL(*) CHLTYPE(SVRCONN) Display values for each channel: DIS CHANNEL(Channel Name) If the value of either "MAXINST" or "MAXINSTC" is greater than the organization-defined limit, this is a finding.

Fix: F-59403r875965_fix

For each queue manager's server connection (SVRCONN) channel(s): To access the MQ Appliance CLI, enter: mqcli runmqsc <queue manager name> >> To display available SVRCONN channels, enter: DIS CHANNEL(*) CHLTYPE(SVRCONN) ALTER CHANNEL(<svrconn channel name>) CHLTYPE(SVRCONN) MAXINST(max allowed channel instances) MAXINSTC(max allowed channels for same client: less than MAXINST) end

The MQ Appliance messaging server must automatically terminate a SSH user session after organization-defined conditions or trigger events requiring a session disconnect.

AC-12 - Medium - CCI-002361 - V-255788 - SV-255788r961221_rule

RMF Control

AC-12

Severity

CCI

CCI-002361

Version

MQMH-AS-000680

Vuln IDs

V-255788
V-74805

Rule IDs

SV-255788r961221_rule
SV-89479

An attacker can take advantage of CLI user sessions that are left open, thus bypassing the user authentication process. To 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. Session 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. Conditions 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.

Checks: C-59461r875967_chk

To access the MQ Appliance CLI, enter: mqcli show rbm Verify that the cli-timeout displays the approved timeout value of 600 seconds (10 minutes) or less. If it does not, this is a finding.

Fix: F-59404r875968_fix

For the CLI used by the administrator, log on to the MQ Appliance CLI as a privileged user. Enter: co rbm cli-timeout 600 exit write mem y

The MQ Appliance must automatically terminate a WebGUI user session after 600 seconds of idle time.

AC-12 - Medium - CCI-002361 - V-255789 - SV-255789r961221_rule

RMF Control

AC-12

Severity

CCI

CCI-002361

Version

MQMH-AS-000720

Vuln IDs

V-255789
V-74813

Rule IDs

SV-255789r961221_rule
SV-89487

An attacker can take advantage of WebGUI user sessions that are left open, thus bypassing the user authentication process. To 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. Session 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. Conditions 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.

Checks: C-59462r875970_chk

Log on to the MQ Appliance CLI as a privileged user. To access the MQ Appliance CLI, enter: mqcli To enter configuration mode, enter: co web-mgmt show If the idle-timeout value is not "600" seconds or less, this is a finding.

Fix: F-59405r875971_fix

Log on to the MQ Appliance CLI as a privileged user. To access the MQ Appliance CLI, enter: mqcli To enter configuration mode, enter: co web-mgmt idle-timeout <600 seconds or less> exit write mem y

The MQ Appliance SSH interface to the messaging server must prohibit the use of cached authenticators after 600 seconds.

IA-5 - Medium - CCI-002007 - V-255790 - SV-255790r961521_rule

RMF Control

IA-5

Severity

CCI

CCI-002007

Version

MQMH-AS-000730

Vuln IDs

V-255790
V-74815

Rule IDs

SV-255790r961521_rule
SV-89489

Checks: C-59463r875973_chk

In the MQ Appliance WebGUI, Go to Administration (gear icon) >> Access >> RBM Settings. Verify that cache setting is defined and specifies "600" seconds. If the time period is not set to "600" seconds, this is a finding.

Fix: F-59406r875974_fix

In the MQ Appliance WebGUI, Go to Administration (gear icon) >> Access >> RBM Settings. Limit cache settings to "600" seconds.

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.

SC-23 - Medium - CCI-002470 - V-255791 - SV-255791r961596_rule

RMF Control

SC-23

Severity

CCI

CCI-002470

Version

MQMH-AS-000790

Vuln IDs

V-255791
V-75029

Rule IDs

SV-255791r961596_rule
SV-89703

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

Checks: C-59464r875976_chk

From the MQ Appliance WebGUI, click on the Administration (gear) icon. Click on Main >> File Management. Click on the cert directory. Click on the "Details" action to the right of each cert to display its attributes. Verify that each certificate attribute meets organizationally approved requirements. If any certificates have not been issued by a DoD- or CNSS-approved PKI CA, this is a finding.

Fix: F-59407r875977_fix

Install certificates that have been issued by a DoD CA.

The version of MQ Appliance messaging server running on the system must be a supported version.

SI-2 - Medium - CCI-002605 - V-255792 - SV-255792r1001151_rule

RMF Control

SI-2

Severity

CCI

CCI-002605

Version

MQMH-AS-000810

Vuln IDs

V-255792
V-74831

Rule IDs

SV-255792r1001151_rule
SV-89505

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. Organization-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). This 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. The 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).

Checks: C-59465r1001150_chk

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.

Fix: F-59408r991676_fix

Upgrade to a supported version.

The MQ Appliance messaging server must use DoD- or CNSS-approved PKI Class 3 or Class 4 certificates.

SC-13 - Medium - CCI-002450 - V-255793 - SV-255793r961857_rule

RMF Control

SC-13

Severity

CCI

CCI-002450

Version

MQMH-AS-000830

Vuln IDs

V-255793
V-74835

Rule IDs

SV-255793r961857_rule
SV-89509

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.

Checks: C-59466r875982_chk

Fix: F-59409r875983_fix

Install approved certificates that have been issued by a DoD CA.

The MQ Appliance messaging server must accept FICAM-approved third-party credentials.

IA-8 - Low - CCI-002011 - V-255794 - SV-255794r981695_rule

RMF Control

IA-8

Severity

CCI

CCI-002011

Version

MQMH-AS-000840

Vuln IDs

V-255794
V-74887

Rule IDs

SV-255794r981695_rule
SV-89561

Access may be denied to legitimate users if FICAM-approved third-party credentials are not accepted. This 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. Third-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. Satisfies: SRG-APP-000404-AS-000249, SRG-APP-000405-AS-000250

Checks: C-59467r875985_chk

Log on to the WebGUI as a privileged user. Click on the "MQ Console" icon. Click "Add" widget at the top right of the screen. Select queue manager intended for OCSP from the drop-down list. Select "Authentication Information". Verify that the authentication type is "OCSP". Click on the "Properties" button. Click "OCSP" on the side bar to verify that the OCSP responder URL is correct. If either the authentication type is not "OCSP" or the OCSP responder URL in not correct, this is a finding.

Fix: F-59410r875986_fix

Log on to the WebGUI as a privileged user. Click on the "MQ Console" icon. Click "Add" widget at the top right of the screen. Select a queue manager from the drop-down list. Select "Authentication Information". Click the "+" (plus sign) to define the authentication method authentication for this queue manager. Specify an "Authinfo" name (e.g., USE.OCSP). Select "OCSP" as the "Authinfo" type. Specify an OCSP responder URL. Click "Create". In the "Local Queue Managers" widget, select the OCSP queue manager you just configured. Click "More..." then select "Refresh Security... "

The MQ Appliance messaging server must provide a log reduction capability that supports on-demand reporting requirements.

AU-7 - Medium - CCI-001876 - V-255795 - SV-255795r961056_rule

RMF Control

AU-7

Severity

CCI

CCI-001876

Version

MQMH-AS-000870

Vuln IDs

V-255795
V-74889

Rule IDs

SV-255795r961056_rule
SV-89563

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. Log 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. To 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. Instructions for using the amqsevt sample program to display instrumentation events may be found at the following URL: https://ibm.biz/BdsCzY Satisfies: SRG-APP-000181-AS-000255, SRG-APP-000355-AS-000055

Checks: C-59468r875988_chk

Confirm that the following command is available and functioning on an authorized MQ client device: amqsevt -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] If an MQ client application is not enabled to monitor one or more of the above event queues, this is a finding.

Fix: F-59411r875989_fix

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: amqsevt -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] Note: Any MQ monitoring solution that can connect to MQ as a client may be used to monitor event queues.

The MQ Appliance messaging server must be configured to fail over to another system in the event of log subsystem failure.

AU-5 - Medium - CCI-000140 - V-255796 - SV-255796r960915_rule

RMF Control

AU-5

Severity

CCI

CCI-000140

Version

MQMH-AS-000900

Vuln IDs

V-255796
V-74891

Rule IDs

SV-255796r960915_rule
SV-89565

This requirement is dependent upon system MAC and availability. If the system MAC and availability do not specify redundancy requirements, this requirement is NA. It 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. Messaging 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. 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 Satisfies: SRG-APP-000109-AS-000070, SRG-APP-000109-AS-000068, SRG-APP-000125-AS-000084

Checks: C-59469r875991_chk

In the event of a MQ queue manager failure, an HA configuration must be used. Obtain system documentation identifying the HA configuration. Establish an SSH command line session to either of the pair as an admin user. To access the MQ Appliance CLI, enter: mqcli To run the dspmq command, enter: dspmq -s -o ha Each queue manager that is properly configured for HA should show HA(Replicated). If it does not, this is a finding.

Fix: F-59412r875992_fix

Rudimentary instructions for setting up HA are included here. 1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3. 2. Configure the three connected MQ Appliance ports (on both appliances) as follows: Interface Purpose IP address/CIDR eth1 HA group primary interface x.x.x.x/24 eth2 HA group alternative interface x.x.x.x/24 eth3 HA Replication interface x.x.x.x/24 On the second appliance, enter the following command from the MQ Appliance CLI: prepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout] On the first appliance, enter the following command: crthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance] On the first appliance, stop the first queue manager to be HA enabled: endmqm [name of queue manager] Set an HA group: sethagrp -i [name of queue manager] Note: 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).

The MQ Appliance messaging server must uniquely identify all network-connected endpoint devices before establishing any connection.

IA-3 - Medium - CCI-000778 - V-255797 - SV-255797r1000054_rule

RMF Control

IA-3

Severity

CCI

CCI-000778

Version

MQMH-AS-001000

Vuln IDs

V-255797
V-74897

Rule IDs

SV-255797r1000054_rule
SV-89571

Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. For 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

Checks: C-59470r875994_chk

Check that TLS mutual authentication configuration is correct by using "DISPLAY" commands. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] To display available SVRCONN channels details, enter: DIS CHANNEL(*) CHLTYPE(SVRCONN) Note the names of SVRCONN channels (client channels). Display values for each channel: DIS CHANNEL([name of SVRCONN channel]) Confirm that the parameter "SSLCIPH" specifies a FIPS approved cipher spec and that the value of "SSLAUTH" is set to "REQUIRED". MQ cipher specs are available here: https://ibm.biz/BdrJGp Utilize a FIPS approved cipher when specifying SSLCIPH. If either the "SSLCIPH" or "SSLAUTH" value for each channel is not correct, this is a finding.

Fix: F-59413r875995_fix

Run the fix for each affected queue manager and each affected channel. To access the MQ Appliance enter: mqcli runmqsc [queue name] ALTER CHANNEL([channel name] CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCIPH([Use FIPS Approved cipher specs only]) SSLCAUTH(REQUIRED) Enter "end" to exit runmqsc mode.

Access to the MQ Appliance messaging server must utilize encryption when using LDAP for authentication.

IA-5 - Medium - CCI-000197 - V-255798 - SV-255798r961029_rule

RMF Control

IA-5

Severity

CCI

CCI-000197

Version

MQMH-AS-001010

Vuln IDs

V-255798
V-74899

Rule IDs

SV-255798r961029_rule
SV-89573

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. Messaging 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. Note: Multiple alternative LDAP hosts may be listed in the CONNAME parameter, separated by commas. Review IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server. See https://ibm.biz/BdiBGu and https://ibm.biz/BdixXz for a detailed description of these options.

Checks: C-59471r875997_chk

To access the MQ Appliance CLI, for each queue manager, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] To display the active authentication object, enter: DIS QMGR CONNAUTH Result: QMNAME([queue mgr name]) CONNAUTH([auth object name]) DIS AUTHINFO(auth object name) Verify that "AUTHTYPE(IDPWLDAP)", and "SECCOMM(YES)" are displayed, and that all parameters are correctly specified to use the organizationally approved LDAP server(s). If these parameter values cannot be verified, this is a finding.

Fix: F-59414r875998_fix

Specify LDAP as the authentication method for each queue manager. To access the MQ Appliance CLI, enter: mqcli runmqsc [queue manager name] DEFINE AUTHINFO('[Object name e.g., USE.LDAP]') AUTHTYPE(IDPWLDAP) CONNAME('[ldap1(port),ldap2(port),ldap3(port)]') SECCOMM(YES) [Ensures encryption is used] SHORTUSR('[short user name]') CHCKCLNT(REQUIRED) BASEDNU('base user DN') REPLACE ALTER QMGR CONNAUTH('[AUTHINFO object name]') REFRESH SECURITY TYPE(CONNAUTH) Type "end" to exit runmqsc mode.

The MQ Appliance messaging server must map the authenticated identity to the individual messaging user or group account for PKI-based authentication.

IA-5 - Medium - CCI-000187 - V-255799 - SV-255799r961044_rule

RMF Control

IA-5

Severity

CCI

CCI-000187

Version

MQMH-AS-001020

Vuln IDs

V-255799
V-74901

Rule IDs

SV-255799r961044_rule
SV-89575

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. Messaging servers must provide the capability to utilize and meet requirements of the DoD Enterprise PKI infrastructure for application authentication. Note: Two or more alternative LDAP hosts may be listed, in the CONNAME parameter, separated by commas. Review IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server. See https://ibm.biz/BdiBGu for a detailed description of these options.

Checks: C-59472r876000_chk

To access the MQ Appliance CLI, for each queue manager, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] DIS AUTHINFO(*) AUTHTYPE(CRLLDAP) CONNAME Verify 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. If the "AUTHINFO" definition is not equal to "AUTHTYPE(CRLLDAP)", this is a finding.

Fix: F-59415r876001_fix

The MQ Appliance must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

IA-4 - Medium - CCI-000795 - V-255800 - SV-255800r981681_rule

RMF Control

IA-4

Severity

CCI

CCI-000795

Version

MQMH-AS-001080

Vuln IDs

V-255800
V-74903

Rule IDs

SV-255800r981681_rule
SV-89577

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. Applications need to track periods of inactivity and disable application identifiers after 35 days of inactivity. Management 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. To 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. Review IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server. Note: Multiple alternative LDAP hosts may be listed in the CONNAME parameter, separated by commas. Review IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server. See https://ibm.biz/BdiBGu and https://ibm.biz/BdixXz for a detailed description of these options.

Checks: C-59473r876003_chk

To access the MQ Appliance CLI, for each queue manager, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] To display the active authentication object, enter: DIS QMGR CONNAUTH Result: QMNAME([queue mgr name]) CONNAUTH([auth object name]) DIS AUTHINFO(auth object name) Verify that "AUTHTYPE(IDPWLDAP)" is displayed. Verify LDAP server user settings are configured to disable accounts after "35" days of inactivity. If "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.

Fix: F-59416r876004_fix

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

IA-2 - Medium - CCI-000764 - V-255801 - SV-255801r960969_rule

RMF Control

IA-2

Severity

CCI

CCI-000764

Version

MQMH-AS-001090

Vuln IDs

V-255801
V-74905

Rule IDs

SV-255801r960969_rule
SV-89579

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. To ensure support to the enterprise, the authentication must utilize an enterprise solution. Review IBM product documentation for the LDAP fields required when setting up a communication link with the LDAP server. See https://ibm.biz/BdsRRk for a detailed description of these options.

Checks: C-59474r876006_chk

To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] DIS AUTHINFO(USE.LDAP) Verify that "AUTHINFO(USE.LDAP)" is displayed under authentication information details. If "IBM MQ Appliance object USE.LDAP not found" is displayed, this is a finding.

Fix: F-59417r876007_fix

Specify LDAP as the authentication method for each queue manager. To access the MQ Appliance CLI, enter: mqcli runmqsc [queue manager name] DEFINE AUTHINFO(USE.LDAP) AUTHTYPE(CRLLDAP) CONNAME('[host name1(port)],[host name1(port)]') ALTER QMGR CONNAUTH('USE.LDAP') REFRESH SECURITY TYPE(CONNAUTH) Enter "end" to exit runmqsc mode.

The MQ Appliance messaging server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.

AC-8 - Medium - CCI-000048 - V-255802 - SV-255802r960843_rule

RMF Control

AC-8

Severity

CCI

CCI-000048

Version

MQMH-AS-001100

Vuln IDs

V-255802
V-74907

Rule IDs

SV-255802r960843_rule
SV-89581

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: (i) users are accessing a U.S. Government information system; (ii) system usage may be monitored, recorded, and subject to audit; (iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and (iv) the use of the system indicates consent to monitoring and recording. System use notification messages can be implemented in the form of warning banners displayed when individuals log on to the information system. System 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. Use 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". "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -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. -At any time, the USG may inspect and seize data stored on this IS. -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. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -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."

Checks: C-59475r876009_chk

Using a browser, navigate to the MQ Appliance logon page as a privileged user. Verify the logon page displays the Standard Mandatory DoD Notice and Consent Banner: For the WebGUI, the banner must read: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -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. -At any time, the USG may inspect and seize data stored on this IS. -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. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -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. Logging in signifies acceptance of this agreement." For the SSH CLI, the banner must read: "I've read & consent to terms in IS user agreem't. Logging in signifies acceptance of this agreement." If the standard banner is not displayed in both the WebGUI and CLI interfaces, this is a finding.

Fix: F-59418r876010_fix

The custom banner must be set up as follows: 1. Log on to the WebGUI as a privileged user. 2. Click on the Administration (gear) icon. 3. Under Main, click on File Management. 4. Open the "Store" directory. 5. Scroll down to the file, "dp-user-interface-demo.xml". 6. Click in the box to the left of the file name. 7. At the top of the page, click on the Copy button. 8. Select "local:" as the New Directory Name. 9. Enter a New File Name e.g., "ui-customization.xml". 10. Click Confirm copy. 11. Click Continue. 12. Edit the "ui-customization.xml" file. 13. Refresh the browser page. 14. Click "local:". 15. Click the "Edit" link to the right of "ui-customization.xml". 16. Click the "Edit" button. 17. Locate the XML Stanza named "MarkupBanner". 18. 'type="pre-login"'. 19. Replace the existing text with the text of the Standard Mandatory DoD Notice and Consent Banner: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -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. -At any time, the USG may inspect and seize data stored on this IS. -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. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -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. Logging in signifies acceptance of this agreement." 20. Locate the XML Stanza named "TextBanner". 21. 'type="pre-login"' 22. 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. Logging in signifies acceptance of this agreement." 23. Click the "Submit" button. 24. 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. 25. 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. 26. Scroll to top of the page. 27. Click "Apply". 28. Click "Save Configuration". Log off of the appliance.

The MQ Appliance messaging server must generate log records for access and authentication events.

AU-12 - Medium - CCI-000169 - V-255803 - SV-255803r960879_rule

RMF Control

AU-12

Severity

CCI

CCI-000169

Version

MQMH-AS-001110

Vuln IDs

V-255803
V-74909

Rule IDs

SV-255803r960879_rule
SV-89583

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. The minimum list of logged events should be those pertaining to system startup and shutdown, system access, and system authentication events.

Checks: C-59476r876012_chk

Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] DIS QMGR EVENT A list of all events will be displayed along with an indication of if event logging is enabled. The events are as follows: Authority: 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 If and required event logging is not enabled for running queue managers, this is a finding.

Fix: F-59419r876013_fix

The following events may be logged for each queue manager on the MQ Appliance: Authority (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) To enable logging for a queue manager, enter the following from the MQ Appliance CLI for each event for which you wish to enable logging: To access the MQ Appliance CLI, enter the following: mqcli runmqsc [queue mgr name] ALTER QMGR [event name](ENABLED) end Note: Any MQ monitoring solution that connects to MQ as a client may be used to monitor event queues.

The MQ Appliance messaging server must ensure authentication of both SSH client and server during the entire session.

SC-23 - Medium - CCI-001184 - V-255804 - SV-255804r961110_rule

RMF Control

SC-23

Severity

CCI

CCI-001184

Version

MQMH-AS-001120

Vuln IDs

V-255804
V-74895

Rule IDs

SV-255804r961110_rule
SV-89569

This control focuses on communications protection at the session, versus packet level. At 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. Messaging servers must provide the capability to perform mutual authentication. Mutual authentication is when both the client and the server authenticate each other. Satisfies: SRG-APP-000219-AS-000147, SRG-APP-000223-AS-000150, SRG-APP-000223-AS-000151

Checks: C-59477r876015_chk

Check that TLS mutual authentication configuration is correct by using DISPLAY commands. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] DIS CHANNEL(*) CHLTYPE(SVRCONN) Note the name of SVRCONN channel (client channel) you wish to check. DIS CHANNEL([name of SVRCONN channel]) Confirm that the parameter "SSLCIPH" specifies the desired cipher spec and that the value of "SSLAUTH" is "REQUIRED". If either the "SSLCIPH" or "SSLAUTH" value is not correct, this is a finding.

Fix: F-59420r876016_fix

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. 1. Prepare the key repository on each endpoint client. 2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints. 3. 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. 4. Add the CA-signed certificate to the key repository for each endpoint. On the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example: [C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM) To access the MQ Appliance CLI, enter: mqcli runmqsc [QM1] DEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) + SSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) + DESCR('Receiver channel using TLS from [client name] to [QM name]') end Note: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp

The MQ Appliance messaging server must generate a unique session identifier using a FIPS 140-2 approved random number generator.

SC-23 - Medium - CCI-001188 - V-255805 - SV-255805r961119_rule

RMF Control

SC-23

Severity

CCI

CCI-001188

Version

MQMH-AS-001150

Vuln IDs

V-255805
V-74911

Rule IDs

SV-255805r961119_rule
SV-89585

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

Checks: C-59478r876018_chk

Fix: F-59421r876019_fix

The MQ Appliance messaging server must authenticate all network-connected endpoint devices before establishing any connection.

IA-3 - Medium - CCI-001958 - V-255806 - SV-255806r1000055_rule

RMF Control

IA-3

Severity

CCI

CCI-001958

Version

MQMH-AS-001160

Vuln IDs

V-255806
V-74913

Rule IDs

SV-255806r1000055_rule
SV-89587

Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device. Device authentication is accomplished via the use of certificates and protocols such as SSL mutual authentication. Device 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. 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. Note: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp

Checks: C-59479r876021_chk

Fix: F-59422r876022_fix

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. 1. Prepare the key repository on each endpoint client. 2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints. 3. 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. 4. Add the CA-signed certificate to the key repository for each endpoint. On the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example: [C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM) To access the MQ Appliance CLI, enter: mqcli runmqsc [QM1] Replace the brackets "[ ]" with a selected parameter: DEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) + SSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) + DESCR('Receiver channel using TLS from [client name] to [QM name]') For example: ALTER CHANNEL(C1.TO.QM1) CHLTYPE(SVRCONN) TRPTYPE(TCP) + SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED) + DESCR('Receiver channel using TLS from C1 to QM1')

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.

IA-3 - High - CCI-001967 - V-255807 - SV-255807r1000056_rule

RMF Control

IA-3

Severity

CCI

CCI-001967

Version

MQMH-AS-001170

Vuln IDs

V-255807
V-74915

Rule IDs

SV-255807r1000056_rule
SV-89589

Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. Device 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. 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 must be configured. Note: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp

Checks: C-59480r876024_chk

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. Check that TLS mutual authentication configuration is correct by using DISPLAY commands. To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] DIS CHANNEL(*) CHLTYPE(SVRCONN) Note the name of SVRCONN channel (client channel) you wish to check. DIS CHANNEL([name of SVRCONN channel]) Confirm that the parameter "SSLCIPH" specifies the desired cipher spec and that the value of "SSLAUTH" is "REQUIRED". If either the "SSLCIPH" or "SSLAUTH" value is not correct, this is a finding.

Fix: F-59423r876025_fix

1. Prepare the key repository on each endpoint client. 2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints. 3. 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. 4. Add the CA-signed certificate to the key repository for each endpoint. On the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example: [C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM) To access the MQ Appliance CLI, enter: mqcli runmqsc [QM1] Replace the brackets "[ ]" with a selected parameter: DEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) + SSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) + DESCR('Receiver channel using TLS from [client name] to [QM name]') For example: ALTER CHANNEL(C1.TO.QM1) CHLTYPE(SVRCONN) TRPTYPE(TCP) + SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED) + DESCR('Receiver channel using TLS from C1 to QM1')

MQ Appliance messaging servers must use NIST-approved or NSA-approved key management technology and processes.

SC-13 - Medium - CCI-002450 - V-255808 - SV-255808r961857_rule

RMF Control

SC-13

Severity

CCI

CCI-002450

Version

MQMH-AS-001180

Vuln IDs

V-255808
V-74917

Rule IDs

SV-255808r961857_rule
SV-89591

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. 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. Note: Following are the cipher specs available for MQ: https://ibm.biz/BdrJGp

Checks: C-59481r876027_chk

Fix: F-59424r876028_fix

1. Prepare the key repository on each endpoint client. 2. Request a CA-signed certificate for each client. You might use different CAs for the two endpoints. 3. 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. 4. Add the CA-signed certificate to the key repository for each endpoint. On the MQ Appliance queue manager, define a server-connection channel by issuing a command as in the following example: [C1]=Client, [QM1]=MQ Appliance queue manager. Replace [QM1] with the actual queue manager name (e.g., FINANCEQM) To access the MQ Appliance CLI, enter: mqcli runmqsc [QM1] DEFINE CHANNEL([C1].TO.[QM1]) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCIPH([TLS_RSA_WITH_AES_128_CBC_SHA or other cipher spec]) SSLCAUTH(REQUIRED) DESCR('Receiver channel using TLS from [client name] to [QM name]') end

The MQ Appliance messaging server must utilize FIPS 140-2 approved encryption modules when authenticating users and processes.

IA-7 - Medium - CCI-000803 - V-255809 - SV-255809r961050_rule

RMF Control

IA-7

Severity

CCI

CCI-000803

Version

MQMH-AS-001200

Vuln IDs

V-255809
V-74919

Rule IDs

SV-255809r961050_rule
SV-89593

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. TLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. To 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.

Checks: C-59482r876030_chk

To access the MQ Appliance CLI, enter: mqcli To identify the queue managers, enter: dspmq For each queue manager identified, run the command: runmqsc [queue name] DIS QMGR SSLFIPS If the value of "SSLFIPS" is set to "NO", this is a finding.

Fix: F-59425r876031_fix

To access the MQ Appliance CLI, for each queue manager, enter: mqcli runmqsc [queue manager name] ALTER QMGR SSLFIPS(YES) end

The MQ Appliance messaging server must protect the confidentiality and integrity of transmitted information through the use of an approved TLS version.

SC-8 - Medium - CCI-002418 - V-255810 - SV-255810r961632_rule

RMF Control

SC-8

Severity

CCI

CCI-002418

Version

MQMH-AS-001230

Vuln IDs

V-255810
V-74863

Rule IDs

SV-255810r961632_rule
SV-89537

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). Transmission 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. If 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. FIPS 140-2 approved TLS versions include TLS V1.0 or greater. TLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. To 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.

Checks: C-59483r876033_chk

Fix: F-59426r876034_fix

To access the MQ Appliance CLI, for each queue manager, enter: mqcli runmqsc [queue manager name] ALTER QMGR SSLFIPS(YES) end

The MQ Appliance messaging server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.

SC-8 - Medium - CCI-002418 - V-255811 - SV-255811r961632_rule

RMF Control

SC-8

Severity

CCI

CCI-002418

Version

MQMH-AS-001240

Vuln IDs

V-255811
V-74861

Rule IDs

SV-255811r961632_rule
SV-89535

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

Checks: C-59484r876036_chk

Fix: F-59427r876037_fix

To access the MQ Appliance CLI, for each queue manager, enter: mqcli runmqsc [queue manager name] ALTER QMGR SSLFIPS(YES) end

The MQ Appliance messaging server must employ approved cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission.

SC-8 - Medium - CCI-002421 - V-255812 - SV-255812r961635_rule

RMF Control

SC-8

Severity

CCI

CCI-002421

Version

MQMH-AS-001250

Vuln IDs

V-255812
V-74859

Rule IDs

SV-255812r961635_rule
SV-89533

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. If data in transit is unencrypted, it is vulnerable to disclosure and modification. If approved cryptographic algorithms are not used, encryption strength cannot be assured. FIPS 140-2 approved TLS versions include TLS V1.0 or greater. TLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. To 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.

Checks: C-59485r876039_chk

Fix: F-59428r876040_fix

To access the MQ Appliance CLI, for each queue manager, enter: mqcli runmqsc [queue manager name] ALTER QMGR SSLFIPS(YES) end

The MQ Appliance messaging server must provide a clustering capability.

SC-24 - Medium - CCI-001190 - V-255813 - SV-255813r961122_rule

RMF Control

SC-24

Severity

CCI

CCI-001190

Version

MQMH-AS-001260

Vuln IDs

V-255813
V-74893

Rule IDs

SV-255813r961122_rule
SV-89567

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. Failure 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. Clustering of multiple messaging servers is a common approach to providing fail-safe application availability when system MAC and confidentiality levels require redundancy. Satisfies: SRG-APP-000225-AS-000154, SRG-APP-000225-AS-000166

Checks: C-59486r876042_chk

Review system categorization to determine if redundancy is a requirement. If the system categorization does not specify redundancy requirements, this requirement is NA. On each member of the HA pair: Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To run the dspmq command, enter: dspmq -s -o ha One of the appliances should be running as primary, the other as secondary. If HA is not configured and the primary and secondary running, this is a finding.

Fix: F-59429r876043_fix

To configure HA: 1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3. 2. Configure the three connected MQ Appliance ports (on both appliances) as follows: Interface Purpose IP address/CIDR eth1 HA group primary interface x.x.x.x/24 eth2 HA group alternative interface x.x.x.x/24 eth3 HA Replication interface x.x.x.x/24 On the second appliance, enter the following command from the MQ Appliance CLI: prepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout] On the first appliance, enter the following command: crthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance] crtmqm [HA QM name] –p [port] –sx Note: 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).

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.

AU-3 - Medium - CCI-001844 - V-255814 - SV-255814r981683_rule

RMF Control

AU-3

Severity

CCI

CCI-001844

Version

MQMH-AS-001300

Vuln IDs

V-255814
V-74853

Rule IDs

SV-255814r981683_rule
SV-89527

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. Without 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. The MQ appliance is designed to be used in a redundant HQ configuration which will provide a means of centralized management of log activity. Rudimentary 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 Note: 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). Ref.: Configuring high availability queue managers https://goo.gl/xAqNTX

Checks: C-59487r876045_chk

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. On each member of the HA pair: Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To run the dspmq command, enter: dspmq -s -o ha One of the appliances should be running as primary, the other as secondary. If 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.

Fix: F-59430r876046_fix

To configure HA: 1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3. 2. Configure the three connected MQ Appliance ports (on both appliances) as follows: Interface Purpose IP address/CIDR eth1 HA group primary interface x.x.x.x/24 eth2 HA group alternative interface x.x.x.x/24 eth3 HA Replication interface x.x.x.x/24 On the second appliance, enter the following command from the MQ Appliance CLI: prepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout] On the first appliance, enter the following command: crthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance] On the first appliance, stop the queue manager to be HA-enabled: endmqm [name of queue manager] sethagrp -i [name of queue manager] Note: 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).

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.

AU-4 - Medium - CCI-001851 - V-255815 - SV-255815r961860_rule

RMF Control

AU-4

Severity

CCI

CCI-001851

Version

MQMH-AS-001310

Vuln IDs

V-255815
V-74851

Rule IDs

SV-255815r961860_rule
SV-89525

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. Off-loading is a common process in information systems with limited log storage capacity. The MQ appliance is designed to be used in a redundant configuration which will ensure duplicates of log activity are created. Rudimentary 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 Note: 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).

Checks: C-59488r876048_chk

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. For redundant systems: On each member of the HA pair: Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To run the dspmq command, enter: dspmq -s -o ha One of the appliances should be running as primary, the other as secondary. If 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.

Fix: F-59431r876049_fix

To configure HA: 1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3. 2. Configure the three connected MQ Appliance ports (on both appliances) as follows: Interface Purpose IP address/CIDR eth1 HA group primary interface x.x.x.x/24 eth2 HA group alternative interface x.x.x.x/24 eth3 HA Replication interface x.x.x.x/24 On the second appliance, enter the following command from the MQ Appliance CLI: prepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout] On the first appliance, enter the following command: crthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance] crtmqm [HA QM name] –p [port] –sx Note: 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).

The MQ Appliance messaging server must use encryption strength in accordance with the categorization of the management data during remote access management sessions.

AC-17 - Medium - CCI-000068 - V-255816 - SV-255816r960759_rule

RMF Control

AC-17

Severity

CCI

CCI-000068

Version

MQMH-AS-001320

Vuln IDs

V-255816
V-74849

Rule IDs

SV-255816r960759_rule
SV-89523

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. Types of management interfaces utilized by a messaging server include web-based HTTPS interfaces as well as command line-based management interfaces.

Checks: C-59489r876051_chk

To access the MQ Appliance CLI, enter: mqcli config crypto show crypto-mode If the current setting is set to "permissive", this is a finding.

Fix: F-59432r876052_fix

To set management access to the highest encryption strength, enable FIPS 140-2 Level 1 mode at the next reload of the firmware. Enter the following commands: config crypto crypto-mode-set fips-140-2-l1 Press "Enter" The following message will appear: "Crypto Mode Successfully set to fips-140-2-l1 for next boot."

The MQ Appliance messaging server, when categorized as a high level system, must be in a high-availability (HA) cluster.

SC-5 - Medium - CCI-002385 - V-255817 - SV-255817r961620_rule

RMF Control

SC-5

Severity

CCI

CCI-002385

Version

MQMH-AS-001330

Vuln IDs

V-255817
V-74847

Rule IDs

SV-255817r961620_rule
SV-89521

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. Rudimentary 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 Note: 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).

Checks: C-59490r876054_chk

Request and review system documentation identifying the system categorization level. If the system categorization is not high, this requirement is NA. Ask for and review the HA configuration. On the either member of the HA pair: Establish an SSH command line session as an admin user. To access the MQ Appliance CLI, enter: mqcli To run the dspmq command, enter: dspmq -s -o ha Each queue manager that is properly configured for HA should show HA(Replicated). If it does not, this is a finding.

Fix: F-59433r876055_fix

To configure HA: 1. Use three Ethernet cables to directly connect two appliances together using ports eth1, eth2, and eth3. 2. Configure the three connected MQ Appliance ports (on both appliances) as follows: Interface Purpose IP address/CIDR eth1 HA group primary interface x.x.x.x/24 eth2 HA group alternative interface x.x.x.x/24 eth3 HA Replication interface x.x.x.x/24 On the second appliance, enter the following command from the MQ Appliance CLI: prepareha -s [SecretText] -a [eth 1 IPAddress of first appliance] [-t timeout] On the first appliance, enter the following command: crthagrp -s [SecretText] -a [eth 1 IPAddress of second appliance] On the first appliance, stop the first queue manager to be HA enabled: endmqm [name of queue manager] Set an HA group: sethagrp -i [name of queue manager]

Added rules 43

Removed rules 43

Checks: C-59448r875928_chk

Fix: F-59391r875929_fix

Generate Mitigation Statement:

Checks: C-59449r875931_chk

Fix: F-59392r875932_fix

Generate Mitigation Statement:

Checks: C-59450r875934_chk

Fix: F-59393r875935_fix

Generate Mitigation Statement:

Checks: C-59451r875937_chk

Fix: F-59394r875938_fix

Generate Mitigation Statement:

Checks: C-59452r875940_chk

Fix: F-59395r875941_fix

Generate Mitigation Statement:

Checks: C-59453r875943_chk

Fix: F-59396r875944_fix

Generate Mitigation Statement:

Checks: C-59454r875946_chk

Fix: F-59397r875947_fix

Generate Mitigation Statement:

Checks: C-59455r875949_chk

Fix: F-59398r875950_fix

Generate Mitigation Statement:

Checks: C-59456r875952_chk

Fix: F-59399r875953_fix

Generate Mitigation Statement:

Checks: C-59457r875955_chk

Fix: F-59400r875956_fix

Generate Mitigation Statement:

Checks: C-59458r875958_chk

Fix: F-59401r875959_fix

Generate Mitigation Statement:

Checks: C-59459r875961_chk

Fix: F-59402r875962_fix

Generate Mitigation Statement:

Checks: C-59460r875964_chk

Fix: F-59403r875965_fix

Generate Mitigation Statement:

Checks: C-59461r875967_chk

Fix: F-59404r875968_fix

Generate Mitigation Statement:

Checks: C-59462r875970_chk

Fix: F-59405r875971_fix

Generate Mitigation Statement:

Checks: C-59463r875973_chk

Fix: F-59406r875974_fix

Generate Mitigation Statement:

Checks: C-59464r875976_chk

Fix: F-59407r875977_fix

Generate Mitigation Statement:

Checks: C-59465r1001150_chk

Fix: F-59408r991676_fix

Generate Mitigation Statement:

Checks: C-59466r875982_chk

Fix: F-59409r875983_fix

Generate Mitigation Statement:

Checks: C-59467r875985_chk

Fix: F-59410r875986_fix

Generate Mitigation Statement:

Checks: C-59468r875988_chk

Fix: F-59411r875989_fix

Generate Mitigation Statement:

Checks: C-59469r875991_chk

Fix: F-59412r875992_fix

Generate Mitigation Statement:

Checks: C-59470r875994_chk

Fix: F-59413r875995_fix

Generate Mitigation Statement:

Checks: C-59471r875997_chk

Fix: F-59414r875998_fix

Generate Mitigation Statement:

Checks: C-59472r876000_chk

Fix: F-59415r876001_fix

Generate Mitigation Statement:

Checks: C-59473r876003_chk

Fix: F-59416r876004_fix

Generate Mitigation Statement: