What are the limitations for zERT discovery?

zERT discovery has the following limitations:
  • zERT only monitors TCP and Enterprise Extender (EE) traffic. zERT does not monitor non-EE UDP traffic or any other IP protocol.
  • zERT only monitors local traffic, meaning traffic that terminates at the local TCP/IP stack. zERT does not monitor traffic that is being Start of changerouted through the local TCP/IP stack (this includes traffic that is generated within z/OS® Container Extensions).End of change
  • zERT monitors for TLS, SSL, SSH and IPSec protection. No other cryptographic security protocols are supported.
  • zERT recognition of TLSv1.3 protocols is only available on z/OS V2R4 or later.
The following z/OS cryptographic protocol providers are fully enabled for zERT:
  • z/OS Communications Server IPSec
  • z/OS Cryptographic Services System SSL (which also covers AT-TLS)
  • z/OS OpenSSH
  • IBM® z/OS JSSE with the ZERTJSSE provider
Other TLS, SSL and SSH implementations running on z/OS are monitored using observational discovery, which provides a more limited set of security attributes. Specifically for the following situations:
  • Only initial handshakes are observed. zERT has no visibility to early termination of TLS, SSL or SSH session or changes in security attributes made after the initial handshake is complete since the traffic on the connection is encrypted.
  • The number of security attributes observed during the initial handshake is limited. Some attributes are not visible due to the use of encryption during cryptographic protocol negotiations, while others such as distinguished names and serial numbers from X.509 certificates are not observed in order to minimize stream observation's impact on performance.
  • Start of changeSignificant portions of TLSv1.3 handshakes are encrypted, meaning zERT has no visibility to those handshake messages. This also means zERT can only infer if the handshake completed successfully.End of change

There are a small number of cases where zERT is unable to monitor System SSL security sessions. These are cases where an application that calls System SSL directly begins a TLS/SSL handshakes in the middle of the application data stream instead of the very beginning of the stream. An API is provided for such applications to notify zERT that the handshake is about to occur. If the application uses that interface, then zERT will have visibility to the System SSL sessions. Otherwise, zERT will not have visibility to such sessions and will report them as having no recognized TLS/SSL protection. For more information about the API for notifying zERT, see SIOCSHSNOTIFY IOCTL in z/OS Communications Server: IP Programmer's Guide and Reference.

It is important to keep in mind that the number of SMF 119 subtype 11 records generated by the zERT discovery function could be very large, depending on the number of connections supported by your z/OS system as well as the frequency with which those connections are created and deleted. Here are some guidelines for understanding the possible volume of records:
  • For TCP connections, at least one subtype 11 record will be written for every connection that lasts less than 10 seconds.
  • For every TCP connection that lasts 10 seconds or longer, and for Enterprise Extender connections, at least two subtype 11 records will be written.
  • The size of each subtype 11 record depends on the type and number of cryptographic security protocols being used to protect the subject connection. Remember that a single connection can be protected by zero or more protocols. All of the following are valid protection scenarios:
    • A connection is protected by a single TLS, SSL, SSH, or IPSec session.
    • A connection is protected by Start of changean IPsec tunnelEnd of change as well as TLS, SSL or SSH.
    • Although it would be unusual, all three protocols could be applied to a single connection.
    • No cryptographic protection is applied (even in this case, the appropriate subtype 11 records will be written since it is a valid protection state).

Start of changeIf SMF 119 subtype 11 records are only needed for certain types of traffic or only in specific exception cases, you can use zERT policy-based enforcement to generate a targeted set of subtype 11 records.End of change

A second zERT function called zERT aggregation can be used to report zERT information in a summarized format that requires far fewer SMF records than zERT discovery might generate.