Sending seaudit logs to a remote SIEM solution to a syslog port causes data to be displayed as unformatted
search cancel

Sending seaudit logs to a remote SIEM solution to a syslog port causes data to be displayed as unformatted

book

Article ID: 236716

calendar_today

Updated On:

Products

CA Privileged Identity Management Endpoint (PIM) CA Privileged Access Manager - Server Control (PAMSC)

Issue/Introduction

When trying to send logs to a remote SIEM (Security Information and Event Management) server to a syslog log collector or directly to a remote syslog server from ControlMinder, PIM or PAM SC, data are received, but they appear in an unformatted data.

Lines displayed are similar to the following

"x`\\ri\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0002 !\\x96a\\u0000\\u0000\\u0000\\u0003\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000"

Environment

CA ControlMinder 12.8, CA PIM all versions, CA PAM SC all versions

Cause

From selorgd running in ControlMinder, PIM or PAM SC it is possible to send events to a remote system formatted as seaudit events. The remote system must be running then the selogrcd log collector utility to receive the logs and it will write them in the remote system in seaudit format.

Several other options for sending logs via mail or sending them to file are also possible. These options must be configured via the log route configuration file, selogrd.cfg and the corresponding options in configuration file seos.ini

A complete description of the options available for the routing daemon are described here:

The Audit Log Route Configuration File selogrd.cfg

and the options to configure seos.ini are documented in the following section of the endpoint documentation:

selogrd

Links provided are for PAM SC 14.1 but differences with previous versions of the product are negligible.

As part of the routing method, one may notice the possiblity of specifying a host, or syslog. Methods are mutually exclusive and it is not possible to combine them together. As such a selogrd.cfg routing configuration such as

Rule#1
host logs.example.com
syslog LOG_INFO
.

Will not work, because both access possibilities are exclusive of each other

Resolution

It is not possible to achieve directly the desired goal: selogrd cannot route directly its logs to a remote SIEM server in syslog format. They will always get to the final server unformatted.

It is possible to route the logs to a remote system running selogrcd, as specified in:

selogrcd Daemon Collect Audit Records

And it is also possible to collect the audit logs locally in syslog format

Configure an Endpoint to Send seaudit Logs to syslog

But the combination of both cannot be configured (e.g. sending audit logs natively to a remote SIEM system in syslog format).

There is a possible workaround for carrying out this operation, albeit it may require some filtering at the receiving SIEM host

  • Make sure that rsyslogd is running in the local endpoint where you are generating the logs
  • Create a selogrd.cfg routing file in the PAM SC/PIM machine to send data to local syslog in syslog format considering a certain log level (e.g.
    Rule#1
    syslog LOG_INFO
    .
    )
  • In rsyslog.cfg of the machine where the logs are being generated, configure required LOG level received from selogrd to be sent to the SIEM machine listening for syslog traffic (e.g. *.info       @log-receive.example.com). rsyslog rules are not exclusive, whereby you can still keep the rest of the rsyslog rules sending info messages to file or elsewhere
  • In the remote receiving machine specify to keep only those messages coming from the originating machine which contain the selogrd[ string and the remote server name. All selogrd messages received will contain both strings

This is an indirect way of achieving the goal, albeit it will cause regular info-type (or whatever category chosen) data traffic to be routed to the remote SIEM collector as well, not just the PAM SC/PIM audit one, and potentially also for unwanted traffic to be logged to local syslog if the info messages are also kept locally, but so far it is the only workaround available, short of using some other delivery method or of installing an endpoint with selogrcd in the remote SIEM system.