Mainframe Security’s Latest Tool for Ensuring Encryption Standards are Met

With all the focus on securing customer data in today’s enterprises, one of the most challenging jobs is that of the network administrator who is responsible for ensuring that all data being transmitted (especially outside the data center) is encrypted as prescribed by corporate security standards.

With the tools previously available, I imagine that this could be an overwhelming responsibility – like trying to plug a never-ending series of plumbing leaks while working without almost any light.

However, beginning with z/OS 2.3, IBM provides data that makes possible an entirely new level of visibility into the encryption status of all network traffic in your environment. This is enabled through z/OS Encryption Readiness Technology (zERT), which makes this data available through SMF 119.12 records.

zERT leverages the fact that the TCP/IP stack serves as a central collection point and repository for cryptographic protection attributes. Think of it as giving parents the capability of being plugged in to all their child’s smartphone and social media feeds 24×7, and thus always being aware of any detrimental influences in their lives.

As you can imagine, the information provided by zERT is very helpful to network administrators responsible for managing the encryption levels and protocols in place for network data sent to various IP addresses inside and outside the enterprise.

Perhaps most importantly, zERT identifies what network traffic is not being protected (either at all, or with a recognized protocol). It also captures how the traffic is being protected, who the traffic belongs to, and if follow up is needed. Thus, zERT data can enable network administrators to both evaluate ongoing adherence to security policies and programmatically provide data for required reporting to auditors and compliance officers.

[This is an abbreviated version of an article I wrote for Cheryl Watson’s Tuning Letter 2019 No. 4. Follow this link to read the entire article on “zERT: Breakthrough in Visibility for Managing Encryption of Network Traffic” republished with Watson & Walker’s permission.]

zERT Data Logistics

The initial zERT capability was delivered with z/OS 2.3 and generated “Detail” data – one SMF 119.11 record for every session. But this resulted in extremely high data volumes, so the new function APAR PI83362 delivered the capability to generate zERT “Summary” data – one SMF 119.12 record per SMF interval for each unique session type between client/server pairs. These Summary records are well-designed and more than sufficient for typical analysis. They are activated by the TCP/IP profile statements GLOBALCONFIG ZERT AGGREGATION and SMFCONFIG ZERTSUM.

When activated, the TCP/IP stack will create a zERT entry for each unique session type between client/server pairs during each SMF interval. It may know in detail about the session protocol through an interface with the cryptographical protocol provider (such as System SSL, OpenSSH or IPsec), or it may obtain information by observing the stream for TLS, SSH or SSL, in which case fewer details tend to be available.

Based on this information, the zERT software will classify the protection of a session as either:

• None (which means no protection was recognized)
• TLS
• SSH
• IPsec

zERT also identifies a few ‘special’ cases, such as Enterprise Extender sessions, as well as output [IPv4] sessions from an FTP server.

The zERT Summary data contains a wealth of information. Along with the protocol, zERT records other protection attributes including:

• protocol version
• cryptographic algorithm being used
• key lengths

zERT also collects identifying attributes to track connections between each pair of Client and Server IP addresses, including:

• port number
• job
• user ID

Here is an example of the data provided from a zERT Summary record for data encrypted with the TLS protocol (with data from a single record broken into 2 lines for readability).

TLS Specific Protocol Information

The zERT Summary records also contain connection and throughput counters. These include:

• the total number of connections
• the number of partially protected connections (where encryption was not applied during the entire session)
• the number of short (<10 second) connections

Short connections are especially interesting for TLS, where establishing the session is expensive in terms of CPU.

It is very important to note that zERT does not collect or record the values of keys, initialization vectors, or any other secret values that are exchanged or negotiated during the session.

Ensuring Encryption Deployment in Your Environment

IBM’s introduction of z/OS Encryption Readiness Technology is a game-changing advance for the mainframe security team responsible for ensuring the deployment of encryption in their environments.

But zERT alone won’t ensure your data is encrypted properly. To learn more about how to take full advantage of this critical new data source, read the full article from Cheryl Watson’s Tuning Letter on “zERT: Breakthrough in Visibility for Managing Encryption of Network Traffic”.