+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

The Future of Active Security Monitoring on the IBM i

Posted by Luke Probasco on Jan 24, 2017 8:19:21 AM

Active monitoring is one of the most effective security controls an enterprise can deploy. In fact, a large majority of security breaches occur on systems that have been compromised days, weeks, or even months before sensitive data is lost. A recent Verizon Data Breach Investigations Report indicates that a full 84 percent of all breaches were detected in system logs.  By actively collecting security logs in real-time, organizations can not only monitor security events, but also prevent a data breach before it starts.  I recently sat down with Patrick Townsend, to discuss log collection and active monitoring on the IBM i.

Hi Patrick, can you give our readers an overview on the importance of collecting and monitoring security logs on the IBM i?

The Future of Active Security Monitoring on the IBM i One of the most effective things that you can do to prevent a data breach is to deploy an active monitoring solution, sometimes also known as system logging.  You’ll find active monitoring at the top of all cyber-security lists of things to do – because it is effective.  Active monitoring is key to a strong security posture, for anybody.

Today, we all know that there is no longer a true perimeter and that our systems are at risk.  Luckily, active monitoring can help.  Here are are some key principles that organizations need to understand.  First, an active monitoring solution needs to involve a log collection server or SIEM solution (IBM Security QRadar, Splunk, LogRythm, etc.) to collect security events across the entire enterprise and actively detect threats.  Second, there needs to be real-time collection and monitoring of security events.  Rather than scooping up the security events once or twice a day, it is imperative to be collecting these events in real-time. When you collect logs across the entire enterprise, a SIEM can provide a lot of intelligence to identify patterns and anomalies – which will identify a potential attack.  The final critical components are good reporting, query, and forensics tools.  SIEM solutions also give you the ability to quickly run reports and analyze suspect data.  This is important for two reasons.  If you are having an attack you need to identify quickly where the attack is originating and how it is happening.  This is essential in order to know how to remediate it.  If you aren’t able to pinpoint the problem, it is very likely that you are going to be attacked by the same methods again.

Switching gears, the serious points for an IBM i customer revolve around the fact that the IBM i is a critical back-office processor for most customers and runs multiple applications.  Too often the IBM i is an island within an organization, but it is important that it is fully integrated in your enterprise’s entire infrastructure security strategy.

Also, it is generally true that a cyber-attack almost never starts on an IBM i server.  They typically start on a compromised user PC or someplace in the organization.  From there, a hacker spends a fair amount of time probing around the IBM i finding any weak points.  We shouldn’t be naïve – hackers know about IBM i servers.  They know what to look for, they know the user IDs, they know how to compromise these systems – they are very good at it.

IBM introduced some new security event sources in V7R3.  Can you talk a bit about those? And what events should an IBM i customer be collecting?

Every release of the IBM i server has had new security events and fields to collect and monitor.  At Townsend Security we work very hard to stay ahead of these releases so that our customers are well positioned to handle new information and use it for protection.  A couple examples include IPV6 address support and new fields in existing events.  Regarding the recent V7R3 release, new sources include:

  • QAUDLVL (Auditing level) system value
  • *NETSECURE (to audit secure network connections)
  • *NETTELSVR (to audit Telnet connections)
  • *NETUDP (to audit UDP connections)

To address the second part of your question, when you deploy an active monitoring solution on the IBM i, you are certainly going to want to collect events from QAUDJRN, QHST, QSYSOPR, as well as exit points.  Interestingly, the QAUDJRN security audit journal does not exist when you first install a new IBM i server. You must create the journal receivers and the journal to start the process of security event collection.

Aside from the new log sources that IBM introduced in V7R3, for someone who maybe deployed a logging solution a few years ago, what should they be aware of now?

First, let’s take a look at how compliance regulations have been evolving.  We now know that most attacks work on the basis of privilege escalation.  For example, an attacker gets access to our systems and then eventually gets sufficient authority to steal data. Because of this, we are seeing that it is more important to identify when an administrative level or highly privileged user logs in to our system.  This is an example of how a logging solution needs to evolve to meet current compliance requirements. Businesses are now required to log and monitor that activity.

Unfortunately, this can be particularly hard on the IBM i.  On first look, an IBM i account may appear to have normal user privileges, but may in fact inherit higher privileges through a Group Profile or Supplemental Group Profile. It is important to detect these elevated privileges in real time and provide the security administrator with an easy-to-use report to identify the source of elevated privileges. This is an excellent example of how logging solutions need to evolve with the ways security events are monitored.  We recently tackled this in the latest release of our Alliance LogAgent.

Where do you see the future of logging on the IBM i?

Let me dust off my crystal ball!  First off, File Integrity Monitoring (FIM) will become more important.  To maintain a strong posture, security administrators need to know who is accessing sensitive data and system values on the IBM i.  We’re also going to see more requirements around File Integrity Monitoring across the regulatory compliance environments.  Why?  Because, as we discussed earlier, cyber-attackers escalate privileges, access sensitive data, and change security configurations in order to get the work done that they want to do.  Again, this is why we are seeing increased requirements in regulations like the Payment Card Industry Data Security Standard (PCI DSS) and new financial services regulations.

Another interesting prediction:  It won’t be unheard of for organizations to use multiple SIEM solutions. We are starting to see businesses use one SIEM for traditional security monitoring and another to monitor operational data.  Operational data, you ask?  Sure.  Logging solutions can easily allow administrators to answer operational questions like: How full are my disks?  Do I have any critical hardware errors?  Second, they can benefit from deploying a SIEM to monitor application data.  Sales teams, for example, can track inventory status, trending products, etc.  The benefits of file monitoring don’t have to be exclusive to security.

In the near future, we will also see a pickup of integration with Artificial Intelligence (AI), also commonly referred to as cognitive computing.  IBM has the Watson platform, and there are others, which I believe will be used to enhance security.  We are already seeing initial efforts in this respect.  Harnessing that AI capability with security makes total sense.  

Finally, as we are seeing, everything not bolted down is going to the cloud.  We will definitely see an evolution of new cloud services around security and logging.  It may take a little time for vendors to start leveraging that, but I believe it is definitely in the works.

To hear this interview in it’s entirety, download our podcast “The Future of Security Logging on the IBM i” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss log collection and monitoring on the IBM i, new log sources in V7R3, and the future of security logging on the IBM i.

The Future of Active Security Monitoring on the IBM i

Topics: System Logging, Alliance LogAgent

Townsend Security Announces Major Update to Alliance LogAgent for IBM i

Posted by Luke Probasco on Nov 29, 2016 12:01:00 AM

New features include full reporting of administrative users, including authority the user adopts through Group Profiles and Supplemental Group Profiles.

IBM i Security: Event Logging & Active Monitoring Townsend Security today announced a significant update to its existing Alliance LogAgent for IBM i (AS/400, iSeries) solution, allowing full reporting of administrative users, which includes authority the user adopts through Group Profiles and Supplemental Group Profiles. Alliance LogAgent is a Security Information and Event Management (SIEM) integration solution that collects, formats, and transmits security information in real-time to any SIEM or log collection server.

When the new configuration options are enabled, Alliance LogAgent will tag all significant security events as performed by the administrative level user. This enhancement will help security administrators easily identify which users have elevated privileges and enable SIEM solutions to quickly identify and alert on operations. In addition to the new administrative user reporting, Alliance LogAgent now provides an easy-to-use local assessment report that identifies privileged users. This will reduce the overhead of inspecting and adjusting privileges of IBM i users. 

Alliance LogAgent is compatible with all SIEM solutions that accept Syslog messages, IBM QRadar Log Event Extended Format (LEEF), or the HP ArcSight Common Event Format (CEF). The new administrative field reporting will make it easy for SIEM administrators to create dashboards, compliance reports, and alerts based on reported fields. When an administrator privileges are detected Alliance LogAgent adds the following field to the security message:

            admin_user=yes

For IBM QRadar the new field is:

            adminUser=yes

By providing a normalized field in the security events sent to the SIEM monitoring platform, the SIEM’s query and forensic tools can be used more effectively.

“Many IBM i customers have struggled with identifying who on their system has elevated privileges. It is crucial to identify and strictly control these users as cyber criminals often use privilege escalation to enable the exfiltration of sensitive data,” said Patrick Townsend, CEO of Townsend Security. “On first look an IBM i account may appear to have normal user privileges, but may in fact inherit higher privileges through a Group Profile or Supplemental Group Profile. Alliance LogAgent now detects these elevated privileges in real time, and provides the security administrator with an easy-to-use report to identify the source of elevated privileges. We think this is a crucial enhancement that will help IBM i customers better secure their platforms.”

Alliance LogAgent is in use with a wide variety of SIEM solutions including LogRhythm, SecureWorks, NTT Solutionary, IBM QRadar, Alert Logic, AlienVault, McAfee SIEM, Splunk, SolarWinds, and many others. In addition to collecting the IBM i security audit journal information Alliance LogAgent collects system history messages, operator messages, exit point information, system statistics, and a variety of open source application logs in Unix/Linux format.

The solution is licensed on a per logical partition (LPAR) basis, with perpetual and subscription licensing options available. Existing Alliance LogAgent customers on a current maintenance contract can upgrade to the new version at no charge.

IBM i

Topics: Alliance LogAgent, Press Release

IBM i Security: Auditing Privileged Users, Applications, and Database Files

Posted by Patrick Townsend on Nov 3, 2016 9:21:51 AM

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."


IBM i Security: Event Logging & Active Monitoring

Audit Privelaged Users

Attackers attempt to gain privileged access to your IBM i system and as a privileged user can perform a wide variety of tasks on the IBM i server. As a privileged user, an attacker can steal sensitive data or damage your system. You should strongly consider enabling full user auditing of any user profile that has a high level of privilege. This should include the IBM user profile QSECOFR and any user with All Object (*ALLOBJ) or Audit (*AUDIT) capabilities. The commands executed by the audit user are logged to the QAUDJRN journal. You can identify privileged users by running an IBM security report:

   PRTUSRPRF TYPE(*AUTINFO)
   SPCAUT(*ALL)

Once you identify privileged users you can enable user auditing with the Change User Audit (CHGUSRAUD) command like this:

   CHGUSRAUD USRPRF(QSECOFR)
   OBJAUD(*ALL) AUDLVL(*AUTFAIL *CMD
   *PGMADP *NETCMN *PGMFAIL)

Note that you may want to increase or decrease the information you audit for privileged users. See the help for the command options.

Auditing Highly Sensitive Applications and Database Files

You should also consider enabling application and database access audit where sensitive data can be changed or where sensitive data is stored. For example, a core HR application that contains employee information, or a core ERP application that stores credit card information should be audited. Once you have a list of sensitive application programs and database files you can use the Change Object Audit (CHGOBJAUD) command to enable auditing. Audit records are sent directly to the QAUDJRN security journal.

   CHGOBJAUD OBJ(PRODLIB/ORD001)
   OBJTYPE(*PGM) OBJAUD(*ALL)

For IFS Files and directories you can use the Change Audit (CHGAUD) command like this:

   CHGAUD OBJ(‘/mydirectory’)
   OBJAUD(*ALL) SUBTREE(*ALL)
   SYMLNK(*YES)

For more information on auditing privelaged users, applications, and database files, as well as more information on IBM i event logging and active monitoring, download our ebook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."
IBM i

Topics: System Logging, IBM i, Alliance LogAgent

Monitoring IBM i Logs with IBM QRadar - Improve Your Security

Posted by Patrick Townsend on Nov 2, 2015 10:25:00 PM

We all now know that active monitoring and rapid response is one of the critical security controls that really make a difference. That is why system log monitoring makes the Top Ten list of almost all cyber security controls. What is not so well known is how hard it can be to get active monitoring right. We have a lot of Security Information and Event Monitoring (SIEM) solutions to choose from, but very few of them are effective right out of the box. Why is this?

Podcast: Monitoring IBM i Security Logs with QRadar First, system generated logs are a mess. They are largely unformatted text messages without unique identifiers that make it hard for a SIEM solution to interpret. Add many different spoken languages and you have a major headache when it comes to interpreting log messages.

Second, other than some basic formatting guidelines, information in system logs is not normalized. While some log formatting standards like Common Event Format (CEF) and Log Event Extended Format (LEEF) attempt to provide this, very few devices actually format to these standards. The lack of system log standards contributes to the confusion when SIEM solutions attempt to interpret the log messages. It would make a database administrator shed tears.

Lastly, many SIEM solutions collect logs once or twice a day with some type of batch transfer, and events are not processed in real-time. Real-time analysis is core to effective SIEM monitoring of system logs. Without real time event collection it is difficult or impossible to do event correlation and the result is missed positives. All of that intelligence built into modern SIEM solutions can go to waste.

One thing I like about the IBM Security QRadar solution is that it comes with pre-defined definitions that out of the box know how to interpret logs from a wide variety of devices. IBM packages these definitions in a configuration object known as a Device Support Module, or DSM. IBM QRadar customers get access to all of these DSM definitions and they can be easily updated as new and revised configurations become available. This saves a security administrator a lot of time in configuring the SIEM to recognize events.

Another thing I like about IBM Security QRadar is that it understands that normalized data is important. The QRadar Log Event Extended Format, or LEEF, builds on IETF system log standards by adding well-defined data formats and field definitions. If all of your systems are reporting an IP address like this:

src=1.2.3.4

then you know that event correlation is going to work a lot better.

Our IBM i (AS/400, iSeries) solution for IBM Security QRadar integration is named Alliance LogAgent for IBM QRadar. It implements support for the QRadar LEEF data format for all IBM i security events, and transmits events in real time. IBM has now released an updated AS/400 DSM that includes recognition of the more than 200 security events transmitted by Alliance LogAgent for IBM QRadar. This means that customers deploying or updating their QRadar implementation get a much faster implementation and a much better security posture right out of the box. This new solution installs on an IBM i server very quickly and in minutes can be sending security events to IBM Security QRadar.

No one security control will make you safe. But actively monitoring your system and audit logs is crucial to a good security implementation.

For more information, visit our Alliance LogAgent for IBM QRadar or get started with a free evaluation.

Othwer Resources

Center for Internet Secuirity

SANS Top Ten (see CSC 6)

Monitoring IBM i Security Logs with IBM QRadar

Topics: Alliance LogAgent, logging

How Does LogAgent Send Security Information? Is Information Batched?

Posted by Patrick Townsend on Oct 23, 2015 4:34:00 PM

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

System Logging Resource Kit 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.

Request your System Logging Resource Kit

Topics: System Logging, IBM i, Alliance LogAgent

How Much Disk Storage Does Alliance LogAgent Use?

Posted by Patrick Townsend on Oct 16, 2015 3:57:00 PM

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.

System Logging Resource Kit 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!

Request your System Logging Resource Kit

Topics: System Logging, IBM i, Alliance LogAgent

What are the New IBM i Security Audit Journal Events for V7R2?

Posted by Patrick Townsend on Aug 31, 2015 8:44:00 AM

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:

IBM i Logging for Compliance & SIEM Integration 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 i logging for compliance & SIEM Integration

Topics: System Logging, IBM i, Alliance LogAgent

Which IBM i User Gets to My Log Collection Server and SIEM?

Posted by Patrick Townsend on Jul 10, 2015 10:44:00 AM

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.

IBM i Logging for Compliance & SIEM Integration 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:

Entry Type Effective User Job Type Job SubType Job Name Job User Job Number Job Name Job User
JS M BILL B QTFTP00548 QTCP 803244 QTFTP00548 QTCP

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.

IBM i logging for compliance & SIEM Integration

Topics: System Logging, IBM i, Alliance LogAgent

Configuring the IBM i to Collect Security Events

Posted by Patrick Townsend on Jun 23, 2015 8:09:00 AM

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:

IBM i Logging for Compliance & SIEM Integration 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.

IBM i logging for compliance & SIEM Integration

Topics: System Logging, IBM i, Alliance LogAgent

How Much Data Does Alliance LogAgent Send to My SIEM?

Posted by Patrick Townsend on Jun 19, 2015 8:27:00 AM

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!

IBM i Logging for Compliance & SIEM Integration 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:

Send to log server . . . . . . . 2 1=Yes, 2=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.

Topics: System Logging, IBM i, Alliance LogAgent


Subscribe to Email Updates

Posts by Topic

see all