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 routed through the local TCP/IP stack
  • zERT monitors for TLS, SSL, SSH and IPSec protection. No other cryptographic security protocols are supported.
  • A small number of IPSec security attributes are not available when using SWSA and either the distributor or target stack is pre-z/OS® V2R3.
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 (available in IBM SDK, Java™ Technology Edition 8.0.0 Service Refresh 5, Fix Pack 25)
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.

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 a wide IPSec tunnel 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).

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.