Creating a cryptographic inventory
Before transitioning to quantum-safe algorithms, it is important to create a cryptographic inventory that covers all aspects of cryptography in your enterprise. This process includes classifying the data to help you identify where your sensitive data is stored inside and outside the IBM Z environment.
The cryptographic inventory also lists the certificates, encryption protocols, algorithms, and key lengths that are used and indicates those that are weakened by quantum computers. For more information about for an approach for creating a cryptographic inventory, see “Establishing a cryptographic inventory” on page 58.
This chapter shows you how to configure, run, and interpret the results for each of the cryptographic inventory creation tools and includes the following topics:
5.1 Collection tools overview
IBM provides several tools that can aid in the cryptographic discovery process and developing a cryptographic inventory for your IBM Z environment. Each tool provides unique information for creating a cryptographic inventory:
•IBM z/OS Integrated Cryptographic Service Facility (ICSF) cryptographic usage tracking records are written as SMF records aggregating usage of cryptographic engines, cryptographic services, and cryptographic algorithms.
•IBM Application Discovery and Delivery Intelligence (ADDI) analyzes COBOL application files that capture valuable metadata and dependencies by identifying important ICSF parameters for crypto algorithms.
•IBM Crypto Analytics Tool (CAT) creates snapshots of the z/OS environment by extracting security and cryptographic information that is based on defined policies.
•IBM z/OS Encryption Readiness Technology (zERT) collects and reports the cryptographic security attributes of IPv4 and IPv6 application traffic that is protected by using the TLS/SSL, SSH, and IPsec cryptographic network security protocols.
After the information is collected, perform a gap analysis to determine whether business, compliance, and audit requirements are being met. The gap analysis aids you in prioritizing updates for your environment.
For more information about a process for making use of the various tools to identify the cryptographic algorithm, key length, and key label information that is related to COBOL programs, see Appendix A, “Finding cryptographic attributes” on page 121.
5.2 Using ICSF cryptographic usage tracking
Beginning with ICSF FMID HCR77C1, ICSF instances can be configured to collect cryptographic usage data when crypto operations are performed by that ICSF instance. ICSF creates an SMF record type 82, subtype 31 to aggregate crypto usage statistics for each job or user that is associated with the crypto usage in a specified period.
|
Note: It is essential to collect the records over a sufficient period, capturing as much workload and key usage as possible. This process helps build a more comprehensive cryptographic inventory.
|
ICSF cryptographic usage tracking (see Figure 5-1) features the following options for collecting statistics:
•ENG: Crypto Express adapters, CPACF, and software
•SRV: ICSF callable services and UDXes
•ALG: Cryptographic algorithms that are used within ICSF crypto operations
Figure 5-1 ICSF cryptographic usage tracking overview
5.2.1 Configuring SMF for ICSF cryptographic usage tracking
Before ICSF can write SMF records for cryptographic usage, the SMFPRMxx member in PARMLIB (see Example 5-1 on page 74) must be updated to contain the following components:
•The collection interval (INTVAL).
Cryptographic usage tracking is synchronized to the SMF recording interval. In our example, ICSF records crypto usage every 5 minutes.
•The synchronization value (SYNCVAL).
Synchronizes the recording interval with the end of the hour of the TOD clock. In our example, ICSF starts recording crypto usage at the end of the hour.
•The Cryptographic Usage Statistics subtype 31 for ICSF type 82 records (TYPE).
Specifies the type of records to be recorded. In our example, SMF 82 subtype 31 is specified.
Example 5-1 SMFPRMxx member example
DSNAME(SMF.MANA,SMF.MANB) /* SMF Data sets */
INTVAL(05) /* INTERVAL – 5 minutes */
SYNCVAL(00) /* SYNCHRONIZATION – 0 minutes */
SYS(TYPE(0,2,3,82(31),83,128:132)) /* ICSF SMF 82 subtype 31 */
5.2.2 Enabling cryptographic usage tracking within ICSF
Cryptographic usage tracking can be enabled within ICSF by using one of the following methods:
•Through the installation options that are used for ICSF initialization
The CSFPRMxx member in PARMLIB must contain the STATS option. As shown in Example 5-2, all three STATS options are enabled. STATS(ALG) must be specified to enable algorithm usage tracking. STATSFILTERS(NOTKUSERID) can be optionally specified to exclude the task level user ID from the stats aggregation criteria. This option is intended for environments that features a high volume of operations that are running under task level user IDs, which reduces the number of SMF 82 Subtype 31 records written.
Example 5-2 CSFPRMxx options
CKDSN(SYS1.CKDS)
PKDSN(SYS1.PKDS)
TKDSN(SYS1.TKDS)
STATS(ENG,SRV,ALG)
STATSFILTERS(NOTKUSERID)
Example 5-3 SETICSF command
SETICSF OPT,STATS=(ALG)
The STATS setting can be verified by using the DISPLAY ICSF,OPT command (see Example 5-4).
Example 5-4 DISPLAY ICSF,OPT output
D ICSF,OPT
CSFM668I 12.44.17 ICSF OPTIONS 907
SYSNAME = SY1 ICSF LEVEL = HCR77D2
LATEST ICSF CODE CHANGE = 02/21/22
Refdate update interval in Days/HH.MM.SS = 005/00.00.00
Refdate update period in Days/HH.MM.SS = 000/01.00.00
MASTERKCVLEN = display ALL digits
AUDITKEYLIFECKDS: Audit CCA symmetric key lifecycle events
SYSNAME LABEL TOKEN
SY1 Yes Yes
AUDITKEYLIFEPKDS: Audit CCA asymmetric key lifecycle events
SYSNAME LABEL TOKEN
SY1 Yes Yes
AUDITKEYLIFETKDS: Audit PKCS #11 key lifecycle events
SYSNAME TOKOBJ SESSOBJ
SY1 Yes Yes
AUDITKEYUSGCKDS: Audit CCA symmetric key usage events
SYSNAME LABEL TOKEN Interval Days/HH.MM.SS
SY1 No No 000/02.00.00
AUDITKEYUSGPKDS: Audit CCA asymmetric key usage events
SYSNAME LABEL TOKEN Interval Days/HH.MM.SS
SY1 No Yes 000/01.00.00
AUDITPKCS11USG: Audit PKCS #11 usage events
SYSNAME TOKOBJ SESSOBJ NOKEY Interval Days/HH.MM.SS
SY1 No No Yes 000/05.00.00
STATS:
SY1 ALG
COMPLIANCEWARN: Compliance warning events
SY1 PCI-HSM 2016 Yes
TRACKCLASSUSAGE:
SY1 NONE
5.2.3 Formatting cryptographic usage statistics records
After ICSF cryptographic usage tracking is enabled for algorithms, run applications on the ICSF instances with tracking enabled. As a result, SMF cryptographic usage records are generated.
ICSF provides formatters in SYS1.SAMPLIB (CSFSMFJ) that is the JCL that can be submitted to read SMF record type 82 and format them into a report. CSFSMFR is the REXX exec that is used to run the report against the SMF records.
A formatted report of SMF record type 82, subtype 31 (hex ‘001F’) is shown in Example 5-5.
Example 5-5 Formatted report of SMF record type
Type=82 Subtype=001F Crypto Usage Statistics
Written periodically to record crypto usage counts
22 Feb 2022 15:12:27.73
TME... 005389D5 DTE... 0122053F SID... SP21 SSI... 00000000 STY... 001F
INTVAL_START.. 02/22/2022 19:11:30.001815
INTVAL_END.... 02/22/2022 19:12:27.737573
USERID_AS.....DATAOWN
USERID_TK.....
JOBID.........J0000055
JOBNAME.......DATAOWN
JOBNAME2......
PLEXNAME......SYS1
DOMAIN........0
ENG...CARD...8C11/99EA6127...17
ENG...CPACF...150
ALG...DES56......2
ALG...AES128.....2
ALG...RSA1024....1
ALG...ECCBP192...1
ALG...MD5........45
ALG...RPMD160....15
ALG...SHA1....... 70
ALG...SHA3-224... 13
ALG...SHA3-256... 15
ALG...SHA3-384... 13
ALG...SHA3-512... 13
ALG...SHAKE128... 12
ALG...SHAKE256... 14
SRV...CSFKYT..... 2
SRV...CSFDSG..... 2
SRV...CSFOWH..... 264
SRV...CSFOWH1.... 3
SRV...CSFIQF..... 485
SRV...CSFIQF2.... 2
**************************************************
Interpreting cryptographic usage statistics SMF records
After you formatted the cryptographic usage statistics SMF records, you can begin identifying algorithms that are used in applications that must be replaced.
In Example 5-5 on page 75, algorithms DES56, AES128, and RSA1024 were used in crypto operations within the SMF recording interval. The SMF record lists the HOME address space ID or HOME address space job name, which are the job or task that started the cryptographic request.
The SMF record also can list the SECONDARY address space job name (for example, the caller that made the program call or space switch to ICSF), the HOME address space user ID, and the task level user ID if available.
In Example 5-5 on page 75, the usage event is recorded for jobname DATAOWN. It occurred on system SYS1 and used crypto domain 0.
DES56, RSA1024, AES128, SHA-1 are examples of weak algorithm candidates to prioritize for migration in your cryptographic inventory.
5.3 Using IBM Application Discovery and Delivery Intelligence
IBM ADDI (see Figure 5-2) is an analytics platform for mainframe application modernization. It identifies and visualizes application dependencies and helps you quickly understand the impact of changes.
Figure 5-2 IBM ADDI flow
IBM Application Discovery Build Client is part of the IBM ADDI product suite. By using IBM Application Discovery Build Client to perform application crypto analysis, you can realize the following benefits:
•Efficiently locate and identify where crypto is used in applications.
•Capture valuable metadata and dependencies by identifying important ICSF parameters, such as “Rule Array”.
•Store analysis results in a repository.
•Plan migration and modernization efforts.
•React quickly to potential security issues.
|
Note: As of this writing, this support is available for COBOL applications only.
|
5.3.1 Configuring IBM AD Build Client for ICSF crypto analysis
The following steps assume that the installation and configuration process is complete for ADDI. For more information about this process, see this IBM Documentation web page.
Complete the following steps to configure and run IBM Build Client against your COBOL application:
1. Verify that the CRYPTO resolutions file (CAPIResolutions.json) is available in the in
elease folder. This folder is where the AD Build Client executable (IBMApplicationDiscoveryBuildClient.exe) is stored.
The following default path is used by the installation:
C:Program FilesIBM Application Discovery and Delivery IntelligenceIBM Application Discovery Build Clientin
elease
|
Note: After the installation is complete, CAPIResolutions.json can be found in the in
eleaseSamples folder. Copy the .json file and place it in the bin
elease folder.
|
2. Open the AD Build Client tool and create a project by clicking File → New → New Project (see Figure 5-3).
Figure 5-3 Creating an IBM AD Build client
3. Upload your COBOL application files to the project. You should downloaded these files from your mainframe. These COBOL files are scanned and analyzed for CALL statements, which are calls to ICSF cryptographic services. Complete the following steps:
a. Right-click zOS Cobol project folder → Add Files.
b. Locate the files on your local machine, select them, and click OK.
c. Repeat step 2 until all application files are added to the project.
Figure 5-4 IBM AD add COBOL application window
4. Build the project by clicking Build → Build Project. Then, wait until the build process completes. Two files are generated that are related to ICSF crypto CALLs:
– GenericAPI_<timestamp>.csv
– GenericAPI_<timestamp).html
5. Locate the Project path on disk and the change directory to:
<Project path>/Reports/GenericAPI.
For example:
C:IBM ADMainframe Projects<your_project_name>ReportsGenericAPI
The .csv file can be read as is or used as input by other tools as raw input.
The .html file can be used as a report where the results can be filtered according to various criteria.
5.3.2 Interpreting IBM AD Build Client file results
In Figure 5-5, each CALL statement is uniquely identified by an ID in column A (OccurID); CALLs to ICSF CRYPTO service are in column B (APIName). The file where the CALL is stored is in column K (PathStr) at the line in column L (StartRow).
The CALLs parameter values are in column G (ParamValue) and form one of more tuples in column H (GroupID), which correspond to the parameter positions column F (OrdinalPos) that is specified in the CAPIResolutions.json for the respective service.
If no CALL statements to ICSF cryptographic services are found within the COBOL source files, an empty report is generated with the message:
GenericAPI query returned no results.
Figure 5-5 IBM AD Build client results example
When reviewing the results, pay attention to the APIMetadata and ParamValue columns. These columns provide insight into the type of algorithms that are used within the ICSF crypto service call. When building your cryptographic inventory, consider adding programs that contain ICSF calls with weak algorithms, such as DES.
5.3.3 Interpreting the CRYPTO CAPIResolutions.json resolutions file
The CRYPTO Resolutions (CAPIResolutions.json) file is a configuration file with the possible API calls, the parameters to capture, and information about ICSF calls. The ADDI build process uses this file to capture the data and can be extended or customized (see Example 5-6).
Example 5-6 CRYPTO Resolution file snippet example
{ "formatVersion":"1.0",
…
"GenericAPIs":
[
...
{ "GenericAPIName":"CSNBENC1,CSNEENC1",
"Description":"Encipher",
"Metadata":"DES",
"Metadata1": "Encryption/Decryption",
"Parameters":
[
{ "Name":"RULE_ARRAY_COUNT",
"Position":9,
"DefaultValues":"0" },
{ "Name":"RULE_ARRAY",
"Position":10,
"DefaultValues":"INITIAL, TOKEN" }
]
}
...
]
}
Where:
•GenericAPIName: Name of the ICSF service (if that service has several names, you can initialize it with all of the values separated by comma)
•Description: Short description of the service
•Metadata: Algorithm used by that service
•Metadata1: Category to which that service belongs
•Parameters: Array of parameter objects where each object includes the following information:
– _Name: Parameter name (for example, for the Rule Array Parms column: RULE_ARRAY_COUNT and RULE_ARRAY names are used. For any Other Parms, PARAM<No> is used; for example, PARAM6, PARAM7, and PARAM8).
– _Position: Position of that parameter for which we want to collect its values.
– _DefaultValues: Comma-separated default parameter values, if applicable.
5.3.4 Extending the CRYPTO CAPIResolutions.json resolutions file
If you use an abstraction layer within the COBOL source files that is built on top of the standard cryptographic libraries (CCA and ICSF), the CAPIResolutions.json file must be edited and extended with the client interfaces (see Example 5-7).
Example 5-7 Custom CAPIResolutions.json file
{
"GenericAPIName":"MYENCPHR",
"Description":"Custom Encipher",
"Metadata":"DES",
"Metadata1": "Custom Implementation of Encryption/Decryption",
"Parameters":
[
{ "Name":"RULE_ARRAY_COUNT",
"Position":9,
"DefaultValues":"0"
},
{ "Name":"RULE_ARRAY",
"Position":10,
"DefaultValues":"INITIAL, TOKEN"
}
]
}
5.4 Using IBM Crypto Analytics Tool
The IBM CAT provides a graphical interface that is used to search, display, and analyze data that is extracted from the different cryptographic components. The findings are presented in generated reports.
IBM CAT also can apply a set of policy rules that can be used to analyze the extracted data and flag whether the objects are compliant or noncompliant according to the policy rules (such as reporting non-quantum-safe keys).
5.4.1 IBM CAT overview
IBM CAT features the following components (see Figure 5-6):
•A data collection for z/OS that consists of load modules and compiled REXX execs to extract cryptographic and security-related information from z/OS systems. The extracted data is loaded into the IBM Crypto Analytics Tool DB2® database and provides “snapshots”.
•The Crypto Analytics Tool client is a workstation program that accesses the Crypto Analytics Tool database by using a JDBC connection to generate the reports.
Figure 5-6 CAT architectural overview
5.4.2 Reported elements
Whenever you are running the z/OS data collection, the Db2 tables are populated with the results of the data collection, called snapshots. The following elements are reported by CAT in the snapshots:
•ICSF configuration
The ICSF configuration report provides basic information about the ICSF status at the time of the snapshot (sysplex mode, initialization status, CKDS format, and so on). The report also provides the status of runtime options (such as special secure mode and PCF coexistence), the ICSF policies, exit routines, and UDX services.
•Protected verbs and utilities
The protected verbs and utilities report lists all the ICSF services and extracts from RACF the profiles that are protecting these services along with the access list to the profiles.
•Crypto Express
This report provides a list of adapters that are assigned to the LPAR where the snapshot was taken, along with the status of the master keys. The report also provides the access points (ACPs) setup.
•Key data sets (xKDS)
The Key data sets report provides the name of the xKDS along with the status of their RACF protection. It also includes the Masters Keys verification patterns.
•Keys
For each type of key (DES, RSA, AES, and so), this report lists all the keys (with a search option) and their type, size, metadata, and so on. For each key, their RACF protection profiles can be displayed along with the options for the ICSF segment, such as SYMCPACFWRAP.
•RACF
The RACF report provides the list of all the RACF profiles in the classes that are related to cryptography, such as CRYPTOZ and CSFSERV. The report also provides the list of users and groups with access to these profiles, along with the certificates and key rings that are present in RACF.
5.4.3 Monitoring functions
CAT provides the following monitoring functions:
•Queries
In CAT Monitor, predefined queries can be performed. Two types of queries are available: Queries that compare two selected snapshots, and queries that generate a report for a selected snapshot.
For example, by using the comparison function, the comparison report highlights the new keys that are found in the keystore if you compare two different snapshots after a key generation event.
•Policy check
With the policy check, set of policy rules can be specified that can be used to analyze the extracted data and flag whether the objects are compliant or noncompliant according to the policy rules. The set of policy rules can be tailored according to your own policy.
5.4.4 Crypto Analytics Tool use case
In this use case, we see how you can use CAT to generate a policy report to identify non-Quantum-safe keys in your ICSF keystore. For example, analyzing our AES keys that are stored in the ICSF CKDS and report any anomaly, such as a weaker AES 128 key.
For this example, it is assumed that the CAT z/OS data collection component is installed and that the data collection is run at a regular interval.
The CAT Monitor was installed on a workstation, the JDBC license was copied into the <CATMonitor>configurationlicense directory, and the Db2 connection information is provided.
First, we activate the default policy, verify the content of the policy for AES keys and then, apply it to our AES 256 keys.
5.4.5 Activating the policy
We enable the built-in Policy. On the workstation where CAT is installed by selecting Window → Preferences.
By default, the built-in policy is not activated. To activate it, select the policy and click Set Active and then, Apply (see Figure 5-7).
Figure 5-7 CAT Policy Activation
5.4.6 Checking the policy
To verify the content of the policy, select the policy and then, click Edit.
The policy editor is displayed (see Figure 5-8), which includes the name of the policy, a description, and a tab for each of the cryptographic elements where a policy can be applied.
Figure 5-8 CAT Policy Editor
If we select the AES Keys tab, we can see that the default policy reports any AES128 key that is created after 2004-01-01, any AES192 key created after 2011-01-01, and so on.
As shown in Figure 5-9, the policy also reports any keys with identical Key Check Value (KCV); that is, those key labels have the same key value.
Figure 5-9 AES Key Length Policies
Exit the Preference dialog by clicking Cancel twice.
5.4.7 Applying the policy to a snapshot
When back in CAT main window, select and expand a snapshot in the Systems Explorer frame.
In the ICSF section, the types of keys that are present in the key data sets are listed. As shown in Figure 5-10 on page 87, we right-clicked AES Keys and then, selected Policy → Verify AES Keys.
Figure 5-10 Running the AES Key Policy
The Policy Check report is displayed. In Figure 5-11, the Policy Check Report is highlighting that some noncompliant AES keys were found in our keystore.
Figure 5-11 CAT Monitor AES Policy Check Report
By clicking the highlighted policy exception, the list of keys (see Figure 5-12) shows that only one was found as not compliant in the policy check report. When selecting each key, details about the key and the associated metadata are displayed.
Figure 5-12 AES non-policy-compliant keys display
5.5 Using IBM z/OS Encryption Readiness Technology
IBM zERT is a communications server feature that provides information about the cryptographic network protection state of TCP/IP and Enterprise Extender connections that end on a z/OS system. It also reports their usage in SMF records.
With IBM zERT Network Analyzer (see Figure 5-13), a web-based GUI runs under z/OSMF. z/OS network security administrators can analyze and report on the data that is reported in zERT Summary records (SMF type 119 subtype 12).
Figure 5-13 zERT Process
|
Note: At least Db2 for z/OS V11 is required as the database repository for IBM zERT Network Analyzer.
|
With z/OS 2.5 and zERT Policy Enforcement, you can define required network security policy, including the encryption algorithm in use and then, direct the TCP/IP stack to take specific actions for connections that do not meet that defined policy through the policy agent (PAGENT).
5.5.1 Enabling zERT for zERT Network Analyzer
To generate the zERT summary records, the following parameters are required in the TCP/IP configuration profile:
•ZERT AGGREGRATION in the GLOBALCONFIG section
•TYPE119 ZERTSUMMARY in the SMFCONFIG section
Also, the z/OS SMF configuration parmlib member should enable the collection of the SMF type 119 records.
5.5.2 Using IBM zERT Network Analyzer
In this section, we demonstrate how zERT network analyzer can be used during the cryptographic inventory step to provide encryption algorithms data for z/OS Communications Server.
Configuration tasks overview
Before IBM zERT Network Analyzer is used, the following configuration tasks are required:
•Authorize the user IDs to use the IBM zERT Network Analyzer (see SYS1.SAMPLIB(IZUNASEC).
•Work with your Db2 for z/OS database administrators to create the Db2 database objects and connect IBM zERT Network Analyzer to the Db2 database.
Populating IBM zERT Network Analyzer database
To perform this task, you need cataloged SMF dump data sets with the SMF record type 119 and subtype 12, zERT aggregation records. The z/OSMF task (usually user IZUSVR) must be authorized to read the SMF dump data sets.
Complete the following steps:
1. In the main IBM zERT Network Analyzer page, select Data Management → Import SMF Data → Add data set. Add all the required SMF dumps data sets.
2. Select all of the data sets that you want to import in the database and then, click Import Selected. Then, confirm that you want to import the selected data sets (see Figure 5-14).
Figure 5-14 IBM zERT Network Analyzer Import SMD Data
The import operation is asynchronous, and the completion of the import can be checked in the Data Management History window by reviewing the Status column (see Figure 5-15). The task can be selected to expand to a detailed view of the import operation (number of records added, duplicate, and ignored).
Figure 5-15 IBM zERT Network Analyzer SMF import details
Building your first query
Now that the SMF data is imported into the Db2 database, you can build your first query. Complete the following steps:
1. In the main IBM zERT Network Analyzer page (see Figure 5-16), select Queries → New query. Here, you must provide a query name and (optionally) a description for the query.
Figure 5-16 IBM zERT Network Analyzer creating a new query
By default, the query retrieves all available SMF records, and reports on all of the data that is available in the Db2 database.
However, to limit the output of the query and select more valuable information, you can add a scope filter. This filter can limit the output to a specific data range (such a, the last 30 days), the sysplex/systems/TCP/IP stack, the TCP or Enterprise Extender IP, ports, and client IP (see Figure 5-17).
Figure 5-17 IBM zERT Network Analyzer query scope filter
You can limit the output of the query by selecting Security Filters. In the Security filter window, you can limit the output of the query to specific security traffic (unprotected, IPsec, TLS, and SSH). Within a security traffic, such as TLS, you can limit the output to specific algorithms (see Figure 5-18).
Figure 5-18 IBM zERT Network Analyzer Security session filters
2. After your query definition is complete, click Save and run query. After confirmation, the query runs and the result is available in the Report window.
Viewing the query result
The query results are available in the Report window (see Figure 5-19).
Figure 5-19 IBM zERT Network Analyzer query result
The query result features one summary line, with the Sysplex, System, Stack, and Server IP along with the ports, jobname, and summary information about the type of session that was reported (unprotected, IPsec, SSH, and TLS).
You can expand the results, and get more information by clicking the query result line.
IBM zERT Network Analyzer shows the list of Clients IP along with another summary of the sessions. You can get more information about the sessions for a specific client or all the clients by selecting the IP addresses that you want to analyze and then, clicking View security session details (see Figure 5-20).
Figure 5-20 IBM zERT Network Analyzer client details
The report displays (see Figure 5-21). For each client IP selected, the details about the security are provided (Protocol version, Key Exchange Algorithm, and so on).
Figure 5-21 IBM zERT Network Analyzer security session details
All the query results are exportable, and can be used in spreadsheet by clicking Export to CSV.
Creating your own data-in-transit cryptographic inventory
From the previous example, we discovered that we can create specific targeted reports about specific types of security sessions and algorithms by using the IBM zERT Network Analyzer.
Then, you can build a cryptographic inventory for your data-in-transit, with specific attributes, such as the clients/servers you are targeting, the protocols or cryptographic algorithms (which is useful to prepare a transition for specific applications/client-servers in the enterprise).
5.5.3 Monitoring data in-transit by using zERT
With z/OS 2.5, a feature called zERT Enforcement Policy was introduced. With this feature, you can now define a policy with filters that is based on addresses, ports, jobname, encryption algorithm, and ciphers. Then, you can take actions if the connection is not “in policy”. The actions can be logging only (SMF, syslogd, and console) or resetting the TCP/IP connection. The policy is enforced by the Policy Agent address space (PAGENT).
Creating a policy
To create a zERT Enforcement Policy, it is recommended to use, the z/OSMF Network Configuration assistant (see Figure 5-22) as is done with the others policy agent-based policies (such as AT/TLS and IPsec).
Figure 5-22 Main page of z/OS Configuration Assistant
In the policy, you can define multiple criteria that the connection needs match to trigger the policy. Then, in the actions, you define what occurs if such connection is established.
For example, you can reset a nonsecure connection and disconnect the client so that no information transits in this nonsecure connection.
In our environment, TN3270clear connection requests coming from IP address 10.0.0.111 are not permitted (see Figure 5-23). Therefore, the client immediately disconnects after reporting the information in the z/OS log.
Figure 5-23 zERT Rule information
After activating the policy through the policy agent, we can see in the PAGENT log (refer to Example 5-8) that message EZZ8771I is issued. We also see that the TN3270 client with an IP address of 10.0.0.111 starts a nonsecure connection, which is immediately reported and disconnected through a reset of the connection (message EZZ8562I).
Example 5-8 PAGENT Log
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR TCPIP : TTLS
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR TCPIP : ZERT
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
AZFGroupAction1
EZZ6035I TN3270 DEBUG CONN DETAIL 373
IP..PORT: 10.0.0.111..53854
CONN: 000056FA LU: SYSZTCP8 MOD: EZBTTRCV
RCODE: 1001-01 Client disconnected from the connection.
PARM1: 00000000 PARM2: 00000000 PARM3: 00000000
EZZ6034I TN3270 CONN 000056FA LU SYSZTCP8 SESS DROP CLNTDISC 374
IP..PORT: 10.0.0.111..53854
IKT100I USERID CANCELED DUE TO UNCONDITIONAL LOGOFF
IKT122I IPADDR..PORT 10.0.0.111..53854
EZZ6034I TN3270 CONN 000056FA LU SYSZTCP8 CONN DROP CLNTDISC 376
IP..PORT: 10.0.0.111..53854
EZZ6034I TN3270 CONN 0000571C LU **N/A** ACCEPTED 23 378
IP..PORT: 10.0.0.111..55623
EZZ8562I CONN RESET BY ZERT POLICY 379
EZZ8552I STACK= TCPIP CONNID= 0000571C CONNDIR= INBOUND
EZZ8553I LOCALIPADDR= 10.0.0.216 LOCALPORT= 23
EZZ8554I REMOTEIPADDR= 10.0.0.111 REMOTEPORT= 55623
EZZ8555I TRANSPROTO= TCP JOBNAME= TN3270 USERID= TCPIP
EZZ8556I SECPROTO= NONE SECPROTOVERSION= N/A
EZZ8560I RULE= TN3270clear
EZZ8561I ACTION= Reset__Console
This example shows a simple policy, but during your quantum-safe journey, you can define rules that are based on these encryption algorithms to prevent (or report real-time) connections that use non-quantum-safe encryption algorithms.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.