SSL and TLS

SSL refers to Secure Sockets Layer, a Netscape-developed protocol for securing transmissions over the Internet. TLS refers to Transport Layer Security, the successor to SSL. SSL and TLS provide for message authentication and encryption. Except where it makes an obvious distinction, this section uses the terms SSL, TLS, and SSL/TLS interchangeably. On z/OS, SSL/TLS is implemented by the Cryptographic Services Base element of z/OS.

BMC AMI Datastream uses the facilities of z/OS Cryptographic Services and the SSL/TLS protocols to provide:

• Encryption of syslog data during transmission to prevent eavesdropping. Encryption with up to 512-bit keys is supported. Encryption is a basic feature of SSL/TLS.
• Authentication of syslog data. The SSL/TLS protocols include the use of a message authentication algorithm to prevent message tampering. MD5, SHA1, SHA256, SHA384 and AEAD message authentication are supported. Message authentication is a basic feature of SSL/TLS.
• Diffie-Hellman key exchange. Diffie-Hellman key exchange provides forward security. Forward security means that someone who records encrypted exchanges today this is not able to decrypt them if they determine the private key at some point in the future. Diffie-Hellman key exchange is enabled if the coded SERVER TLS Ciphersuite includes it. See SERVER statement.
• Server authentication. Verification of certificate authority (CA) signing of the certificate presented by the syslog server console authenticates that the connected server is the intended server, and that the session has not been the victim of a man-in-the-middle attack. z/OS Cryptographic Services SSL/TLS requires that server certificates be signed by a CA known to the key ring, thereby assuring server authentication.

• Client authentication. If the SSL/TLS server (SIEM console) is properly configured, it requests and authenticates a certificate provided by the SSL/TLS client (BMC AMI Datastream or CZASEND). BMC AMI Datastream and CZASEND support client certificates and authentication. A client certificate, installed in the key ring and specified with the TLS(LABEL) parameter, is required.

You need access to the appropriate RACF resource classes. If you have hardware cryptographic support, see the IBM documentation.

z/OS Cryptographic Services and by implication BMC AMI Datastream support self-signed server certificates, including the self-signed certificates generated by the MAKE_CERT command of the BMC Defender SyslogDefender. The self-signed certificate (but not its key) must be preloaded into your certificate database or key ring, or you receive error CZA0075E Error code 417 returned for server-address from GSK function gsk_secure_socket_init(): Self-signed certificate cannot be  validated .

Vulnerabilities

BMC AMI Datastream is not and has never been subject to the Heartbleed bug. The Heartbleed bug is unique to the OpenSSL cryptographic software library and BMC AMI Datastream uses IBM z/OS Cryptographic Services, not OpenSSL. All SSL (as opposed to TLS) implementations are subject to the so-called POODLE vulnerability. The preferred mitigation is to disable SSL and allow only TLS – where BMC AMI Datastream supports through the SERVER TLS(SECURITY(-SSLV3)) parameter. The Shellshock (or Bashdoor) bug affects the UNIX shell, not encryption protocols.

Disclaimer

While BMC believes that it has followed industry best practices in developing BMC AMI Datastream and particularly BMC AMI Datastream SSL/TLS support, no security or encryption product can guarantee perfect security. Your organization is solely responsible for determining the suitability of BMC AMI Datastream and its configuration to your environment.