Townsend Security Data Privacy Blog

IBM i customers should be aware of a new security issue with IBM i Access for Windows version 7.1. This issue will affect a large number of IBM i users as Access for Windows is very commonly used by IBM i customers. US-CERT/NIST in the NVD database indicates this issue has a base score of 7.2 and an impact score of 10. This means that IBM i customers should give this issue attention as soon as possible.

• The vulnerability ID is CVE-2015-2023 and you can find the details here
• IBM provides a description of this issue on their website here
• A fix from IBM is available with Service Pack SI57907 and can be found here

If you are an IBM security administrator I recommend that you sign up for notifications on the NVD website. While the volume of IBM i issues is relatively small, they do occur from time to time and some of them are severe enough to warrant quick action. You can also review IBM i security notifications on the IBM i website here (but be sure to monitor the NVD site too).

Patrick

Data security doesn’t need to be a challenge! 

Whether your data is stored within your database files or transmitted to your trading partners, using the right tools can mean the difference between meeting compliance and security best practices or suffering a data breach. 

Townsend Security is well known for providing security solutions for a wide variety of platforms (IBM i (AS400, iSeries), IBM mainframe, VMware, Windows, Linux). Recently, our founder and CEO produced an excellent webinar on “Securing Your IBM i Using the Right Tools”. Many of our IBM i customers are under multiple compliance requirements including PCI, HIPAA, SOX, GLBA, and others which require securing data-at-rest and data-in-motion, real-time security event logging, file integrity monitoring, and two-factor authentication. The webinar covers encryption and key management as well as a number of our other auxiliary products specifically for the IBM i (AS400, iSeries) platform.

There were a number of excellent questions asked after the presentation, and the following is a brief recap of that Q&A session with links to additional information:

Q:  Can I use FieldProc to protect multiple fields in a file?

A:  The short answer is yes, encrypting multiple fields is a fully supported capability. FieldProc does allow, from both DB2 and from our solution, protecting multiple columns or fields in a DB2 file. You can define multiple fields and then enable FieldProc with one command on all those fields within our solution. People often ask if indexes can also be encrypted and yes, that is fully supported as well. There are a few limitations in legacy RPG applications, while with a native SQL application there are no limitations.

To learn more about Field Procedures on the IBM i, check out this blog:  5 Common FAQs About IBM i Encryption Using FIELDPROC 

Q: Can’t I just transfer my file from IBM i to Windows and then PGP encrypt it there?

A:  This is a great compliance question and comes up often with QSA Auditors. Yes, of course you can move a file from one machine to another using operations navigator. The problem is that it exposes data in the clear during the movement, either across the network if it is an unsecured connection or when the data lands on the other side of the transfer. Any of these exposures will likely result in an audit failure.

Good security practice, regardless of the platforms involved is:

•   Encrypt at the Source
•   Decrypt at the Destination

Make sure to securely move it in encrypted form and don’t let it get loose anywhere in between!

Learn more about the core components of a total encryption strategy in this blog: Secure Managed File Transfer and PGP Encryption

Q: How does key management work with older back-up copies of data that was secured with earlier keys?

A:  Any Enterprise key management solution should maintain encryption keys under policy for as long as they are needed. As you generate new keys, the older keys are retained and made available for decryption purposes, until you retire those keys. Our solution will maintain multiple versions, and doesn’t have a limit on how many keys or generations you can have of master or key encryption keys. If you have a loss or need to delete data that is out of your control, you can then delete the key. 

For more information on the full life cycle of keys, check out this blog: Why Key Management is So Critical in the Life Cycle of an Encryption Key

Q:  Your two-factor authentication product is supported in which countries?

A:  Since our 2FA solution is through TeleSign, a global company, it has a broad presence in more than 200 countries around the world and in 87 languages.  By leveraging an individual's mobile phone, a reliable means of authentication has become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone. 

This blog will outline Making a Case for Two Factor Authentication: Taking Security Beyond Usernames and Passwords

Q: How does LogAgent send security information to my SIEM or log collection server? Is information batched or real time?

The Townsend Security solution for system logging and SIEM integration is Alliance LogAgent. It works with a large number of SIEM solutions including IBM QRadar, LogRhythm, Dell SecureWorks, NTT/Solutionary, Splunk, Alert Logic, HP ArcSight, McAfee, and many others. It brings the IBM i (iSeries, AS/400) into an active monitoring strategy that is so important to good security. Since real-time security event collection is crucial to active monitoring, customers often ask us how Alliance LogAgent achieves this? Let’s take a deeper dive into how this is accomplished.

The IBM security audit journal is named QAUDJRN and it collects most of the critical security events on the IBM i platform. Unlike many IBM i system logging tools, Alliance LogAgent collects events from this journal in real time. Using IBM provided application program interfaces (APIs), events are collected from the security journal as they are written to the journal by the operating system. There is no batch-oriented extraction of events once or twice a day, and no batch transfer using unsecure FTP. Alliance LogAgent is able to grab the events as they become available. This provides the real-time view of security events that is so critical to active monitoring, correlation and alerting by SIEM solutions.

Once the event is extracted it has to be converted into a usable format. The security event information in QAUDJRN is in an internal IBM format and is stored in the EBCDIC character set which is largely unusable by SIEM solutions. Alliance LogAgent immediately converts the important information into a system log format (syslog, Common Event Format, or Log Event Extended Format), and translates it to the ASCII character set that is used by SIEM solutions. To make the information usable to SIEM solutions the event information is normalized into fields that are easy for SIEM solutions to understand. These normalized fields are in the keyword=value format (more on this is another blog). The formatting also happens in real time so that there are no delays imposed by the conversion process.

Once the security event is extracted and converted to a usable format, it must be communicated to the SIEM solution for processing. Alliance LogAgent implements a set of syslog communications modules that immediately send the security event to the SIEM server. Alliance LogAgent supports three different syslog communications options:

• Internet UDP protocol
• Internet TCP protocol
• Internet TLS encrypted TCP protocol

By default these communications programs send security events to the standard syslog port of 514 on the SIEM server, but you can easily change the port number if needed. Not every SIEM solution supports encrypted transfer of log events, but Alliance LogAgent gives you this option along with non-encrypted options for log transfer.

Alliance LogAgent runs in a background batch process at a low priority so that it does not disrupt normal interactive response times. Using the optimized processes of Alliance LogAgent the IBM i customer achieves real-time processing of security events and gets the best results and maximum benefit from their SIEM solution. Security issues are identified immediately and the IBM i system administrator can react swiftly to potential security breaches.

Additionally, Alliance LogAgent takes a similar approach to monitoring other security event sources on the IBM i platform. The QHST system message facility is also monitored in near real-time as messages are logged to the QHST files. For messages sent to the system operator message queue QSYSOPR or QSYSMSG, Alliance LogAgent also monitors these message queues for events and sends the information to the SIEM server in real time. The same is also true of the Alliance LogAgent exit point monitoring applications.

Alliance LogAgent was built from the ground up to accommodate real-time security event collection and transmission to your SIEM solution. It is fast, efficient, and non-intrusive. Exactly what you need to collect and monitor security information on your IBM i platform.

When IBM i users deploy Alliance LogAgent to integrate their IBM i servers with their log collection and SIEM solutions they naturally ask about the storage requirements. This is probably because some IBM i logging solutions perform batch extractions of the security events and then use FTP or other file transfer mechanisms to transfer the data. And there can be a LOT of security event information to transfer thus expanding the need for storage on the IBM i platform.

Alliance LogAgent does not use an periodic batch extraction architecture for its implementation. Instead, Alliance LogAgent extracts security event information from the security audit journal QAUDJRN in real time and pushes the information directly to the log collection server or SIEM solution directly. So the answer to the storage question is easy:

Zero. Zilch. Zed. Nada.

There is no intermediate or temporary storage utilization when you deploy Alliance LogAgent. All events are extracted, converted to a standard system logging format, and transmitted directly without the need for intermediate files. This is true for all of the security log sources on the IBM i including the security audit journal QAUDJRN, the system message files QHST, the exit points, the message queues, and the Linux-style message files in the IFS file system.

Of course, the application itself including the programs and configuration files require some storage on the IBM server. A typical installation of Alliance LogAgent will require about 115 MB of disk storage. But this storage will not grow over time due to historical information or temporary storage.

That is good news for IBM i customers who are trying to control costs.

Securing our systems is a demanding task and we don’t need the added worry of additional system resource costs!

IBM introduced the DB2 Field Procedures (FieldProc) column level encryption interface in V7R1 of the operating system. It has been a great way for IBM i (iSeries, AS/400) customers to protect sensitive data in their DB2 for i files and tables, but customers often have questions about how this new capability works. One of the most common questions is “Can I encrypt index fields and will they work correctly?”

The answer to the first part of the question is YES you can encrypt index fields, and the answer to the second part of the question is THAT DEPENDS. Let’s take a deeper look at encrypted indexes with FieldProc.

First, let’s look at DB2 FieldProc strictly from a SQL point of view. Remember that SQL is IBM’s preferred interface to the DB2 relational database. So let’s start there:

The first thing to understand is that FieldProc is fundamentally a SQL construct. That is, it is designed for and implemented as a SQL facility. You can specify a FieldProc program on the SQL CREATE TABLE or ALTER TABLE commands, but you can’t specify FieldProc on traditional DDS source descriptions. FieldProc works great on index fields in your SQL applications! Your SQL statements will work just as you would hope and you will have a great new facility for implementing automatic encryption. With very few limitations you will find that encrypted indexes work without any issues for your SQL applications. I’ve rarely found a customer who was unhappy with IBM’s implementation of FieldProc in native SQL applications. This includes SQLRPG applications that use native SQL for the database interface.

But, of course, most IBM i customers are running a lot of legacy RPG or COBOL applications that do not use SQL. And this is where there are some significant restrictions on encrypted indexes.

First, you CAN use FieldProc on traditional database files created with DDS. It is not necessary to convert the database files to SQL in order to use FieldProc. Of course, FieldProc application support is installed using SQL statements, but they will work on traditional DDS created files with some minor limitations. So this part is not complicated.

Next, you CAN encrypt indexes that are created with DDS. However, you do have some significant limitations when using FieldProc with DDS files. For example, some join logical files that join on encrypted index fields will not work. You simply won’t be able to create join logical files that link using fields encrypted under FieldProc.

A more fundamental problem is that legacy RPG and COBOL applications will not work correctly with most encrypted indexes. Since the legacy file interface is not SQL, the legacy applications will not work as expected in many cases. For example, it is very common to use the Set Lower Limits (SETLL) command with the Read (READ) command to read a range of values in a table. In these legacy applications the SETLL value will be converted to the encrypted value by FieldProc, and then the next record will be read using the encrypted key value. But encrypted values will not be in the same order as the original plaintext values. This will lead to empty subfiles and empty or incorrect information on reports.

For many IBM i customers the limitations on encrypted indexes are not a big problem and they live with them. For many others encrypted indexes with legacy RPG applications is a significant problem that will make the use of FieldProc impossible.

Is there a solution for this problem? Well, of course you can convert all of your legacy databases and applications to SQL databases and SQL RPG applications, or even to native SQL applications. But this represents a major investment by many customers. But there is an alternative provided in the Open Access for RPG (OAR) implementation by IBM.

The Open Access for RPG implementation allows you to define a handler for file operations using one F specification in your RPG program. With this implementation the legacy file operations are handled by your new handler application. And that can be a set of SQL functions! This means that a legacy RPG program can become enabled for true SQL operations with a simple change and re-compile of the application. Of course, you must have the SQL handler functions ready to take over the file operations. I won’t go into creating SQL handlers in this blog, but be aware that creating SQL handlers is not for the faint of heart. You need to have extensive experience with SQL and understand the OAR architecture. If you’ve not done this before the IBM Lab Services team can provide assistance.

In summary, FieldProc is a great new facility and it is already helping a lot of IBM i DB2 customers to protect data with strong encryption. It works great with native SQL applications, but you need to be aware of some limitations when used with legacy RPG and COBOL applications.

Our Alliance AES/400 solution provides everything you need to implement FieldProc. 

Each new release of the IBM i (iSeries, AS/400) operating system brings the likelihood that IBM has added new security events to the security audit journal QAUDJRN. Version 7 Release 2 (V7R2) of the IBM i operating system was no different. There are four new security event types collected in the security audit journal. Let’s take a look at these new events:

PTF Operations (event type PF)
This new event type records significant Program Temporary Fix (PTF) operations. This includes operations like loading a PTF, applying a PTF, removing a PTF, PTF superseded, and other PTF operations. It also includes operations on licensed products. Saving, restoring, deleting, and installing licensed programs are included in this group. Because of the potential impact on on-going operations of your IBM i server by PTF activity you should monitor these types of events and forward them to your SIEM solution.

PTF Object Change (event type PU)
This event records changes to objects that occur due to PTF operations. These events are created when PTFs are applied or removed, and the event will tell you if the PTF object is new or changed. PTF objects can be database files, programs, IFS files and many other types of objects. Because of the potential impact on on-going operations of your IBM i server when PTFs are applied or removed you should monitor these types of events and forward them to your SIEM solution.

Row and Column Access Control (event type AX)
Row and Column Access Controls are new in V7R2 and provide significant new security features for IBM DB2 for IBM i. Users can now control access to DB2 information at both a row and column level. This new AX event records changes to column masks and row permissions including changes, additions, and removal of RCAC controls. Because row and column access controls are a part of your normal security strategy, you should monitor these changes with your SIEM solution.

Query Manager Profile Changes (event type X2)
This new security audit journal event type records changes to Query Manager profiles. The implementation of the event represents a radical departure from the decades-long definition of security audit journal types as it does not have a normal description file in library QSYS, and it does not have the typical format for security audit journal entries. You must use SQL and special steps to instantiate the information and monitor it correctly. Query manager profile changes can affect user rights to sensitive data and so should be monitored by your SIEM solution.

These are the new IBM security event types that were added to the QAUDJRN security journal in IBM i V7R2. You will want to be sure your IBM i system logging solution addresses these events and that your SIEM solution is monitoring them appropriately. Alliance LogAgent supports these events in the latest version which you can download through the normal update process.

IBM introduced Field Procedures (FIELDPROC, or FieldProc) on the IBM i (AS/400, iSeries) platform in V7R1 of the operating system. It is a strategically important implementation and is a permanent part of the DB2 for IBM i database going forward. The FieldProc implementation is an event-driven exit point directly in the DB2 database and is invoked for most of the standard CRUD operations (but not delete). While the FieldProc implementation can be used for many things, IBM i customers primarily use it as a mechanism to automatically encrypt and decrypt data at the column level. It is now a widely adopted and deployed method for data protection on the IBM i and IBM System z Mainframe editions of the DB2 database.

While the benefits of the data at rest protection offered by FieldProc encryption is clear, our customers often ask us if FieldProc encryption will also protect their backups. It is a good question because there are times when making a copy of a file with FieldProc encryption causes the data to be decrypted by the copy. So does DB2 data remain protected with normal IBM i backups?

Fortunately, the answer is Yes - your backups will be protected with FieldProc encryption when you use any of the normal SAVE commands on the IBM i platform including commands like Save Object (SAVOBJ), Save Library (SAVLIB), Save Save File Data (SAVSAVFDTA), Save Changed Objects (SAVCHGOBJ), and the various IBM Backup Recovery and Media Services (BRMS) commands.

While it is rare, I have seen some uses of the Copy File (CPYF) command to copy data to backup tapes or files. In this case your data will be automatically decrypted during the copy operation and will NOT be protected in the backup image. To save data in encrypted format ALWAYS use one of the IBM save commands, the IBM BRMS application, or any third party backup solution that uses the IBM SAVE commands.

Another related question that we often get is how can I verify that the data is actually encrypted on the backup image? This is a good question because security auditors often want an independent verification of the encrypted status of the data. One way to verify the encrypted status of the data is to use the IBM Dump Tape (DMPTAP) command to dump the contents of the tape after a save operation. Try saving the file without FieldProc encryption, then save it with FieldProc encryption enabled. The Dump Tape command will show the contents of the data and you can easily see unencrypted values or encrypted values in the dump reports. Note that you may need to turn off save compression in order to view the data with this method.

Another way to verify the encrypted status of data is to use the same procedure, but save the file or table to a save file (SAVF). You can then use FTP to transfer the file to your PC in binary mode and use a file viewer to review the contents. Unfortunately, you can’t use the Display Physical File Member (DSPPFM) command as it does not display save files. On your PC you might like to use a utility like UltraEdit as it can view data in the EBCDIC character format. You can easily determine that your data is encrypted in the save file.

Either of these techniques can be used to verify the encrypted status of your files when saved with FieldProc active. You can rest assured that your data is protected on backup tapes and images and that the encryption key is not stored with the data!

Townsend Security provides a FieldProc implementation in our Alliance AES/400 solution. It integrates seamlessly with our Alliance Key Manager solution which manages encryption keys through the entire key life cycle. The Alliance AES/400 solution is the only IBM i FieldProc encryption solution that is NIST validated for the AES encryption library, and which combines this level of encryption with a NIST validated encryption key management solution, giving you provable compliance with industry standards.

Backup data protection is a great added benefit to FieldProc encryption on the IBM i platform. I hope this discussion helps resolve any question you have about FieldProc encryption and backup protection.

Patrick

IBM i (iSeries, AS/400) users are often confused about user names in the IBM security audit journal QAUDJRN, and how they are reported to their log collection server or SIEM solution by Alliance LogAgent. To understand this it is important to know that every batch or interactive job on the IBM i platform actually has two user names: a job user name and a current user name (sometimes called the effective user). These two user names are often the same, but there are many times when they are different. Let’s take a look at some examples.

The IBM FTP server runs under the IBM user name QTCP as it waits for a connection from an FTP client. The user name QTCP is provided by IBM and is used for a number of network services. When an FTP client connects to the IBM FTP server and logs in, the job user remains QTCP but the current user is now the name of the actual user who logged in to the FTP session. If a user named BILL logged in you would then have these two user names:

Job user name: QTCP
Current user name: BILL

Both of these user names are recorded in the IBM security audit journal. You can see this information when you use the Display Audit Journal Entries command DSPAUDJRNE. Try selecting the job start event “JS” and you will see this in the output:

But there is a big difference in the capabilities and security risk between these two users. The user QTCP is an IBM supplied user with no ability to log into the system, and the user BILL is an actual user whose authorities and capabilities are in effect. If BILL is a highly privileged user he will have the ability to do a lot of damage and may even be able to retrieve any database file on the system.

Monitoring both user names in your SIEM solution and retaining the history of the activity on these two users is critical for your security strategy on the IBM i.

In Alliance LogAgent we collect and report both of these names when sending information to your log collection server and SIEM solution in the Syslog format. When you look at these events you will see something like this:

user_name=”QTCP”
effective_user=”BILL”

If you are using the Common Event Format (CEF) that is preferred by HP ArcSight’s SIEM solution, you will see information like this:

suser=QTCP
eff_user=BILL

If you are using the new IBM QRadar log event extended format (LEEF), Alliance LogAgent will send the information like this:

user=QTCP
usrName=BILL

The “usrName” keyword is predefined to IBM QRadar and is the user credential that is monitored for anomalies and suspicious behavior. So it is important that the effective user be supplied in this case.

Both user names contain important security information, and both should be reported to your SIEM solution for active monitoring. Alliance LogAgent always sends both user names to make your monitoring and security strategy more effective.

Our Alliance LogAgent customers often ask us which IBM i security events we transmit from the IBM security audit journal QAUDJRN to their log collection server or SIEM solution. There are several factors that affect which security events get collected by the IBM i operating system, and even which events are collected by Alliance LogAgent for transmission to your SIEM server. Let’s take a look at these:

When your new IBM i server is delivered it is not configured to collect any security events. You must create the QAUDJRN journal and the journal receiver as a first step. Then you must change some system values in order to activate security event collection. This is the first step in answering the question about which security events Alliance LogAgent transmits. It can only transmit the events you enable and you set these with the system values.

The first system value you must set is QAUDCTL. When you receive your new IBM i platform this system value is set to *NONE meaning that no security events are collected. You should probably change this to:

*AUDLVL
*OBJAUD
*NOQTEMP

You now need to set the QAUDLVL and QAUDLVL2 system values to specify the type of events you want to collect. On a new IBM i server these system values are blank. IBM makes it easy to collect the security events through a special system value named *SECURITY. If you set the QAUDLVL system value to *SECURITY you will collect only the security-related events on the IBM platform. Of course, there are other events that you might like to collect. Press the F1 help key to view a complete list of events. If they won’t all fit in the QAUDLVL system value just add them to the QAUDLVL2 system value and specify *AUDLVL2 in the list.

You can now use the Change User Audit (CHGUSRAUD) command to audit users. I would suggest you turn on full user auditing for any security administrator, any user with All Object (*ALLOBJ) authority, and any user with audit (*AUDIT) authority.

You can also turn on object level logging with the Change Object Auditing (CHGOBJAUD) command. Be sure to specify all libraries and files that contains sensitive data. Do the same thing for IFS directories using the Change Audit (CHGAUD) command.

You’ve completed the first step in configuring security event collection. Alliance LogAgent can only report what you configure the system to collect and this first step defines those events.

Alliance LogAgent can also be configured to filter security events. The default is to report all of the events collected in the system audit journal QAUDJRN, but you can narrow these to a defined set of events. In the Alliance LogAgent configuration menu you will see an option to Work With Security Types. This will list all of the event types collected in the QAUDJRN journal. You can use function key F13 to set group patterns, or change each event. The F13 option is nice because it has a *SECURITY option that will let you set all security events on for reporting. Or, you can edit an individual security event to change its reporting status. For example, to turn off reporting of Spool File actions, edit the SF event and change the reporting option to No:

Send to log server . . . . . . . 2     1=Yes, 2=No

When you make this change Alliance LogAgent will no longer send spool file action information to your SIEM solution.

It is not wise to turn off the reporting of security events in Alliance LogAgent! You will always want to collect and report these events.

Setting the system values and configuring Alliance LogAgent security events are the primary ways you determine which events are transmitted to your log collection server. There are additional filtering options in Alliance LogAgent to include or exclude objects, IFS files and libraries and these can help you further refine the events that are transmitted.

Our customers often ask how they can manage the amount of data that Alliance LogAgent sends to their SIEM active monitoring solution. It’s an important question because most SIEM solutions license their software based on the number of Events Per Second (EPS) or by the number Gigabytes per day (GBD). So managing the volume of data has an important cost benefit as long as you don’t undermine the effectiveness of the security monitoring!

There are some things Alliance LogAgent inherently does to help with the volume of data, and there are some things you can do, too. Let’s look at both of these areas.

First Alliance LogAgent reduces the amount of data sent from the IBM security audit journal QAUDJRN by extracting only the information that has relevance to security from each journal entry. Each journal entry has a 610-byte header and most of the information in the header has no security relevance. Then the actual event information that follows can can be several hundreds of bytes in length. The average journal entry is about 1,500 bytes in length. Alliance LogAgent extracts and formats the important information into one of the Syslog formats. The result is an event with an average size of 380 bytes.

That is a 75% reduction in the amount of data sent to your SIEM solution!

Alliance LogAgent also gives you the ability to meter the number of transactions per second that you are sending. The IBM i server can generate a large number of events and throttling the transactions with this configuration option can help you reduce and control SIEM costs. Additionally, it can also help minimize the impact on your network capacity. This is a great option if your SIEM solution is licensed based on the number of Events Per Second (EPS).

In the second category are things you can do to minimize the number of events that are processed using various Alliance LogAgent configuration settings. Let’s take them one at a time:

Selectively send journal entry types
The IBM security audit journal QAUDJRN collects security events and general system information. Some of the general system information may have no security relevance and Alliance LogAgent allows you to suppress the transmission of these events. For example, the security audit journal may have information about printed reports (journal entry type SF for spool files) that have been produced on your system. If this information is not needed for security monitoring, you can turn off the event reporting in Alliance LogAgent. From the configuration menu take the option to Work With Security Types. You can can change the option to Send To Log Server to No:

Hint: You can also use function key F13 to select all IBM Security (*SECURITY) level events for reporting, and turn all other events off.

Filter library objects
You may have many libraries on your IBM i server that are not used for production data or which do not contain any information that has security relevance. From the configuration menu you can create an object exclusion list to exclude individual libraries, or you can exclude all libraries and objects. If you take the latter approach be sure to define libraries in the inclusion list that you want to monitor and report. By excluding non-relevant libraries and objects you can minimize the number of events that are transmitted.

Filter IFS objects
Like library exclusion and inclusion you can define IFS file system filters. From the configuration menu you will see options for IFS exclusion and inclusion rules. You can even exclude all IFS directories (exclude the “/” root directory) and then add in the IFS directories you want to include. IFS filtering lets you define individual files or entire directories and subdirectories. The “/tmp” directory is a working directory and you may wish to exclude events from that directory if there are no relevant security-related events there.

Filter users
Alliance LogAgent also gives you the ability to filter certain users from reporting, too. You should use caution when implementing this type of filtering, and never filter highly privileged users. Alliance LogAgent provides a list of IBM user profiles that you might consider for exclusion, but you should review these with your IBM i security administrator before filtering these users. You can also add your own users to this list.

Filter QHST messages
The QHST message files contain important logon and logoff event information along with other messages that may not be as important. Alliance LogAgent lets you filter QHST messages to only include logon and logoff events if you wish.

Filter system values
Some of the IBM i system values have a low security value and can be suppressed by Alliance LogAgent. Alliance LogAgent provides a list of system values for your consideration and you can disable reporting changes if you decide they do not have security relevance. You can also add your own system values to the filter list.

These data compression, metering, and filtering options give you a lot of control over the amount of information that Alliance LogAgent sends to your log collection server and SIEM solution. These can help you control costs and minimize the impact on your network. The original information remains in your IBM security audit journal and system history messages file if needed for research or forensics.