|
Our last few blog entries have described the new z/OS Encryption Readiness Technology (zERT) features of z/OS Communications Server V2R3. In this edition, let’s recap a few of the points and cover a few important considerations to keep in mind as you plan your zERT deployment.
1. zERT can generate very large volumes of zERT Connection Detail (SMF 119 subtype 11) records, depending on the number of connections supported by your z/OS system.
- Please plan accordingly.
- Consider only capturing zERT Summary (SMF 119 subtype 12) records on a regular basis and only capture subtype 11s for limited times when investigating specific traffic.
2. zERT monitors TCP and Enterprise Extender traffic. All other IP protocols are unmonitored.
3. zERT monitors traffic that terminates at the local TCP/IP stack. It does not monitor routed traffic
4. zERT does not store or record the values of secret keys, initialization vectors, or any other secret values that are negotiated or derived during cryptographic protocol handshakes.
5. Regardless of the prior point, the zERT data that is recorded provides a rather complete picture of the z/OS system’s network cryptographic protection profile. As such, you should take appropriate steps to protect the recorded SMF data as well as access to the SYSTCPER and SYSTCPES NMI services.
6. zERT only monitors connections that are established after zERT discovery is enabled (or re-enabled).
- If you disable and later re-enable zERT, it will not monitor any of the connections that existed before re-enabling.
- To ensure the most complete monitoring, enable zERT discovery in your TCP/IP profile.
- Remember that you can enable and disable the recording of zERT discovery and zERT aggregation data (the zERT Connection Detail and zERT Summary records) via the SMFCONFIG and NETMONITOR parameters independently of zERT monitoring.
7. TCP traffic protected by cryptographic protocol providers that are not enabled for zERT (OpenSSL, other SSH implementations, etc.) will only be reported through stream observation, which has the following limitations:
- Stream observation can only report the initial TLS/SSL or SSH handshake as long as it is the first thing to flow over the TCP application connection after that connection is established. It has no visibility to rehandshakes or early termination of security sessions.
- zERT has no visibility to attributes that are negotiated during the initial handshake using encrypted messages.
8. There are a small number of System SSL applications that cannot be monitored and are therefore reported as being unprotected. These are applications that:
- Send or receive application-specific data before initiating the TLS/SSL session.
- Do not use the SIOCSHSNOTIFY ioctl.
9. In certain mixed-release sysplex environments, some IPSec-related attributes will not be available for reporting.
zERT provides the raw data for unprecedented insight to the cryptographic protection of your z/OS network traffic. So the next time you are asked “which traffic is protected” or “how is our traffic protected,” look to zERT to provide the answers!
|