AI SIEM for IBM i and AS400: QAUDJRN, QHST, SYSLOG and Security Context

AI SIEM starts with an IBM i data pipeline, not an AI feature

An AI SIEM can summarize an IBM i case, connect a user to related activity, suggest an investigation, and help an analyst review evidence. It cannot do any of that reliably if the IBM i records are incomplete, delayed, mapped to the wrong fields, or stripped of the context that gives an event meaning.

That is the part most product demonstrations skip. IBM i has strong native auditing, but the useful records live in platform-specific journals, messages, exit-point activity, application logs, database activity, and security product output. A central SIEM sees only what the organization deliberately extracts and sends. The work is to select the right sources, preserve their meaning, deliver them continuously, and prove the result before asking AI to interpret it.

QAUDJRN is the primary security source

IBM identifies QSYS/QAUDJRN as the primary source of system security auditing information. When auditing is configured, IBM i can record events such as authority failures, user profile changes, authority changes, object activity, auditing changes, network activity, command activity, and other security-relevant actions selected through QAUDLVL, QAUDLVL2, user auditing, and object auditing.

The journal does not become useful merely because it exists. A team has to decide what to audit, manage the receivers, protect access, retain the evidence, and verify that important event types are actually being written. IBM notes that the journal receivers are the security audit trail. Receiver rotation and storage management belong in the monitoring plan because a full, missing, or damaged receiver can break the evidence chain.

For extraction, IBM documents DSPJRN and CPYAUDJRNE, journal APIs, and SQL access through QSYS2.DISPLAY_JOURNAL and entry-specific services. A forwarding product may use one or more of those methods, but the buyer should still know the source entry type, selection rule, polling or streaming behavior, and failure handling.

QHST adds operations context but does not replace QAUDJRN

QHST is the IBM i history log. IBM describes it as a high-level trace of system activity that includes system, subsystem, job, device, and system message information. That context can help explain when a subsystem ended, a job failed, a device changed state, or an important system message appeared near a security event.

QHST is not the security audit journal. It does not contain the same structured record of authority failures, profile changes, object auditing, and other actions selected for QAUDJRN. Sending only QHST to a SIEM can create the appearance of IBM i coverage while leaving the security team blind to the events it actually expected to investigate.

The useful source inventory goes beyond two logs

An IBM i SIEM design normally needs more than QAUDJRN and QHST. The right mix depends on the applications, network exposure, security tooling, and compliance requirements. Build the inventory around investigation questions rather than collecting every record by default.

• QAUDJRN security audit entries selected through QAUDLVL, QAUDLVL2, user auditing, and object auditing
• QHST system, subsystem, job, device, and system message activity
• Authentication, sign-on, service, exit-point, and network activity that may come from IBM i or a security product
• Database monitoring and object-journal data when the investigation requires transaction-level evidence beyond security auditing
• Application logs, batch records, scheduled jobs, and business events that explain what a user action changed
• Security product alerts for privileged access, MFA, exit programs, antivirus, file integrity, or vulnerability management
• Infrastructure context from firewalls, endpoints, identity providers, email, cloud services, and ticketing systems

SYSLOG, CEF, LEEF, and JSON are transport shapes, not context

IBM i records are commonly forwarded through syslog or transformed into structured formats such as CEF, LEEF, or JSON. QRadar also supports several collection protocols and device support modules. The format matters, but it does not solve the mapping problem by itself.

A forwarded event should preserve the original event identity, timestamp and time zone, system name, partition, job, user profile, object, library, program, command or action, network address, journal sequence, entry type, result, and any source-specific fields needed to verify the record. Keep a reference to the raw record where practical. If every IBM i event arrives as a generic message string, AI and conventional correlation both have to guess at the structure.

Map IBM i identities and objects into the wider environment

The same person may appear as an IBM i user profile, an Active Directory identity, an email address, a VPN account, and an endpoint user. A useful SIEM needs a defensible way to associate those identities without assuming that similar names are the same person. Service profiles and shared profiles need separate treatment.

Object names also need context. LIBRARY/FILE, an IFS location, a program, a job, and a subsystem are not interchangeable resources. Preserve the native identifiers, then enrich them with ownership, criticality, application, environment, and business role. That gives an investigation enough context to distinguish a failed test job from activity against a production payroll object.

AI changes the investigation after the records are trustworthy

Once the data is usable, AI can reduce real work. It can group related events, build a timeline, explain IBM i entry types, connect activity across identity and endpoint sources, summarize a case, suggest the next query, and draft a review for a security or application owner.

The output still needs evidence. An analyst should be able to move from a conclusion to the IBM i records, related sources, queries, assumptions, and missing data behind it. The system should say when a source was late or unavailable. It should not turn an incomplete feed into a confident narrative.

Govern response more tightly than search

Searching and summarizing IBM i activity are lower-risk actions than disabling a profile, changing an authority, ending a job, or modifying a security setting. Separate read-only investigation from permissioned changes.

For every response workflow, document who can request it, what evidence is required, who approves it, which system and partition are in scope, how credentials are handled, what is logged, and how the action is reversed. An AI SIEM should work inside those controls rather than inventing them during an incident.

Run one event from source to case before expanding

The first proof should be small and complete. Choose a known event such as an authority failure or a controlled profile change. Generate it in the approved test scope, confirm the QAUDJRN entry, observe extraction and transport, inspect the normalized fields, verify the detection, and review the evidence shown in the case. Measure delay at each step.

Then interrupt the pipeline. Stop or delay the forwarder, rotate a receiver, or remove a required field in a controlled test. The monitoring layer should identify the data-health problem. A SIEM that alerts on threats but not on a broken IBM i feed can report false confidence for weeks.

Use the existing IBM i software records to build the shortlist

The AS400 Software directory already separates the forwarding and analytics parts of this decision. Review the Syslog and SIEM for IBM i record for the collection and transport layer, and the QRadar AI Cybersecurity Intelligence record for one current analytics platform. They are starting points, not automatic recommendations.

The right shortlist follows the source inventory. Confirm which entry types and fields each integration supports, whether delivery is real time or scheduled, how source health is monitored, what happens during receiver changes, and how custom IBM i records are parsed. Then test the same known event through every finalist.

Common questions about this IBM i Security Monitoring topic.

Can AI SIEM read QAUDJRN directly?

Some IBM i security or forwarding products can extract QAUDJRN data and send it to a SIEM. The exact method varies. Verify which entry types are selected, how records are parsed, how quickly they are delivered, and how a failed feed is detected.

Is QHST enough for IBM i security monitoring?

No. QHST provides high-level system, subsystem, job, device, and message activity. QAUDJRN is the primary security audit source for selected security events. Many environments also need application, database, exit-point, identity, network, and security-product data.

Does IBM i send SYSLOG natively for every security event?

Do not assume that every required IBM i security record arrives as ready-to-use syslog. Confirm the extraction and transformation design for QAUDJRN, QHST, application records, and security-product output, then verify the fields inside the destination SIEM.

What should an IBM i AI SIEM proof of value test first?

Start with one known, controlled event. Follow it from the IBM i source through extraction, transport, normalization, detection, evidence, and case output. Then test whether the platform notices when that data feed is delayed or broken.

Glossary for this article

• AI SIEM A security information and event management platform that uses machine learning or generative AI in data preparation, detection, prioritization, investigation, or response.
• SIEM Security Information and Event Management: centralized platforms that collect, correlate, and alert on security event logs across an organization's systems, including IBM i.
• QAUDJRN The security audit journal in library QSYS and the primary IBM i source for selected security auditing information.
• QHST History Log The IBM i history log containing a high-level record of system, subsystem, job, device, and system message activity.
• SYSLOG for IBM i A logging integration pattern that forwards IBM i security and operational events into SIEM or centralized monitoring platforms.
• Common Event Format (CEF) A structured text format used to represent security events as a standard header followed by extension fields that SIEM platforms can parse.
• Log Event Extended Format (LEEF) IBM QRadar's structured event format for identifying a source and carrying security-event attributes that QRadar can process.
• Security Data Pipeline The collection, parsing, mapping, enrichment, filtering, and delivery work that turns IBM i and enterprise telemetry into usable SIEM data.
• QRadar IBM's security intelligence and SIEM platform, often evaluated as a destination for normalized IBM i security and event data.

Go deeper on this topic

• Syslog and SIEM for IBM i The IBM i collection and forwarding layer already represented in the software directory.
• QRadar AI Cybersecurity Intelligence One current SIEM and analytics record in the catalog.
• IBM i security levels and best practices How QSECURITY, authority management, audit journaling, and SIEM visibility fit together.
• AS400 Security The dedicated security property's auditing and logging reference.

Sources

• IBM Documentation: Using the security audit journal
• IBM Documentation: Setting up security auditing
• IBM Documentation: Audit Journal entry types
• IBM Documentation: Analyzing audit journal entries
• IBM i Work Management: QHST history log
• IBM QRadar SIEM integrations