We’ve been talking about securing data at rest and data in transit for a long time. It’s just that data in transit is even more important these days as more-and-more information is transferred and the mainframe is an important network hub, and ensuring it is appropriately secure becomes ever more important.
With the introduction of the z14, we got the concept of pervasive encryption and the idea that all data could be encrypted no matter where it was. For data in transit, we’re probably familiar with TLS/SSL, SSH and IPSec cryptographic network security protocols, but how do you know their cryptographic status? That’s the question that z/OS® Encryption Readiness Technology (zERT) answers. And this blog is a very brief summary of what zERT can be used to do.
zERT’s raison d’être is to provide its users with intelligent network security discovery and reporting capabilities. And it does this by monitoring TCP and Enterprise Extender connections, and collecting and reporting on the cryptographic security attributes of IPv4 and IPv6 application traffic.
The data it collects is written to SMF in new SMF 119 subtype 11 and 12 records for analysis. There’s also a new real-time Network Management Interface (NMI) service for network management applications to retrieve zERT SMF records as they are generated.
SMF 119 subtype 11 records contain the full of detail of each session. Subtype 12 captures all unique session types between client/server pairs per interval. They both allow users to see what traffic is protected, and if so, what security protocol and version is used.
With client/server pairs, zERT can be used to track connections between each pair of client and server IP addresses, and information collected includes the port number, job, and userid.
Looking in more detail, we can see that the zERT summary records contain connection and throughput counters, including: the total number of connections; the number of partially protected connections (where encryption was not applied during the entire session); and the number of short (shorter than10 second) connections. It’s worth noting that short connections can be significant for TLS, because establishing the session is expensive in terms of CPU, making them an expensive way to run connections.
There are a couple of limitations to zERT. For example, no information is collected non-EE UDP traffic or traffic using other IP protocols. If you want to see a list of what these other protocols are, have a look at https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers. And zERT only collects cryptographic security attributes for TLS, SSL, SSH, and IPSec protocols, not any other cryptographic security protocols.
When zERT is used with recognized cryptographic protection, it can show which cryptographic protocol is being used, who the traffic belongs to, which cryptographic algorithms are used, the length of the cryptographic keys, and other important attributes of the cryptographic protection. This can be used to determine regulatory compliance and, importantly, for see whether any connections are currently using cryptographic protection that is not robust enough and needs to be increased. It can also provide information for auditors and compliance officers.
Of course, 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.
In terms of the performance impact of zERT, there are a few things to consider. It’s estimated that the performance impact on the TCP/IP stack is quite small, in terms of latency and CPU consumption. On the other hand, the zERT Network Analyzer can affect system CPU consumption because it is a data-intensive application. However, zERT Network Analyzer is a Java application, and it uses Db2 for z/OS as its data store, so, a lot of the processing is zIIP eligible. There’s also zERT aggregation, which can be used to reduce the volume of zERT-generated SMF data in situations where there are workloads with lots of short-lived connections.
zERT looks like a really useful tool from IBM. zERT Discovery collects and records cryptographic information, and zERT Aggregation groups attributes by security session. As a tool, it provides a way for users to get a grip on the overall quality of the cryptographic protection for their z/OS network. The security team can find out whether they have any security exposures. They can see whether any unapproved protection protocols are being used, or even whether there are some cases where no protection is being used on data in transit.
Find out more about iTech-Ed Ltd here.