Townsend Security Data Privacy Blog

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!

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 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.

IBM i users who need to meet compliance regulations for actively monitoring their systems are faced with the challenge of collecting system and security events from a variety of log sources. Collecting events from the security audit journal QAUDJRN is a fundamental requirement, but is it the only place that contains significant security events? The answer is no, there are also significant security events in the system history message file QHST.

The most significant security events contained in QHST are the user log on and log off messages. These are stored in the QHST message files with message IDs CPF1164 (log on) and CPF???? (log off). User log on and log off events are, of course, critical for active monitoring of system access, especially for highly privileged users such as QSECOFR and any user with All Object (*ALLOBJ) and security special authorities of Audit (*AUDIT) and ????.  The log on and log off activities recorded in the QHST message files are not available in the security audit journal QAUDJRN, so you must be able to retrieve these messages from QHST to meet compliance regulation requirements for log collection and active monitoring.

Alliance LogAgent supports this requirement by enabling the collection of these events from QHST message files. You can filter QHST message to collect only events for:

• Log on and Log off messages for all users
• Log on and Log off messages for only highly privileged users
• Log on and Log off messages for only QSECOFR
• All QHST messages

User log on and log off messages are not the only events that have security information. Most IBM i customers will select the Alliance LogAgent option to process all messages in QHST. This gives you a complete record of all events in the QHST message file in your log collection central repository.

There are many challenges in processing messages in the QHST file. These include:

• The QHST information is in an IBM proprietary format that is impossible for log collection servers and SIEM solutions to process. The messages must be converted to a usable format.
• QHST message files have a special naming convention and the system automatically generates new QHST message files on a regular basis. You must detect new message files and keep track of which files and messages have been processed.
• There are no event-driven APIs that allow you to collect new QHST messages in real time. Your QHST collector application must detect new events and process them quickly.
• The QHST files are not updatable, so your QHST event collector must keep track of the messages that have been processed, and must resume after a system IPL or a system failure without lost information.
• QHST messages are not automatically transferred to a log collection server or SIEM solution. Communications programs must be able to transfer the messages in real time.

Alliance LogAgent meets all of these challenges. QHST message files are automatically processed in near real time, and handles the generation of new QHST message files by the system. Messages are converted from the proprietary IBM format to the industry standard syslog format (RFC 3164) and converted from EBCDIC to ASCII. Messages are then transmitted to the log collection server or SIEM solution securely and in real time.

The Alliance LogAgent QHST message collector is a part of the base product. If you are currently using LogAgent to process QAUDJRN events, you can just enable the QHST option and you will start processing messages the next time the Alliance LogAgent subsystem starts. If you are implementing Alliance LogAgent for the first time, just enable the Logagent QHST collector before you start the subsystem.

View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

Patrick

Active monitoring is one of the core security recommendations to help prevent unauthorized access to sensitive systems and information. It is a requirement of a wide variety of compliance regulations such as PCI-DSS, HIPAA/HITECH Act, GLBA/FFIEC, FISMA, and many others. From a security perspective, active monitoring makes it into the SANS Top 20 list of things you should do, and is a key recommendation from the US Cyber Security teams.

What are the core requirements for active monitoring and what are the special challenges for the IBM i platform? Some core requirements include:

• Centralize security events from all servers and PCs
• Perform real-time collection to one central repository
• Real-time monitoring of events
• Conduct real-time event correlation for pattern recognition
• Store events in historical archives for forensics
• Pro-actively alert the security team for possible breaches
• Provide event query and reporting services

To meet these requirements for active monitoring, the IBM i can’t be an island of event information. IBM i security events must be consolidated with event information for all of your PCs, servers, and network devices to get a complete picture. Because the volume of events is typically quite large, most organizations will deploy a centralized log collection server combined with a SIEM solution that provides event correlation, real-time monitoring, alerting, and log collection archival.

One of the biggest challenges for IBM i customers is the large number of sources for log information. These include:

• IBM Security Audit Journal QAUDJRN
• System operator message queue (QSYSOPR, QSYSMSG)
• System history message file QHST
• IBM exit points (SQL, Telnet, FTP, and many more)
• Linux/Unix style logs (Apache, OpenSSH, Perl, PHP, etc.)
• DB2 column access
• User and ISV applications

A good security event collection strategy will have to address all of these sources. Added to the large number or sources are some additional challenges:

• Security event collection applications are not provided by IBM. They must be written by in-house developers or acquired from third parties.
• Security information is in non-standard, proprietary IBM formats.
• There are no native communications applications to securely transmit event information to a log collection or SIEM server.
• There is no application management structure (start, stop, re-start, audit, etc) for log collection activities.

Alliance LogAgent helps IBM i customers meet all of these challenges. It collects security event information from all significant log sources, converts information to industry standard formats including the syslog format (RFC 3164) and Common Event format (CEF), provides filtering options for messages, and securely transmits them to the log collection server or SIEM solution. Alliance LogAgent keeps track of event sources and won’t skip messages due to an IPL or network outages.

Alliance LogAgent is compatible with all major log collection servers and SIEM solutions, and is an affordable solution for small organizations. View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

 
Patrick

Do you know which of these 3 key regulations apply to you and your company?

Secure system logging on your IBM i (AS/400) can do more than help you meet compliance requirements, it can also help you stop a data breach before it happens!  We will take a quick look at three of the major regulations; PCI DSS, GLBA/FFIEC, HIPAA/HITECH, (keep in mind, there may be other compliance regulations that apply to system logging in your industry as well).

All regulations say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them. It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files, tamper resistant, and verifiable.

PCI DSS

Section 10 requires logging for anyone who collects credit card data

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.6.x v3 (Nov 2013) noted this clarification: Clarified the intent of log reviews is to identify anomalies or suspicious activity, and provided more guidance about scope of daily log reviews. Also allowed more flexibility for review of security events and critical system logs daily and other logs events periodically, as defined by the entity’s risk management strategy.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC

Recommends data security logs of actions that could affect financial reporting or fraud for financial institutions

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

FFIEC Action Summary

Financial institutions should gain assurance of the adequacy of their risk mitigation strategy and implementation by:

• Monitoring network and host activity to identify policy violations and anomalous behavior
• Monitoring host and network condition to identify unauthorized configuration and other conditions which increase the risk of intrusion or other security events
• Analyzing the results of monitoring to accurately and quickly identify, classify, escalate, report, and guide responses to security events
• Responding to intrusions and other security events and weaknesses to appropriately mitigate the risk to the institution and its customers, and to restore the institution's systems

HIPAA / HITECH ACT

Requires system logs of access to Protected Health Information (PHI) in the medical sector

• Security Management Process - §164.308(a)(1)(ii)(D):
  - Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)(.c) 
  …the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”
• Access Controls - § 164.312(b)
  (section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

System logging is important across all operating systems, however the IBM i is a major target for data theft because of the volume of information that can be managed in the system. Because the IBM i system can handle multiple applications, it doesn’t log information like others do. The IBM i collects logs simultaneously from multiple sources and may deal with large volumes: Up to 3,500 events per second…250 Million of events per day! These events need to be consolidated and correlated in a separate location, usually a Security Information and Event Management (SIEM) console, in order to see the whole picture and understand potential attacks on the system.

Because many unwanted intrusions start with a simple password hack that gives deeper access into your system, there is usually a long trail visible within system logs. What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management (forensics show 69% of breaches were detectable via log evidence). Everything, starting from the original breach, can be detected and identified with proper monitoring of the system logs.

To delve deeper into system logging, we are sharing a resource kit of materials by industry expert Patrick Townsend about logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between the IBM i and SIEM Console.

Alliance LogAgent from Townsend Security

• Creates real-time logs that ALL SIEM consoles can read
• Forwards important information to your SIEM console in a standard format
• Uses SSL/TLS encryption to secure delivery

IBM i users who need to meet compliance regulations for actively monitoring their systems are faced with the challenge of collecting system and security event information from a variety of log sources. We know we have to collect information from the IBM security audit journal QAUDJRN, but there are often additional security events in the system operator’s message queue QSYSOPR. The system operator message queue receives message from the IBM i operating system as well as from user applications.

There are many challenges in processing messages in the QSYSOPR file. These include:

• The QSYSOPR message information is in an IBM proprietary format that is impossible for log collection servers and SIEM solutions to process. The messages must be converted to a usable format.
• Access to the QSYSOPR message file by an event collector can conflict with the access by the actual system operators.
• There are no event-driven APIs that allow you to collect new QSYSOPR messages in real time. Your QSYSOPR message collector application must detect new events and process them quickly.
• The QSYSOPR messages are not updatable, so your QSYSOPR event collector must keep track of the messages that have been processed, and must resume after a system IPL or a system failure without lost information.
• QSYSOPR messages are not automatically transferred to a log collection server or SIEM solution. Communications programs must be able to transfer the messages securely in real time.

Alliance LogAgent meets all of these challenges. QSYSOPR messages are automatically processed in near real time. To avoid potential access conflicts, Alliance LogAgent can collect messages from the QSYSMSG message queue. Messages are converted from the proprietary IBM format to the industry standard syslog format (RFC 3164) and converted from EBCDIC to ASCII. Messages are then transmitted to the log collection server or SIEM solution securely and in real time.

The Alliance LogAgent QSYSOPR message collector is a part of the base product. If you are currently using LogAgent to process QAUDJRN events, you can just enable the QSYSOPR message file option and you will start processing messages the next time the Alliance LogAgent subsystem starts. If you are implementing Alliance LogAgent for the first time, just enable the LogAgent QSYSOPR collector before you start the subsystem.

View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

Alliance LogAgent is a product designed with the intent of reading your security audit journal event entries, then formatting and forwarding those events to any SIEM or LEM device, but LogAgent provides several significant features and functions that you may not be aware of.   In this article I will discuss five of these highly valuable features of the Alliance LogAgent product that you may not know about.

1. Exclude trusted users to reduce volume. In addition to allowing system administrators to filter out various event types from reporting, Alliance LogAgent will also allow you to filter out all events created by specified user profiles through the use of an “Excluded Users” list.  System admins may occasionally find it necessary to filter out all audit events created by implicitly trusted system user profiles.  Alliance LogAgent allows you to configure this ability at the IBM i level so that you can block those events from reaching your SIEM, thus reducing the volume of events that the SIEM must filter from reports.
2. Secure communications between agent and SIEM. While most SIEM solutions provide support for TCP and/or UDP connections to agents, Alliance LogAgent also supports the use of SSL/TLS secure connection for customers who need to protect the privacy of the communications between the agent and the SIEM.  With the simple addition of certificates to the IBM i Digital Certificate Manager and configuration of an Application ID tied to the certificate, Alliance LogAgent can be quickly configured to use SSL/TLS communications to protect your communications with the SIEM.
3. Exit Point monitoring. In the IBM i environment many IBM applications provide Exit Points that can be used to trigger flags for reporting or launching other processes.  Alliance LogAgent has the ability to monitor these Exit Points and create audit events that get reported to the SIEM so that system administrators can use the SIEM to monitor many of those functions.  Providing Exit Point monitoring within Alliance LogAgent allows the SIEM to provide administrators with valuable reporting of the use of many of these systems within the IBM i.
4. File Integrity Monitoring. File integrity monitoring is recommended under PCI DSS and other regulations.  Even in other environments it is often highly desirable to be able to verify and monitor the integrity of data within database files.  Alliance LogAgent has an add-on module that provides this highly valuable File Integrity Monitoring (FIM) function.  Database Monitor allows the admin to determine which files and which fields within those files need to monitored for access and integrity.  Database Monitor will record the original field data and also the new values recorded in the field, as well as application and user information for how and when the data was changed.  This integrity monitoring allows you to also set alerts to administrators if unauthorized users, or applications alter data, or if data changes violate configurable thresholds. 
5. Simplified formatting for event reporting. In the world of event management there are many possible SIEM and LEM systems and services available.  Some of these SIEM and LEM systems use Common Event Format (CEF) for handling event data, while others use the Syslog (RFC3164) format.  Alliance LogAgent provides configuration options to support either of these two formats and is compatible with a wide range of SIEM and LEM devices and services without any need for additional IBM i support or programming.  Simply select a couple of collector and formatting options in the product configuration panels, specify the destination address of the SIEM device, and start the system.  You can begin seeing your IBM i audit events at the SIEM in a matter of minutes from initial installation of the product.

With the importance of event monitoring becoming more critical for system administrators, it is important to choose a logging solution that will meet your needs.  Alliance LogAgent’s wide range of features, combined with the ease of setup and configuration, allows system administrators great flexibility while still allowing for rapid deployment with nearly zero impact on daily operations.