Use of Security Information and Event Managers (SIEMs) is expanding to include IBM i information, but what is appropriate to send?

Many organizations started to use a SIEM to help with PCI compliance, allowing them to aggregate information into a single source as well as to be able to better detect attacks. But as more organizations want visibility into the activity occurring across their organizations, SIEMs have become more mainstream. That causes people to wonder what should be sent from IBM i to a SIEM. And that, of course, is one of those “it depends” questions. Let’s take a look at some of the considerations you’ll want to make.

What Is Your SIEM Being Used For?

First, understand the purpose of your SIEM. Some organizations use it as the system of record for all activity, meaning that the log of the actions that have taken place on IBM i is going to be retained by the SIEM. In that case, you’ll want to send all of the entries from your audit journal to your SIEM. But before you actually do that, you’ll have to determine whether your SIEM can handle the volume of entries you’re going to send it. Many SIEMs can’t. And sometimes, while it may be able to consume the volume, it can’t store the volume or the volume is too expensive (some SIEMS charge by the volume of data processed or consumed). If your SIEM is intended to be the system of record but can’t—for whatever reason—consume all entries, you’ll need to determine which entries will satisfy audit requirements and only send those.

You’ll also need a vendor product or utility to send the information to your SIEM. Most SIEMs consume information in syslog format. That’s the log format used by most UNIX and Linux systems. But the IBM i audit journal, history log, and message queues aren’t in syslog format, so you must use something that will do the translation. While IBM has provided some DB2 table functions to convert audit journal entries into syslog format, this approach is definitely a “roll your own” solution. Vendor products (such as HelpSystems’ SIEM Agent) are usually more easily implemented and managed, including being able to filter entries prior to sending to the SIEM.

What Should You Send to Your SIEM?

If the purpose of your SIEM is to be the system of record, then you’re sending all records. If it’s not, what do you send? That, again, is one of those “it depends” questions.

If you’re sending entries to assist with compliance, list the regulations you need to be in compliance with and then read the law—yes, I said read the law. That’s really the only way you’ll know for sure whether what you’re sending will meet your compliance requirements. I also recommend you check with your internal auditor. Of course, they won’t be familiar with the specific IBM i entries (such as AF – Authority Failures or CO – Creation of Objects), but they can describe the type of activity they’re expecting to have sent to the SIEM. Let’s look at some examples. If you have to be in compliance with Sarbanes-Oxley (SOX) or the Japanese version (JSOX), the concern is about the integrity of the financial information; therefore, you may want to send the audit journal entries that would show someone has changed the database files containing the financial information. Note that if you have the ability to send database journal information to your SIEM, that entry would contain the actual details of the change rather than the audit journal entry, which provides only an indication that the file was changed but will contain no details of the actual change. If you want to look only for exceptions (my preference), I’d filter out any changes that occurred via a financial application program and send only entries that occur “outside” of the application. Another focus of some SOX auditors is the use of the job scheduler commands, so you may want to audit the use of those commands (using the Change Object Auditing (CHGOBJAUD) command) and send those entries as well.

Regulations such as the Payment Card Industry’s Data Security Standard (PCI DSS) have a much broader focus; therefore, you’ll want to send many more entries:

• AF—Entries of profiles attempting to access the file containing cardholder data as well as attempts to decrypt data without authority
• PW—Invalid signon attempts
• CP—Changes to profile entries where the password has been set and doesn’t meet the password composition rules. (This situation is possible if your system is at V7R1 or earlier or you haven’t made use of the V7R2 feature *ALLCRTCHG added to the QPWDRULES system value, which forces passwords specified when creating or changing a profile to match the password composition rules specified in QPWDRULES.)
• SV—Changes to system values to detect changes to global settings to ensure the changes are known and haven’t put the system out of compliance

If the purpose of your SIEM is to detect that the system or the organization at large is under attack or to detect misconfiguration, the list is slightly different:

• PW entries—Specifically looking for PW – U (user) entries where the user is “root” or “Admin” and the attempt originates from an external IP address. This will be an indication that your IBM i has become exposed to the Internet and a bot has attempted to gain access to your system.
• PW entries—Specifically looking for PW – P (password) entries. The SIEM would then be “tuned” to look for a widespread attack (i.e., many attempts happening within a short period of time). You may also want to look for invalid password attempts for IBM-supplied profiles, especially QSECOFR.
• IM—Intrusion detection entries. This requires that you specify *ATNEVT for QAUDLVL and go into Navigator for i to further configure this feature. Sending IM entries can help you detect malware in your organization as well as low-level TCP/IP-based attacks.
• JS—Job start entries that originate from an unknown external IP address. This, again, is going to be an indication that your system has somehow gotten exposed to the Internet. Or JS entries for QSECOFR, filtering out any known (regularly scheduled) jobs and investigating the ones you don’t recognize.
• CP—Changes to the password of QSECOFR and/or re-enabling it if you routinely keep it in a *DISABLED status.

If you’re just looking to detect inappropriate activity, you first have to determine what that means for your organization. The list will likely vary by organization, but beyond the suggestions listed previously, here are some ideas that may help you create your specific list:

• CP—Creation or changes to profiles to detect profiles created with or changed to have *ALLOBJ and/or *SECADM specify authorities or added to a group with those special authorities
• AF—Authority failures. If you’ve implemented a “deny by default” posture for your database files, send authority failures of anyone attempting to access one of those files.
• AF entries for users attempting to run commands that have been secured
• SV—System value changes. Again, to ensure the changes are known and are approved.
• CO—Creation of objects. Look for programs created by profiles other than the change management profile (which will show that someone has bypassed the normal change management process).

What About Other Logs?

My focus so far has been on sending information from the audit journal to your SIEM, but what about other logs, such as the history log (QHST) or logs from exit-point software? Unless your SIEM is a system of record, I don’t see much point in sending QHST records. All security-relevant information is found in the audit journal, and I’d prefer not to flood a SIEM with redundant information.

Sending information from your exit-point software is something I’d recommend because that will provide more details than the corresponding audit journal entry. Send:

• Failed access attempts to detect inappropriate activity
• Uploads via or FTP puts to log changes to financial information
• All accesses (both successful and unsuccessful) from unknown external IP addresses to detect that the system has become exposed to the Internet

I alluded to sending database journal entries to your SIEM earlier. Sending these entries may help with PCI compliance if you send entries of the users that decrypt PCI data, for example. SIEMs can also assist with privacy law compliance if you have enabled database reads.

Summary

Organizations that use IBM i to run their business but don’t send the information regarding activity on the system to their SIEM is like someone doing a jigsaw puzzle and leaving out the major scene. Sending only network or perimeter activity allows you to put together the puzzle border, but, without IBM i sending its information, you have a large, gaping hole in your picture. If your organization uses a SIEM, make sure your IBM i system is participating so the picture of the activity occurring throughout the organization is complete.