Adding IBM Guardium via Syslog

Updated November 13, 2026 12:17

Purpose

This guide explains how to forward IBM Guardium Data Protection events to Logsign USO over syslog and what Logsign does with them. The integration reads the LEEF messages that Guardium collectors send through syslog. It covers two kinds of messages: policy alerts (for example SQL errors or repeated failed logins) and SQL audit records written by a policy rule with the Log with details action.

Prerequisites

A Guardium administrator account that can configure remote syslog and message templates on each collector.
Network connectivity from every Guardium collector to the Logsign USO collector on your syslog port (TCP or UDP 514 by default).
The Logsign user account that will add the data source needs access to Settings > Data Collection.

Step 1: Forward Guardium events to Logsign

Guardium sends policy alerts and audit records to a remote syslog server from each collector. Use the IBM Guardium documentation for your version to add the IP address of the Logsign USO collector as a remote syslog destination (on most versions this is done from the Guardium CLI with the store remotelog command). Configure this on every collector that should send events.

Select the LEEF message template for the events you forward. In the policy rules whose events you want in Logsign, use an action that sends the event to syslog, such as an alert action for policy violations or Log with details for SQL audit records. Keep the default Guardium LEEF fields. Logsign recognizes messages from the guard_sender process.

Step 2: Add the data source in Logsign USO

Open the Logsign USO web interface and click + Device under Settings > Data Collection. Choose Syslog as the collection method, select IBM as the vendor and Guardium as the product, and enter the IP address of the Guardium collector as the host. Repeat this for every collector that sends logs. Click Save. Once Guardium starts sending, events appear under Search.

Supported message formats

Every message starts with a syslog header that carries the Guardium collector name and the guard_sender process, followed by a LEEF header and a list of Key=Value pairs separated by the | character. Two typical events look like this (anonymized, query shortened):

A value runs until the next |Key= separator, so SQL text that contains =, ( or ) is kept as one value. Keys with an empty value are not written.

Field mapping

The alert template and the Log with details template use different key names for the same information. Logsign reads the alert key first and the Log with details key second.

Logsign field	Alert template key	Log with details key
Time.Generated	devTime	devTime
Source.IP	src	src
Source.Port	srcPort	spt
Source.UserName	dbUser	usrName
Source.HostName	-	HostName (database client)
Destination.IP	dst	dst
Destination.Port	dstPort	dpt
Protocol.Name	protocol	proto
Event.Info	LEEF header event name	name
Event.Category	classification	cat
Event.SubCategory	category	-
Event.Type	type	EventType
Event.ID	-	EventId
Rule.ID	ruleID	-
Database.Query	sql	RawQuery
Database.ParsedQuery	-	ParsedQuery
Object.Name	-	ObjectsName
Operation.Name	-	Operation
Service.Name	-	ServiceName
Application.Name	-	ApplicationName
Account.ConnectState	-	UserAuthenticated
Error.Message	error	SQLError
EventSource.Version	LEEF header version	LEEF header version

EventSource.HostName always shows the Guardium collector from the syslog header. The database client host name from the LEEF HostName key goes to Source.HostName.

Event classification

Logsign classifies each event with the value of type (alert template) or EventType (Log with details). For example, SQL_ERROR maps to Object / Database / Error and LOGIN_FAILED maps to Identity / User / Deny. The Log with details event types BIND_DATA, RAW_STATEMENT and SQL_LANG map to Object / Database / Info (Database Object Info Query).

Notes and limits

For alert messages, the severity comes from the severity key (INFO, LOW, MED, HIGH). Log with details messages carry a sev key that Logsign does not read; their severity comes from the syslog priority of the incoming message.
Some Log with details keys repeat information that is already mapped (externalId, requestMethod, ResponseTime, SourceApplication, requestClientApplication) and are not mapped to separate fields. OSUser is also not mapped.
If Log with details events arrive without Source.Port, Database.Query or Object.Name, or if SQL queries appear cut at the first = character, the appliance is running an older version of the IBM Guardium plugin. Contact Logsign support to confirm the version you need.

Verification

In Logsign USO, open Settings > Data Collection and confirm that the Guardium source is receiving data.
In Search, look for events with Vendor IBM and Product Guardium. EventSource.HostName should show the Guardium collector name.
Run a query on a database that a Log with details rule monitors. The event should show the query in Database.Query, the table in Object.Name and the database client in Source.HostName, with EventMap Object / Database / Info.
If the source is receiving data but no events show Vendor IBM, the messages are not in a format this integration recognizes. Check that Guardium uses the LEEF template and that nothing on the way rewrites the syslog header.