S 5.113 Use of the VTAM Session Management Exit under z/OS
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: Specialists Responsible, Administrator
The VTAM (Virtual Telecommunication Access Method) component in z/OS offers the option of providing the login process with additional protection using a VTAM Session Management Exit (ISTEXCAA). This exit is triggered when starting and terminating the VTAM session and allows the following functions to be executed:
- Session authorisation
Checking and allowing/denying logical unit sessions - Session accounting
Collecting session accounting data for analysis at a later time - Adjacent SSCP selection
Selection of an SSCP according to defined rules (routing) - Support of the session takeover in the framework of XRF application processing
The VTAM Session Management Exit is frequently used for the first two functions; for the last two, on the other hand, it is only used in a few special cases. The VTAM Session Management Exit must be created internally by the organisation or purchased. The manufacturer does not supply a VTAM Session Management Exit with the operating system.
The following recommendations should be considered for the use of the VTAM Session Management Exits.
Programming information
Knowledge of Assembler
The exit must be programmed in Assembler. In addition, good knowledge of the VTAM software is a prerequisite. If the necessary knowledge and skills are not available in an organisation, then consideration should be given to using alternative software products available on the market. These products are often more secure and easier to install.
Performance
The exit can affect the VTAM performance significantly. For this reason, it must be ensured that no time-consuming operations, for example reading files, are performed when running the exit.
Definitions
It should be possible to reload all definitions that the exit uses during operation dynamically without having to stop other operational functions.
If possible, it should be possible to define the set of rules (policy) for the exit externally (i.e. the program should not contain any definitions).
Supported functions
The following functions should be supported in the exit at a minimum:
- writing a LOG entry (Syslog)
- writing an SMF record
- interface to WTO (Write to Operator) for rejections
This makes it possible to subsequently check for rejected login attempts. Additional statistical information can also be recorded as an option, but this information can also be derived from the SMF records.
Protecting the security rules
The set of rules (policy) for the exit should be stored in a separate file that is loaded into the main memory the first time the exit is executed. Only those employees whose jobs require that they have access to this file should be granted access to it. This applies especially when the policy of the exit is stored in the current VTAMLST file. It should be examined if concatenating the different VTAMLST files would help to increase the security of the operation. Different VTAMLST files permit different access rights, while the concatenated files are handled in terms of processing like a single file. Substitution arrangements must be specified.
VTAM commands
The VTAM Session Management Exit can be enabled and disabled dynamically during operation using the VTAM Modify command. Appropriate RACF definitions must ensure that only the employees whose job requires them to have access to this command should have access to it. Substitution arrangements must be specified.
Use of NetView ALIAS name translation
Functions for ALIAS Name Translation can be used in the VTAM Session Management Exit. The NetView ALIAS Name Translation Facility can also be used parallel to it. The latter is indicated by a flag. If both facilities are used, then it must be ensured that the ALIAS Name Translation options of both agree with each other and do not contradict each other. For example, different aliases should not be specified for the same name.
Review questions:
- Is it ensured during exit programming under z/OS that it is possible to reload all definitions that the exit uses during operation dynamically without having to stop other operational functions?
- Is it ensured during exit programming in z/OS that the program does not contain any definitions, but that it is possible to define the set of rules (policy) for the exit externally?
- Is the set of rules (policy) for the exit in z/OS stored in a separate file that is loaded into the main memory the first time the exit is executed?
- Is it ensured by z/OS RACF definitions that only the employees whose job requires them to have access to the VTA Modify command have access to it?