IBM Support

Shipping Guardium Syslog to Remote Server

Technote (FAQ)


Question

How do I ship Guardium Syslog to an SIEM or an Enterprise Event Monitor?

Answer

The Guardium appliance has the ability to send logs and alerts to a remote daemon using a predefined message format. The receiving daemon receives the message, parses and processes it. This document does not address setting up the central daemon. Please refer to the vendor of the Event Monitor.
The steps to setup Guardium to ship the logs are:

  1. Gather reporting requirements.
  2. Verify the central host is listening for remote messages. Gather the hostname (or IP address) and the port number.
  3. Setup the Guardium appliance to forward log messages.
  4. Send a test message from appliance and verify receipt on central host.

Central Host Configuration:
Verify that the central host is listening for forwarded messages. This is typically by means of rsyslogd. If a different daemon is listening for shipped logs, verify that that process is running. The following pieces of information from the central host are required:
  • The IP address or the name of the host. The host must be accessible from the Guardium appliance.
  • The port that the Event Monitor is listening. The default port in Guardium is 514/UDP. The Guardium appliance can be configured to use the port and the protocol that the Event Monitor is using.
  • The message format that the Event Monitor requires, in order to be able to understand the message. This is specific to each Event Monitor. Please refer to the vendor of the Event Monitor. This document lists the message template variables that Guardium can send.
  • The message facility and the message priority that the Event Monitor requires.

Message Facility: Guardium supports the standard syslogd facilities.
    auth authpriv cron daemon ftp kern lpr mail mark news security syslog user uucp local0...local7
    An all-inclusive facility called “all” will ship all syslog events.

The Guardium application messages originate from the “daemon” facility.

Message Priority: Guardium supports the standard syslog message priorities:
    alert crit debug emerg err info notice warning
    An all-inclusive priority called “all” will ship logs for any priority.

Guardium Remote Log Configuration:
Configuring the Guardium appliance to ship logs to a remote consists of 2 parts
    • Remote log store configuration
    • specifying the message template for the Event Monitor.

Remote log store configuration:
This is managed from the CLI command line.
  • To get the help screen for remote log configuration, type:
      cli> store remotelog help
  • To view the current remote log store:
      cli> show remotelog
      If no remote log store is configured, this command will return:
        Not configured.
      If remote log stores are configured, this command will list them. For example:
        *.* @10.10.9.56
  • To configure one or more remote log store(s):
      cli> store remote log add facility.priority host[:port] <tcp|udp>

      Examples:
      • To ship Guardium application logs to cem.example.com (192.168.1.6) using the default port 514 using UDP for all priorities:
          cli> store remote log add daemon.all cem.example.com udp
          cli> store remote log add daemon.all 192.168.1.6 udp
      • To ship Guardium application logs to cem.example.com (192.168.1.6) using port 1514 using TCP for all priorities:
          cli> store remote log add daemon.all cem.example.com:1514 tcp
          cli> store remote log add daemon.all 192.168.1.6:1514 tcp
      • Guardium supports shipping logs to multiple remote hosts. These remote stores can be configured variously in terms of hostname (or IP), ports, facilities and priorities.
          cli> store remote log add daemon.all cemgdm.example.com udp
          cli> store remote log add auth.all cemauth.example.com udp
  • To remove a remote store:
      This is the converse of the add command, replacing the add clause with “clean”.
        cli> store remote log remove facility.priority host[:port] <tcp|udp>

Specifying the message template for the Event Monitor
This is accomplished from the Guardium GUI.
  1. Log into the Guardium appliance GUI as a user with admin privileges.
  2. Navigate to Administration Console/Configuration/Global Profile
  3. Edit the “Message template” text box as required. Please note that the text must be in a single line without line breaks or form feeds. This template affects only remote log shipping. Please refer to Appendix 1 for the list of message parameters supported by Guardium.
  4. Restart the Inspection Engines. Please note that whenever the message template is edited, the inspection engine must be restarted in order to update the Guardium Appliance. All the configured Inspection Engines can be restarted via the CLI using a single command:
    1. Log into the Guardium appliance as user CLI
    2. Type: "restart inspection-engines"
TIP: If you are using a text editor such as “notepad” that has the facility to wrap lines for better visibility, turn off wrapping before copying the text, as it may introduce line breaks

Example screen shot:


Testing the configuration:

  1. If a policy that logs alerts to syslog does not exist, create a temporary policy rule that logs a message to syslog. The simplest, perhaps,is a FAILED LOGIN policy rule.
  2. Login to the database server with an invalid password.
  3. Verify that the alert has been received by the Event Monitor.

Troubleshooting:
  • If the remote host is specified by name, verify that the name can be correctly resolved by the Guardium appliance. The following CLI commands will list the DNS and route settings:
      cli> show network routes defaultroute
      cli> show network resolver <n> (where n is a number from 1 to 3 depending on the required DNS resolvers)
      If these values are incorrect, correct them as necessary using:
      cli> store network defaultroute <ip-address>
      cli> store network resolver <n> <ip-address>

      If these values are correct, verify that the Guardium appliance can reach the remote host, by replacing the host name with its IP address.
  • Verify that the port and protocol specified in the remote log store configuration is correct.
  • If messages are still not received by the remote host, please contact IBM InfoSphere Guardium Technical Support.
  • If the message has reached the remote host, but the Event Monitor is unable to process it, please verify that the message template is correct for that specific Event Monitor or contact the vendor the Event Monitor.

Message Template Parameters:

Variable
Description
%%ruleDescription The rule description from the policy rule definition
%%category Category from the rule definition
%%classification Classification from the rule definition
%%severity Severity from the rule definition
%%ruleID The rule number from the rule definition
%%sessionStart Session start time (login time)
%%serverType The database server type
%%clientIP Client IP address
%%serverIP Server IP address
%%clientPort Client port number
%%serverPort Server port number
%%netProtoco Network protocol - for K-TAP on Oracle, this may display as either IPC or BEQ
%%DBProtocol Database protocol
%%DBProtocolVersion Database protocol version
%%DBUser Database user name
%%AppUserName Application user name
%%SourceProgram Source program name
%%AuthorizationCod Authorization code
%%requestType Request type
%%lastError Last error description; available only when a SQL error request triggering an exception rule contains a last error description field
%%SQLString SQL string (if any)
%%receiptTimeMills Numeric representing the time when the alert occurred, in MilliSeconds since the fixed date or Jan 1 1900
%%receiptTime Timestamp representing the time when the alert occurred
%%sessionStartMills Numeric representing the start of the session where the alert occurred, in MilliSeconds since the fixed date of Jan 1 1900
%%violationID Numeric representing the POLICY_VIOLATION_LOG_ID of this alert in GDM_POLICY_VIOLATION_LOG (this is the same as the Violation Log ID in the Policy Violations/ Incident Management report)

Default format of the global profile Message template:

Alert based on rule ID %%ruleDescription|Category: %%category|Classification:%%classification|Severity %%severity|Rule # %%ruleID [%%ruleDescription ]|Request Info: [Session start: %%sessionStart]|Server Type: %%serverType|Client IP %%clientIP|ServerIP:%%serverIP|Client PORT: %%clientPort|Server Port: %%serverPort|Net Protocol:%%netProtocol|DB Protocol: %%DBProtocol|DB Protocol Version: %%DBProtocolVersion|DBUser: %%DBUser|Application User Name%%AppUserName|Source Program:%%SourceProgram|Authorization Code: %%AuthorizationCode|Request Type:%%requestType|Last Error: %%lastError|SQL: %%SQLString|To add to baseline:%%addBaselineConstruct

Example formats:

The following are some example formats for a few SIEM products. Please validate these with your SIEM vendor, as these may have changed by the vendor. If you are copying and pasting from these templates, please ensure that any line break is removed.

Sensage

This is the suggested format for Sensage. Please verify with the vendor for any changes. This format deletes two fields used for internal information %%AuthorizationCode & %%addBaselineConstructAlso and places %%SQLString at the end of the message for easy truncation, if necessary.

Alert based on rule ID %%ruleDescription|Category: %%category|Classification:%%classification|Severity %%severity|Rule # %%ruleID [%%ruleDescription ]|Request Info: [Session start: %%sessionStart]|Server Type: %%serverType|Client IP %%clientIP|ServerIP:%%serverIP|Client PORT: %%clientPort|Server Port: %%serverPort|Net Protocol:%%netProtocol|DB Protocol: %%DBProtocol|DB Protocol Version: %%DBProtocolVersion|DBUser: %%DBUser|Application User Name%%AppUserName|Source Program:%%SourceProgram|Request Type: %%requestType|Last Error: %%lastError|SQL:%%SQLString

Arcsight:

CEF:0|Guardium|Guardium|7.0|%%ruleID|%%ruleDescription|5|rt=%%receiptTimeMills cs1=%%severity cs1Label=Severity cs2=%%serverType cs2Label=Server Type cs3=%%classification cs3Label=Classification cat=%%category app=%%DBProtocol cs4=%%DBProtocolVersion cs4Label=DB Protocol Version suser=%%AppUserName sproc=%%SourceProgram act=%%requestType start=%%sessionStartMills externalId=%%violationID duser=%%DBUser dst=%%serverIP dpt=%%serverPort src=%%clientIP spt=%%clientPort proto=%%netProtocol msg=%%SQLString

EnVision:

%GUARDIUM|Alert based on rule ID: %%ruleDescription |Category: %%category |Classification: %%classification |Severity: %%severity |Rule #: %%ruleID | Rule Description:%%ruleDescription |Request Info: Session start: %%sessionStart |Server Type:%%serverType | Client IP: %clientIP |ServerIP: %%serverIP |Client PORT: %%clientPort|Server Port: %%serverPort |Net Protocol: %%netProtocol |DB Protocol: %%DBProtocol |DB Protocol Version: %%DBProtocolVersion |DB User: %%DBUser | Source Program:%%SourceProgram |Authorization Code: %%AuthorizationCode |Request Type:%%requestType |Last Error: %%lastError |SQL: %%SQLString

Document information

More support for: IBM Security Guardium

Software version: 7.0, 8.0

Operating system(s): Linux

Reference #: 1515374

Modified date: 13 June 2017