z/OS Communications Server - Group home

Frequently Asked Questions | z/OS Encryption Readiness Technology (zERT)

  
https://higherlogicdownload.s3.amazonaws.com/IMWUC/UploadedImages/a760f5e9-dc3b-4022-8eac-45e95fa559a9/LowRes_Original-166828965.jpg

As an important part of IBM Z pervasive encryption, z/OS Encryption Readiness Technology (zERT) monitors your z/OS cryptographic network protection. It can help you stay one step ahead of ongoing cyber threats by providing intelligent network security discovery and reporting capabilities.

If some questions come up when you start using zERT, here you will find answers to many of them.


Requirements and support

Question:
Where does zERT fit into Pervasive Encryption?

Answer:
Pervasive encryption provides a transparent and consumable approach to enable extensive encryption of data in flight and at rest to simplify and reduce the costs associated with protecting data and achieving compliance mandates. IBM Z delivered new capabilities through tight full-stack platform integration, in the hardware, OS, and middleware. As highlighted in this diagram, zERT focuses on data in flight, providing visibility to the cryptographic protection of z/OS network traffic to ensure compliance with data protection standards.


pe.png


Question: What are the hardware and software requirements to make the zERT data useful? If there are routers or switches, are there prerequisites for that or can it get data from any other projects?

Answer:
There are no hardware prerequisites for zERT. The following software prerequisites apply:
  • z/OS V2R3 or later releases
  • IBM zERT Network Analyzer requires Db2 for z/OS 11 or later releases
  • IBM Connect:Direct users must ensure Connect:Direct APAR PI77316 is applied
zERT-enabled cryptographic protocol providers (IBM z/OS System SSL, IBM z/OS Communications Server AT-TLS and IPsec support, IBM z/OS OpenSSH, IBM z/OS ZERTJSSE) provide more detailed and complete information about the data they protect than those protected by providers that are not enabled for zERT (for example, OpenSSL).


Performance considerations


Question: Is there any guidance on estimating the amount of space to allocate for my zERT Network Analyzer database? 

Answer:
Yes, this section in the z/OSMF Configuration Guide contains guidelines on estimating the required database space.



Question:
How about the performance impact of adopting zERT?

Answer:
There are two key areas to consider regarding performance: the effect of collecting zERT data in the z/OS TCP/IP stack, and the performance characteristics of the zERT Network Analyzer.
  • The performance impact on the TCP/IP stack is very small, both in terms of latency and CPU consumption. As illustrated in the z/OS Communications Server V2R3 Performance Summary Report, "enabling zERT has little to no impact on latency or CPU consumption."
  • The zERT Network Analyzer can affect system CPU consumption because it is a data-intensive application. zERT Network Analyzer import and query processing for large amounts of data may take a long time and consume a non-trivial amount of CPU cycles.
    • Because the zERT Network Analyzer is a Java application, and Db2 for z/OS is used as its data store, much of the zERT Network Analyzer processing is eligible to run on IBM z Integrated Information Processor (zIIP) specialty engines. Consider running zERT Network Analyzer on a system that has sufficient zIIP capacity available in order to minimize the general purpose processor CPU costs associated with import and query operations.
    • Consider using WLM policies to properly prioritize the DDF workload initiated by the zERT Network Analyzer so it does not impact more important workloads on the system.

  • Here are some general performance-related recommendations for deploying the zERT Network Analyzer:
    • Initially deploy the IBM zERT Network Analyzer plug-in and database on a test system where you can familiarize yourself with the plug-in operation as well as the Db2 for z/OS and system resource requirements.
    • Depending on the number of imported SMF records and the complexity of your queries, consider initially limiting query execution to specific times of day or specific systems to minimize system impacts.
    • If you plan to import SMF dump data sets with large numbers of SMF records (hundreds of thousands or millions), you can reduce the import time and processing costs by filtering out any of the SMF records that are not SMF type 119 subtype 12 before you execute the import operation. These non-SMF 119-12 records can be stripped out of your SMF dump data sets using the IFASMFDP program. To do this, specify the SMF dump data set containing the SMF type 119 subtype 12 and other SMF records as the input data set (INDD) and specify OUTDD(<outDDname>,TYPE(119(12))). Refer to the z/OS MVS System Management Facilities (SMF) book for complete details on using the IFASMFDP SMF data set dump program.
    • If possible, consider using a Db2 for z/OS subsystem that is co-located with the zERT Network Analyzer to reduce latency and elapsed times when running operations like SMF imports and queries.




Question:
For configurations that use ICSF, Crypto Express adapters and/or CPACF, does zERT provide data that indicates how much the different cryptographic facilities are used?

Answer:
zERT does not provide information about where a specific cryptographic algorithm is executed - be it in a Crypto Express adapter, CPACF, or in software. For this type of information consult ICSF Cryptographic Usage Statistics (SMF type 82, subtype 31).




Question:
How effective is zERT aggregation at reducing the amount of zERT-generated SMF data?


Answer:
For workloads with lots of short-lived connections, zERT aggregation is very effective at reducing the volume of SMF data over zERT Discovery. For example, if you have a single client connecting to the same z/OS server 1000 per minute using the same security attributes each time, and your SMF interval is configured to 30 minutes, you would get 30,000 zERT Connection Detail (SMF 119-11) records during a single interval, whereas you would only get one zERT Summary (SMF 119-12) record during the same interval. So the effectiveness really depends on how many connections are protected by a given security session within an SMF interval. The more connections, the larger the advantage in SMF volume.



Question: Regarding product maturity, are OpenSSH, IPsec, AT-TLS, direct System SSL calls all fully addressed?

Answer:
zERT uses two different mechanisms for discovering security session attributes.

  • One is TCP stream observation, which is somewhat limited in what it can collect. As described in the z/OS Communications Server: IP Configuration Guide.
    • 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, 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 cryptographic protocol providers that are not enabled for zERT (as described under the next bullet), the only zERT information available will be that from stream observation. Providers that fall into this category include the standard z/OS JSSE provider, ports of OpenSSL, and Tectia SSH.

  • The other is advisory discovery, where zERT-enabled cryptographic protocol providers pass the session attributes and information about state changes to zERT as the sessions are negotiated, re-negotiated or terminated. This approach provides more detail and can inform zERT about changes in protection after the initial session handshake completes. The following cryptographic protocol providers are enabled for zERT: System SSL (including AT-TLS), IPsec, OpenSSH and the ZERTJSSE provider.

Note: zERT only understands TLS/SSL, IPsec and SSH. If your z/OS traffic is protected by any other cryptographic protocol, zERT will not recognize it and will consider the traffic unprotected (barring the application of another recognized protocol to the same connection).



Question: Can the data in the zERT Network Analyzer database be deleted after my queries are run and reports are generated?

Answer:
There are no guidelines regarding when to prune your zERT Network Analyzer database. This is up to you to decide. However, the following considerations may help with that decision. There are two ways to generate reports:
  • One way is to do it interactively such that the query results are displayed in the web browser. The contents of these reports are generated when the query is run and they are deleted when the web browser tab is closed or when another query is run in the same tab. So if you use web-based reports, you need to keep data in the database for as long as you are interested in viewing it.
  • The other way is to export the query results to a comma-separated value (CSV) file. While these results cannot be viewed through the zERT Network Analyzer, they can be processed by your favorite spreadsheet program or any other program that handles CSV format. Since these results are saved in a file in the z/OS Unix file system, they are persistent and are preserved even after the data is deleted from the database.


Quick starts


Question: How can I enable z/OS Encryption Readiness Technology (zERT)?

Answer:
To enable zERT in-memory monitoring, you must specify ZERT on that stack's GLOBALCONFIG statement. The default value is NOZERT. In addition, you can specify a subparameter to enable the aggregation function:

  • AGGregation: indicates that the zERT aggregation function is enabled.
  • NOAGGregation: indicates that the zERT aggregation function is disabled. This is the default.
See the GLOBALCONFIG statement for more information.

In addition to GLOBALCONFIG ZERT [AGGregation], you must specify which zERT SMF records are to be recorded and to which facilities. zERT SMF 119-11 and/or SMF 119-12 records may be written to SMF, to a realtime network monitoring interface (NMI, for consumption by realtime applications), or both.

To write records to SMF, specify the appropriate parameters on the SMFCONFIG statement:
  • SMFCONFIG ZERTDETail indicates that zERT SMF 119-11 records are to be written to the System Management Facility.
  • SMFCONFIG NOZERTDETail indicates that zERT SMF 119-11 records are not to be written to the System Management Facility. This is the default.
  • SMFCONFIG ZERTSUMmary indicates that zERT SMF 119-12 records are to be written to the System Management Facility.
  • SMFCONFIG NOZERTSUMmary indicates that zERT SMF 119-12 records are not to be written to the System Management Facility. This is the default.
To write records to realtime network monitoring interfaces, specify the appropriate parameters on the NETMONITOR statement:
  • NETMONITOR ZERTService indicates that zERT SMF 119-11 records are to be written to the the SYSTCPER realtime network monitor interface (NMI) service.
  • NETMONITOR NOZERTService indicates that zERT SMF 119-11 records are not to be written to the the SYSTCPER realtime network monitor interface (NMI) service. This is the default.
  • NETMONITOR ZERTSUMmary indicates that zERT SMF 119-12 records are to be written to the the SYSTCPES realtime network monitor interface (NMI) service.
  • NETMONITOR NOZERTSUMmary indicates that zERT SMF 119-12 records are not to be written to the the SYSTCPES realtime network monitor interface (NMI) service. This is the default.



Question: How can I enable and configure IBM zERT Network Analyzer?

Answer:
Take the following steps to enable and configure the zERT Network Analyzer:
    1. Enable collection of zERT Summary (SMF Type 119 subtype 12) SMF records
    2. Dump the collected zERT Summary records to a sequential data set using the IFASMFDP or IFASMFDL program
    3. Enable the IBM zERT Network Analyzer plug-in in z/OSMF by adding ZERT_ANALYZER to the PLUGINS statement
    4. Authorize the user IDs that will be using IBM zERT Network Analyzer
    5. Create the proper Db2 for z/OS database definitions to use with IBM zERT Network Analyzer
    6. Start the z/OSMF IBM zERT Network Analyzer plug-in
    7. Import the dumped zERT SMF Summary records into IBM zERT Network Analyzer
    8. Analyze the imported zERT Summary data using IBM zERT Network Analyzer query and reporting functions
References:


Question: Is there any host system customization needed before using the zERT Network Analyzer?

Answer:
Yes. If you want to configure the zERT Network Analyzer, you have additional system customization to perform. The IBM zERT Network Analyzer task stores and queries SMF data in a Db2 for z/OS database. Before you can use the task, this database must be created in a suitable Db2 for z/OS subsystem and the connectivity information for the database must be configured in the IBM zERT Network Analyzer. See the following two topics for more details.



Other tools that support zERT data

Question: 
Besides zERT Network Analyzer, are there any other tools that can be used to analyze zERT data?

Answer:
Yes, there are numerous ways zERT SMF data can be processed and analyzed. While this should not be considered to be an exhaustive list, the ones we are currently aware of are:
  • IBM zSecure Audit V2.3 (supports subtype 11 and subtype 12 records)
  • IBM QRadar Security Information and Event Management (SIEM) (supports what zSecure feeds it)
  • Merrill Technologies MXG (feeds subtype 11 and subtype 12 records into SAS)
  • Broadcom (formerly CA Technologies) NetMaster Network Management for TCP/IP 12.2.03 (supports subtype 11 records through NMI)
  • BMC Mainview for IP 3.6 (supports subtype 11 and subtype 12 records through NMI)
  • Vanguard Advisor 2.3 (supports subtype 11 records)
  • Intellimagic Vision (supports subtype 12 records)
  • IBM NetView Version 6.3 (will add support for subtype 11 records through NMI in 4Q2019). Here are the announcements:
  • IBM Z Common Data Provider Version 2.1.0 (collects subtype 11 and subtype 12 records)


Question: How does the zERT Network Analyzer compare to other tools?

Answer:
The zERT Network Analyzer is focused on allowing z/OS network security administrators to mine data from zERT Summary (SMF 119-12) records collected over time and from one or multiple z/OS systems. With the zERT Network Analyzer, you can build your own queries over the collected SMF data for a specific scope (systems, endpoints, timeframe) and security attributes (protection protocols, cryptographic algorithms, key lengths, etc.). The query results are presented in a summarized view into which the user can "drill down" into more and more detail.


In contrast, other tools provide a variety of functions based on zERT SMF data, from ingestion into SAS databases to real-time connection monitoring. This range of products and capabilities illustrates the value and possibilities that zERT brings to the table.