z/OS Encryption Readiness Technology (zERT) Concepts
With the increasing number of corporate, industry, and government regulations regarding cryptographic protection of data in flight, as well as discoveries of weaknesses in existing cryptographic protocols and algorithms, it is important for z/OS® administrators and auditors to be able to assess the quality of the cryptographic network protection being applied to their key z/OS workloads.
The landscape of cryptographic network protection on z/OS is varied and can be complex. Because of this, performing such an assessment can be very difficult. Consider the following:
- IBM® provides two TLS/SSL protocol implementations on z/OS:
- z/OS Cryptographic Services System SSL, which is available to software written in C or C++.
- Java™ Secure Sockets Extension (JSSE), which available to Java software (and is written in Java itself).
- z/OS Communications Server provides AT-TLS, which invokes System SSL on behalf of applications and middleware based on policies that you create. AT-TLS can protect traffic from any program that uses z/OS Unix System Services TCP sockets APIs, regardless of the programming language.
- z/OS Communications Server provides a full IPSec implementation, also configured through policies that you create.
- z/OS also supports the Secure Shell (SSH) protocol , although Communications Server does not directly use it. For more information of Secure Shell (SSH) protocol, see z/OS OpenSSH in z/OS Introduction and Release Guide.
- Each of these protocols allow the local and remote endpoints to negotiate the exact protection methods to be used for any given security session. This means understanding the z/OS configuration for a given application's cryptographic protection only tells you which attributes (protocol versions, algorithms, key lengths, and so on.) are possible - it usually does not tell you the exact set of protection attributes that were agreed upon for any specific security session that is established between the z/OS application and a remote endpoint.
With such variety of protocols, configuration methods, and audit and log records, it can be difficult to clearly understand the overall state of cryptographic network protection for your z/OS system.
zERT positions the z/OS TCP/IP stack as a central collection and reporting point for the cryptographic protection attributes for TLS, SSL, SSH, and IPSec security sessions that are protecting TCP and Enterprise Extender connections that terminate on the local stack. This collection and reporting function is called zERT discovery.
A second reporting function called zERT aggregation summarizes the repeated use of security sessions over a period of time (the system's SMF interval or the specified zERT aggregation INTVAL setting). By focusing more on the security session than on individual TCP or EE connections, zERT aggregation provides the same level of cryptographic detail as zERT discovery, but with significantly fewer SMF records. The zERT aggregation function requires the use of zERT discovery to collect the individual TCP and EE connection information that is then summarized by zERT aggregation.
IBM zERT Network Analyzer is a z/OS Management Facility (z/OSMF) task that provides a GUI-based tool for analyzing cryptographic protection characteristics of TCP and Enterprise Extender (EE) connections on your system, using SMF records generated by the zERT aggregation function.
With zERT policy-based enforcement (or simply "zERT enforcement"), the TCP/IP stack uses the cryptographic protection attributes observed by zERT discovery to enforce policy rules that you create based on your local network security requirements. zERT enforcement compares each TCP connection's observed cryptographic attributes to rules installed through the Policy Agent to take appropriate action when a connection’s protection attributes match those defined in a zERT enforcement rule. zERT enforcement rules and their associated actions are defined through the IBM® Configuration Assistant for z/OS Communications Server in z/OSMF. For acceptable protection, the default action is to silently allow the connection. For questionable or unacceptable protection, actions such as notification through messages, auditing through SMF records, and even dropping the connection can be configured.