IBM i natively captures system and security information needed for auditing and compliance. However, it can be difficult to use native information to detect system problems and produce auditing and compliance reports. For all its capabilities, IBM i auditing tools are merely starter mechanisms that gather security information but don’t provide all the monitoring, analysis, and reporting tools most organizations need to make sense of its security data.
The tools you need
Most shops would like to use their IBM i data inside Security Information and Event Management (SIEM) software that can perform the following functions on that data:
- 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 your IBM i system and your network
An SIEM detects and documents system and security issues for IT operations, management, auditors, and regulatory agencies.
But what’s the right way to use IBM i data inside SIEM software and can you use your IBM i as an SIEM software server? To answer those questions, here’s some basic information on using IBM i for SIEM processing, and some recommendations on using your IBM i for SIEM server processing.
Where does IBM i system and security event information come from?
For SIEM purposes, 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 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 are difficult to analyze and don’t have easy to use analysis tools
- 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 reporting (as shown below).
The ten most critical IBM i information sources to monitor and report on
1. The Security Audit Journal (QAUDJRN)
2. The History log (QHST)
3. IBM i message queues, such as QSYSOPR and QSYSMSG
4. Database journals that store the results of database operations, as well as database field level changes and before and after images of database records
5. User authority changes to user profiles, system objects, and files
6. Authority changes that are stored in the audit journal or in vendor-provided software, such as SEA Software’s Authority on Demand package
7. Virus detection notices issued, and actions taken from IBM i anti-virus software scanning the Integrated File System (IFS), such as iSecurity Anti-Virus
8. Application changes that are tracked through vendor software, such as SEA’s iSecurity AP-Journal Application Security & Business Analysis solution
9. The output of security exit programs that provide system and security information
10. IBM i Firewall system events and messages
Three ways to perform SIEM for IBM i shops. As far as performing SIEM analysis, IBM i QAUDJRN can only do so much regarding auditing and compliance. So, what’s the best way to perform SIEM analysis on IBM i data?
There are generally three ways you can perform SIEM analysis on IBM i data.
The basic architecture of an IBM i provides you with the information in the Security Audit Journal, as well as the other data sources listed in figure 1. Using that information, you can set up SIEM and SIEM-like analysis over your IBM i data in the following ways.
- If you have an organization-wide syslog server running SIEM software, use a third-party IBM i SIEM integration package such as iSecurity Syslog to transfer i security event information to enterprise SIEM servers via syslog. Enterprise SIEM servers collect syslog information from many different servers running different operating systems (including IBM i, Windows, Linux, and UNIX servers).
For IBM i servers, you can generally transfer the information in QAUDJRN through syslog but not the other information sources shown in figure 1. Integrating IBM i data into your corporate solution helps provide an organizational-wide view of your data. SIEM packages from vendors such as IBM, Hewlett Packard, or Splunk collate syslog information from many different systems, providing your corporate IT with the tools they need to monitor overall network behavior and react and report on it.
If an enterprise SIEM package is present, you may be required to import your IBM i syslog data to the server. The problem with using enterprise SIEM for IBM i analysis is that it provides a corporate view of your system and security event data, that is usually monitored by the corporate IT team, not IBM i local Subject Matter Experts (SMEs). Enterprise SIEM isn’t a local IBM i tool. When you aggregate information from different systems, details from any one specific system such as an IBM i, tend to get lost. Local IBM i SMEs need to know the details of IBM i SIEM events just as much or more often than the corporate team.
So, 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 and others watching and auditing their systems.
- Do it Yourself (DIY): Create your own SIEM system using programming resources and native IBM i system and security information – Mine the data collected in your QAUDJRN receivers and other IBM i sources to create your own custom system and security event monitoring, analysis, and reporting system.
Creating your own IBM i-based system allows you to massage the data exactly the way you want it and produce custom SIEM monitoring, analysis, and documentation keyed to your exact specifications. However, maintaining an IBM i SIEM system can be time-consuming and use expensive programmer time that can be better deployed creating revenue-generating apps.
The DIY solution is best for organizations that lack resources for purchasing third-party IBM i auditing software to automate your system security auditing process. DIY programming will produce a custom system using IBM i system and security event data, but it will co-opt rare and expensive programming resources while doing the job.
- IBM auditing software: Use a third-party IBM i auditing package, such as SEA’s iSecurity Audit for IBM i system and security monitoring, analysis, and reporting. IBM i security auditing packages provide real-time monitoring of security events, the ability to alert IT responders when an event occurs (or to kick off a corrective action in response to the event), easy to use graphical interfaces (as opposed to IBM’s green screen commands for dealing with QAUDJRN data), and more than 100 built-in reports for compliance and monitoring. These packages provide many capabilities that are like the capabilities provided in enterprise SIEM software. They also provide access to more of the system and security event sources listed in figure 1.
IBM auditing software complements the system and security information provided by IBM i. It also provides an IBM i-specific solution where management, auditors, and IBM local SMEs can dig into what’s happening with their IBM i systems at the local level.
A game plan for SIEM analysis for IBM i data
Given your choices, here is our game plan and recommendations for using IBM i system and security event data for SIEM forensic and predictive analysis.
- Recommendation #1: If your company is running an enterprise syslog and SIEM server residing outside of your IBM i, use a package like iSecurity Syslog to export your syslog data onto that server for monitoring, analysis, and reporting. Exporting IBM i syslog data is generally a requirement in organizations where enterprise SIEM exists.
- Recommendation #2: Use a third-party IBM i system and security auditing software such as SEA’s iSecurity Audit to analyze, monitor, and report on system and security event information. Don’t just rely on your enterprise SIEM solution, if you have one.
An IBM i-based package comes pre-loaded with IBM i-based monitoring, alerting, and reporting capabilities that you won’t be able to get out of an enterprise SIEM package. These packages deal with all your IBM i system and security event data, not just the subset that’s important to an enterprise SIEM server.
The benefits for your IBM i server monitoring, analysis, and reporting are so great that we recommend using one of these packages on your IBM i partition, regardless of whether your organization has an enterprise SIEM server or not.
- Recommendation #3: Don’t produce DIY IBM i-based processing unless you absolutely need to. The time, effort, and cost to provide forensic and predictive analysis capabilities using DIY native programming is difficult to accomplish and it 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.
