Integrating IBM i Security Events into Your SIEM

In the summer of 2018, IBM celebrated the 30th anniversary of the launch of the AS/400 midrange server and its corresponding operating system, OS/400. Through years of successful growth, this reliable platform has become an integral part of IT operations for organizations worldwide.

It is estimated that there are over 350,000 systems in active use running these types of mission-critical applications such as enterprise resource planning, retail, hospitality, and core banking.

IBM i's user base is passionate and loyal. Users appreciate the simplicity of the object-based architecture, unique features like single-level storage, and the fact that the DB2 database is integrated into the operating system.

Today, IBM markets the IBM i OS as part of the Power Systems platform alongside AIX and UNIX. IBM i incorporates TCP/IP networking technology and there is even a file system to store UNIX and Windows files.

The business applications running on IBM i house critical data, such as credit card data, social security numbers, bank account information, and customer and patient records in the integrated DB2 database. In recent years, Sarbanes-Oxley, HIPAA, PCI, GDPR, and GLBA regulations have placed increased emphasis on the need to adequately control and secure such information. Along with preventive measures, organizations around the world are implementing a tighter set of detective controls over the configuration and use of their business applications and servers. Many companies have adopted frameworks such as ISO 27002, COBIT, and NIST to guide the definition and implementation of their security policies. New requirements for SOX, HIPAA, PCI, and many other regulations require close monitoring and analysis of activity logs on critical systems.

The Payment Card Industry Data Security Standard (PCI DSS) has defined some of the most specific requirements of any regulation—logs must be reviewed daily and a minimum of three months’ logs must be immediately available for analysis. Other regulations like the Nevada Gaming Commission Minimum Internal Control Standards (MICS) have followed the lead of the credit card industry and imposed similarly stringent requirements. Despite the importance of the data it stores, security is often poorly defined and configured on IBM i. A recent study showed that, on average, IBM i servers had over 100 users with root-level authority. The typical system has 89 users with default passwords that are the same as the user name.

Today the emphasis of general security spending has shifted away from perimeter security (firewalls, antivirus, and intrusion detection) to compliance initiatives and guarding against the insider threat from employees.

Auditors now demand that IBM i logs and event data receive the same level of monitoring and attention as other platforms. IT executives and security management expect that log data and events from the platform running their most critical business applications should receive the same level of attention as their firewalls, switches, Windows, and UNIX databases.

Driven by the wave of regulations, a new class of security solution provider has emerged called Security Information and Event Management. Gartner’s Magic Quadrant for this category tracks over 15 vendors, including: Splunk, LogRhythm, SolarWinds, and AlienVault.

SIEM solutions provide reporting and analysis of data from host systems, applications, and security devices and correlate and aggregate data from many different sources, providing the reports that are required for internal audits and compliance. These SIEM solutions also provide event escalation and alerting functions that support the incident management and response needs of the IT security organization. Correlation engines analyze network data in real time and look for patterns and trends—for both internal and external threats. Solutions that were originally developed as a way to manage the vast quantity of data from intrusion detection systems are now being used to monitor identity and access logs for compliance purposes. Recent trends in the SIEM market have seen a new focus on logs provided by applications.

SIEM tools often use a computer data logging standard called syslog to integrate security event data from multiple sources into a central repository. Syslog was developed in the 1980s and is now supported by a wide variety of devices across multiple platforms, including Power Systems servers.

Syslog exchanges data in TCP/IP networks using a simple protocol. The syslog sender sends a small text message to the “syslog daemon” or “syslog server.” Messages are labeled with a facility code (indicates the type of program logging the message) and assigned a severity (emergency, alert, critical, error, warning, notice, info, debug). Almost all SIEM solutions can accept a feed from a syslog server.

Enterprises are now expecting that SIEM solutions also include data from IBM i, but this has proven problematic. One of the very powerful features of the operating system is the ability to log and record pretty much everything that happens on the system to a secure audit journal. This journal, QAUDJRN, is tamperproof—once an event is logged to the journal, it cannot be altered or individually removed from the log.

Many people do not use the logging capability because they are unsure how to configure it to selectively gather events of importance (i.e., event types, objects, and user profiles). Additionally, the audit journal can consume enormous quantities of disk space (multiple GB per day is common) and the data logged is difficult to read and interpret.

There are over 70 different types of security events and transactions that the OS can record to the journal. Many vendors, including Fortra, have also leveraged the power and integrity of the audit journal to log and record their own transactions. Some of the relevant activity that can be gleaned from QAUDJRN includes:

• Invalid login (sign-on) attempts
• Command usage by specific users
• Creation, movement, restoration, and deletion of objects (including database files)
• Changes to system values and user profiles
• Authority failures
• FTP and ODBC network transaction details
• Profile swapping activity

There are three simple steps to set up IBM i security auditing, and the operating system provides for granular controls by object and user profile:

1. Security Auditing is configured using the Change Security Auditing (CHGSECAUD) command. The level of auditing can be configured using the QAUDLVL system value. 
2. Specify sensitive and critical files to be audited using the Change Object Auditing (CHGOBJAUD) command.
3. Specify auditing for powerful or privileged users using the Change User Auditing (CHGUSRAUD) command.

The Fortra guide Security Auditing in the Real World provides a much more detailed guide for configuring and adjusting audit controls on IBM i, along with explaining appropriate settings for these parameters. Table 1 indicates some of the QAUDLVL controls that are used to turn on common event types.

Along with events that are written natively by the operating system, vendors can also log important security events. Over the years, IBM has extended the power of IBM i by adding tools that allow data to be accessed from other platforms, including PCs. Well-known services such as FTP, ODBC, JDBC, and DDM are active and ready to serve up data across the network as soon as the machine is powered on.

The operating system does not provide a native log of such network activity, but IBM has provided a means to mitigate this exposure by creating ‘exit points’ at the network services. An ‘exit program’ that is attached (registered) to the exit point can be used to monitor and log access through the network services. IBM i exit programs can also be configured with access control rules that limit access through network services based on user names and IP addresses. A well-written exit program will log and record network activity to secure, and write-once, tamperproof journals like QAUDJRN.

IBM i can produce vast amounts of audit logs—logs that are often of little or no use if the system has not been properly configured. One production system alone can generate thousands of events per second when object-level auditing is fully configured. Often IBM i system needs for object-level auditing are driven by the high-availability software provider and not just security and compliance considerations.

Some SIEM vendors have provided a basic level of support for IBM i in their products by providing agents. However, the solutions provided by SIEM vendors have limitations because their development teams have limited experience programming for IBM i. The SIEM vendors often don’t understand the context of the events, and they don’t know how to map them into their own solutions. In many cases, the SIEM vendor just converts the audit journal to a flat file every few hours and copies it over to a Windows or Linux server. This type of solution can have a huge impact on bandwidth. Additionally, solutions provided by SIEM vendors pose another serious limitation—real-time awareness of security events, as they happen, is not provided.

Any agent that provides monitoring of security events as they happen on the system needs to have the following characteristics:

• Interpretation of events—translate the IBM i-specific jargon into actionable statements that IT security staff can understand.
• Documentation that explains the impact and meaning of each event.
• Filtering of events so that everything sent to the journal is not sent beyond the platform to a central logging solution. Often object-level auditing needs to be configured to support the needs of high-availability software, and events are recorded that are not relevant for security and compliance purposes.
• Filtering by day, time, IP address, user profile, and event type. Before any events are forwarded to a SIEM solution, there should be a more granular level of filtering than provided by the operating system’s audit controls.
• Logging of network activity (FTP, ODBC, remote command) by exit programs.
• Integration with leading SIEM solutions so that events are also mapped and normalized to the schema used by the SIEM vendor.
• Support for logs beyond QAUDJRN; critical CPF messages from the operating system and logs from Apache web server.
• When putting software on any production IBM i system, you need to be confident that it will work on a mission-critical production system—companies want a solution that has been programmed by someone with expertise on the platform.
• Dedicated support from a technical team with mastery of IBM i issues and implementation support from engineers that understand the platform.
• A future roadmap that shows continued investment in the product.

Powertech SIEM Agent for IBM i meets all of the above requirements, and takes only a couple configuration steps to point to the syslog server of your choice. Retailers and financial institutions are using Powertech SIEM Agent for IBM i to meet the onerous requirements of the PCI standard. Powertech SIEM Agent for IBM i monitors hundreds of different events, including audit journal events and operating system messages.

Powertech Exit Point Manager for IBM i provides exit program access control and logging. When it is installed, Powertech SIEM Agent for IBM i can also gather and send transactions that are logged by Exit Point Manager.

Powertech Authority Broker for IBM i helps you keep tabs on privileged users with profile swaps, firecall, and screen captures. When used with Powertech SIEM Agent for IBM i, privileged user activity such as invalid swap attempts or when a swap starts or ends, can be gathered and sent to your SIEM solution for real-time monitoring.

Read more about Powertech SIEM Agent for IBM i or contact us to schedule a demo and see firsthand how Powertech SIEM Agent for IBM i can solve your real-time security event monitoring needs.