SIEM: How IBM i Systems Fit into SIEM Environments

It’s important to understand the basics when transmitting IBM i information to Security Information and Event Management (SIEM) systems for enterprise-wide security analysis. Here’s a quick rundown of what a SIEM is, its relationship to IBM i servers, and how to capture and transmit IBM i security data to a SIEM system.  

What is a SIEM? 

A Security Information and Event Management (SIEM) system collects, aggregates, and analyzes security information from various systems across an organization, network, or other digital environments. Security information is collected from a wide variety of devices, including firewalls, routers, servers, applications, network devices, endpoints, and more.  

Enterprise security teams use SIEM data to produce a single view of their security posture that can be used for forensic analysis (identifying and reporting on system issues that have already occurred) and predictive analysis (monitoring, alerting, and reporting on developing security trends across the enterprise).  

SIEMs help organizations address potential security threats and vulnerabilities before they disrupt business operations. They track and analyze security data using user and behavioral analysis, security analytics, AI, machine learning, and other advanced capabilities. 

Capturing IBM i security and event information in QAUDJRN 

For complete enterprise threat visibility, many organizations are now requiring IBM i security event information to be collected and aggregated into their enterprise SIEM systems.  

Audit control and journaling must be configured correctly to capture IBM i security data. Here are the three steps needed to set up auditing control and journaling on an IBM i server.  

1. Activate Audit Control and Journaling on your server
2. Specify which users you want to collect security auditing information for
3. Specify the objects that you want to collect security auditing information for 

Audit journal entries are saved in the IBM i audit journal (QAUDJRN). QAUDJRN is the primary source for IBM i security event information and its journal entries can be transferred to a SIEM.  

Step 1: Activate audit control and journaling on your server 

Audit control and journaling can be activated or modified by running the Change Security Auditing (CHGSECAUD) command (figure 1). It uses the following parameters for auditing information capture. 

• QAUDCTL system value (QAUDCTL): Used to set the Auditing Control (QAUDCTL) system value. QAUDCTL specifies whether you want to start auditing system actions (*AUDLVL), system object activity (*OBJAUD), or both.  
• Auditing Values (QAUDLVL): Sets the Security auditing level (QAUDLVL) and Security auditing level extension (QAUDLVL2) system values. QAUDLVL and QAUDLVL2 explicitly specify the security event information that will be captured in the system’s audit journal. Security information types that can be tracked include authorization failures (*AUTFAIL), object creation events (*CREATE), object deletion events (*DELETE), program failures (*PGMFAIL), and security functions (*SECURITY). 

Step 2: Specify which users you want to collect security auditing information for 

Run the Change User Auditing (CHGUSRAUD) command for any user profiles that you want to collect security auditing information for. CHGUSRAUD turns on security auditing collection for one or more IBM i users. Shown in figure 2, CHGUSRAUD collects the following information according to these parameters: 

• User profile (USRPRF): The user profile name(s) to start collecting auditing information for.  
• Object auditing value (OBJAUD): The type of audit object information to collect for the users. You can choose to collect no information (*NONE), change all accesses for the users (*CHANGE), or change all and read accesses for the users (*ALL).  
• User action auditing (AUDLVL): Specifies the individualized security auditing level information that will be collected for the users. If the user’s AUDLVL parameter is set to *NONE, auditing will collect the security audit entries specified in the QAUDLVL and QAUDLVL2 system values. If any other user action values are listed in the parameters, those security information audit entries will be collected for the user.  

Step 3: Specify the objects that you want to collect security auditing information for  

Run the Change Object Auditing (CHGOBJAUD) command over any object that you want to collect security auditing information for. CHGOBJAUD allows admins to set up or change auditing for any specific IBM i object. Once turned on, the specific audit entries listed in the object’s Object auditing value (OBJAUD) parameter will be added to the IBM i Audit Journal (QAUDJRN). Object auditing values include: 

• *NONE – No audit entries sent to the audit journal 
• *USRPRF – Audit entries are collected for this object only for users who have had security auditing set up for them in the CHGUSRAUD command (point 2, above). 
• *CHANGE – Audit entries are collected for all change accesses for this object, for all users. 
• *ALL—Audit entries are collected for all read and change accesses for this object, for all users. 

Other sources for IBM i security and event information 

Besides the QAUDJRN security audit journal, security and auditing information is also captured in several different locations, including: 

• The IBM i history log (QHST) 
• System message queues including QSYSOPR and QSYSMSGQ 
• User message queues  
• Vendor message queues 
• Database information captured in database journals 
• Vendor security event information captured in vendor-specific journals 

Security information from these sources and more can be extracted and sent to SIEM systems. 

Further reading: Integrating IBM i Data with SIEM Solutions

Formatting IBM i info for SIEM transmission 

Security information must be formatted correctly before it can be transmitted to a SIEM system. There are three formats for transmitting SIEM information. You must determine which format you need to use before you can set up your SIEM transmissions. The most popular SIEM transmission formats are: 

• Syslog: A standard protocol for collecting, storing, and exchanging system logs and events. System messages are stored in a standardized format and can contain information from many different audit sources. 
• CEF (Common Event Format): An open log management standard that was originally developed by ArcSight but is now owned by Micro Focus. CEF is designed to provide a structured, easy-to-read format for capturing and transmitting security events.  
• LEEF (Log Extended Format): A customized event format for IBM’s Security QRADAR system. LEEF is specifically designed to work with QRADAR and many IBM i integration products can generate LEEF-formatted events.  

Transmitting IBM i information to SIEM systems 

Once you have set up IBM i audit control and journaling and identified the security event information to be transmitted, you can configure and begin sending IBM i security data to one or more SIEM systems. 

While it is possible to develop your own do-it-yourself (DIY) solution for IBM i-to-SIEM transmission, security event transmission and integration are typically managed using vendor products such as iSecurity Syslog.

Creating a custom SIEM transfer solution can be complex, expensive, and time-consuming.  A DIY solution would merely replicate the capabilities already available in third-party packages while consuming valuable application development resources. It’s more efficient to leverage a vendor-provided solution for this task. 

If you’d like to learn more about IBM i-to-SIEM integration, Contact SEA and we’ll be glad to further discuss this issue with you.