For many organizations, IBM i security data must be exported into enterprise-wide Security Information and Event Management (SIEM) solutions. SIEM aggregates enterprise-wide security event data from applications, network devices, servers, and enterprise cloud environments. Enterprise security teams use SIEM data to produce a single view of their security posture that can be used for:
- Forensic analysis to identify and report on system and security issues that have already occurred
- Predictive analysis to monitor, alert, and report on developing issues and trends across the enterprise
SIEMs help organizations recognize and address potential security threats and vulnerabilities before they disrupt business operations. They track and analyze security data using user, behavioral, and security analytics along with other advanced capabilities such as AI and machine learning.
Here’s some basic information and considerations for exporting IBM i data to SIEM solutions.
Ten critical IBM i security information sources for SIEM analysis
For SIEM processing, you want to gather IBM i information detailing system and security events from all available sources. When most people think of IBM i security auditing, they only think of the system’s Security Audit Journal function (QAUDJRN).
While QAUDJRN journal receivers do a great job recording security events on your system, there are some limitations in working with QAUDJRN information, specifically:
- QAUDJRN journal entries can be difficult to analyze.
- QAUDJRN doesn’t collect everything you need to secure your system
- QAUDJRN journal receivers take up too much disk space
Click here for more information on what QAUDJRN is and what it can and can’t do. In addition to QAUDJRN, there are at least nine other critical IBM i information sources that should be examined for SIEM monitoring and analysis.
The ten most critical IBM i security information sources to monitor and report on are:
1. IBM i Security Audit Journal (QAUDJRN)
2. IBM i History log (QHST)
3. IBM i message queues, such as QSYSOPR and QSYSMSG along with user message queues
4. User authority changes to user profiles, system objects, and files
5. Authority changes that are stored in the audit journal or in vendor-provided software, such as iSecurity Authority on Demand
6. Virus and ransomware detection notifications, and actions taken using IBM i anti-virus and anti-ransomware solutions such as iSecurity Antivirus and iSecurity Anti-Ransomware
7. User login history including login failures, multi-factor authentication (MFA) attempts, and Self-Service Password Reset (SSPR) history from vendor solutions such as iSecurity Multi Factor Authentication and iSecurity Password Reset
8. Database journals that store the results of database operations
9. Application and database changes that are tracked through vendor software, such as SEA’s iSecurity AP-Journal Application Security & Business Analysis solution
10. Output from IBM i security exit point programs, using do-it-yourself exit programs or from IBM i exit point monitoring solutions, such as iSecurity Firewall.
Using IBM i data for SIEM aggregation and IBM i security analysis
There are generally three ways you can aggregate IBM i data into an enterprise-wide SIEM solution or provide IBM i-based security analysis. Using information in QAUDJRN as well as the other data sources listed above, you can set up IBM i-to-SIEM transmission capabilities and IBM i security analysis in the following ways.
1. Use third-party solutions to export IBM i security data to an SIEM system
Third-party solutions such as iSecurity Syslog allow you to transmit IBM i security data to one-or-more SIEM systems. IBM i security information can be transmitted in standard Syslog formats including LEEF and CEF or in a free format. Security information is normally exported in near real-time.
There are several other third-party software packages that can transmit the critical IBM i security information listed above to SIEM systems. Syslog information for items such as 5250 login failures, virus and ransomware notifications, MFA login failures, password resets, authority changes, and more can be automatically transferred to enterprise SIEM systems for analysis. Many vendors provide IBM i security solutions, such as the iSecurity suite offered through SEA, that transmits relevant security event data to SIEM solutions.
2. Use third-party IBM i system and security analysis software to analyze, monitor, and report on system and security event information.
The problem with using enterprise SIEM for IBM i analysis is that it provides an organizational view of system and security event data that is usually monitored by the corporate IT team, not IBM i local Subject Matter Experts (SMEs).
There are several third-party IBM i security analysis packages such as iSecurity Audit that come pre-loaded with IBM i-based security monitoring, alerting, and reporting capabilities.
While it’s important to export IBM i Syslog data to a corporate Syslog server running SIEM software, it’s also important to make sure IBM i system and security information is available for local IBM i SMEs.
3. Using DIY IBM i-based processing for security analysis.
It can be difficult, costly, and time-consuming to program your own SIEM transfer and IBM i security analysis solutions. The time, effort, and cost to provide forensic and predictive analysis capabilities using DIY native programming is difficult to accomplish.
DIY solutions will divert programming resources away from more valuable business- and revenue-oriented projects. Use a third-party IBM i system and security auditing package, if possible, before resorting to programming your own solutions. Using a DIY solution will only reinvent the capabilities present in third-party packages.
Find out more about IBM i SIEM integration
There are several vendors who provide IBM i SIEM aggregation and security analysis solutions. If you’d like to learn more about this topic, contact us at SEA and we’ll be glad to further discuss this issue with you.
