IBM i System Logging – QHST Messages

IBM i users who need to meet compliance regulations for actively monitoring their systems are faced with the challenge of collecting system and security events from a variety of log sources. Collecting events from the security audit journal QAUDJRN is a fundamental requirement, but is it the only place that contains significant security events? The answer is no, there are also significant security events in the system history message file QHST.

The most significant security events contained in QHST are the user log on and log off messages. These are stored in the QHST message files with message IDs CPF1164 (log on) and CPF???? (log off). User log on and log off events are, of course, critical for active monitoring of system access, especially for highly privileged users such as QSECOFR and any user with All Object (*ALLOBJ) and security special authorities of Audit (*AUDIT) and ????.  The log on and log off activities recorded in the QHST message files are not available in the security audit journal QAUDJRN, so you must be able to retrieve these messages from QHST to meet compliance regulation requirements for log collection and active monitoring.

Alliance LogAgent supports this requirement by enabling the collection of these events from QHST message files. You can filter QHST message to collect only events for:

• Log on and Log off messages for all users
• Log on and Log off messages for only highly privileged users
• Log on and Log off messages for only QSECOFR
• All QHST messages

User log on and log off messages are not the only events that have security information. Most IBM i customers will select the Alliance LogAgent option to process all messages in QHST. This gives you a complete record of all events in the QHST message file in your log collection central repository.

There are many challenges in processing messages in the QHST file. These include:

• The QHST information is in an IBM proprietary format that is impossible for log collection servers and SIEM solutions to process. The messages must be converted to a usable format.
• QHST message files have a special naming convention and the system automatically generates new QHST message files on a regular basis. You must detect new message files and keep track of which files and messages have been processed.
• There are no event-driven APIs that allow you to collect new QHST messages in real time. Your QHST collector application must detect new events and process them quickly.
• The QHST files are not updatable, so your QHST event collector must keep track of the messages that have been processed, and must resume after a system IPL or a system failure without lost information.
• QHST messages are not automatically transferred to a log collection server or SIEM solution. Communications programs must be able to transfer the messages in real time.

Alliance LogAgent meets all of these challenges. QHST message files are automatically processed in near real time, and handles the generation of new QHST message files by the system. Messages are converted from the proprietary IBM format to the industry standard syslog format (RFC 3164) and converted from EBCDIC to ASCII. Messages are then transmitted to the log collection server or SIEM solution securely and in real time.

The Alliance LogAgent QHST message collector is a part of the base product. If you are currently using LogAgent to process QAUDJRN events, you can just enable the QHST option and you will start processing messages the next time the Alliance LogAgent subsystem starts. If you are implementing Alliance LogAgent for the first time, just enable the Logagent QHST collector before you start the subsystem.

View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

Patrick