Integration into SIEM Solutions Through Syslog Forwarding
Events that arrive in a repository can be passed on to SIEM systems that know how to receive, store and index them for analysis. This is known as audit data forwarding and is configured on a per-repository basis.
Turning Forwarding On and Off
Forwarding has a dedicated group of settings in the properties of a repository. Use the Enable forwarding option to turn it on and off for the repository you are working with, and click Apply to confirm your changes.
From the moment you turn forwarding on, events that arrive in the repository during real-time collection will be forwarded. Events that were already in the repository will be ignored. A status line in the forwarding properties shows you statistical information about the forwarding activities for the repository (see also How Event Forwarding Statistics Can Help You).
- Forwarding does not work for events that are gathered to repositories by InTrust gathering jobs as part of the workflow described in the Auditing Guide.
- If you want to forward events from a repository, make sure the repository name is no longer than 127 characters. Rename the repository if necessary.
- When you turn forwarding off, the effect is immediate. If the forwarding queue is not empty at the time this happens, it will remain like that while forwarding stays disabled. When the events in the queue become older than the retention period, they will be cleared.
- When you turn forwarding back on, any existing events in the forwarding queue are sent first; this mean your forwarding may begin with old events.
- In forwarded events, the When field contains GMT timestamps. Therefore, when you view the forwarded events on the receiving end (for example, in Splunk), the timestamps will be different from the results in Repository Viewer (which converts the value of When to local time automatically).
For details about repository options, see Managing Repositories.
Caution: Do not forward events to an InTrust server that listens for Syslog messages, because the messages will arrive with incorrect timestamps.
The following options control how forwarding is performed:
- Destination host
The host that listens for forwarded messages.
Which transport you want to use:
- UDP (can be faster, but reception is not verified)
- TCP (can be slower, but verifies reception)
- TLS-secured TCP (the most secure option, but works only in environments using TLS)
The port that the destination host uses for listening.
- Message encoding
The Splunk JSON and Syslog RFC 5424 formats use UTF-8. For other formats, you can select the encoding.
- Message filtering
If you need only a subset of the repository data, you can specify filters, which are really Repository Viewer searches. If you want to add or modify a filter, open Repository Viewer and make your changes. Your filter will be available the next time you configure forwarding. For details about working with searches, see Searching for Events in Repository Viewer. Using searches as filters has some important implications; see Event Filtering for details.
- Message format
The format in which data is expected on the receiving end; see Data Conversion Formats for details. This setting has no effect on data that arrives from Syslog devices; such data is forwarded unchanged. Only collected Windows event log data is converted to the specified format.
Data Conversion Formats
SIEM appliances expect data in a specific format. For forwarding to be useful, InTrust must convert the contents of the repository to that format before passing them on.
The following output formats are supported:
- Dell SecureWorks
This is synonymous with the Snare format, transferred over Syslog.
- IBM QRadar
- Tibco LogLogic
- Splunk JSON
The JSON is transferred over Syslog.
- Syslog RFC 5424
This message format is supported by multiple SIEM systems alongside their proprietary formats.
NOTE: When InTrust forwards data in RFC 5424 format, it includes IANA private enterprise number 3973 (registered to Quest Software Inc.) in the messages.
See the following topics for details about setting up integration with specific systems:
You can add support for other formats by providing custom format definition scripts.
To specify a different format, select the Custom Format item in the Message format drop-down list, click Edit, and use the editor that opens.
Note the following specifics:
- Your custom formatting code must implement the Transform() function. This function will be used as the entry point by the event forwarding engine. It takes an event object and its sequential number as arguments, and it returns a string.
- The custom message format will be applied only to the repository you are working with, and will not be replicated to other repositories.
- Switching from the custom format to the predefined format resets the custom format script to its default state. Back up your custom format script in a file.
- A сustom format script has significantly lower performance than an equivalent built-in predefined formatter. For example, the default format script, provided as the template for custom format scripts, forwards events at only about 1/30th the rate of the predefined Dell SecureWorks formatter.
For more details about formatting custom messages, study the default formatting script provided in the built-in editor. This is a valid script that replicates the functionality of the predefined SecureWorks forwarding component in InTrust. To change the message format, either edit the Format variable or write your own custom script using this default script as an example. In the Format string, event field names enclosed in percent signs (%) will be replaced by their values.
For details about event objects and the InTrust object model in general, see Customization Kit.
Recommended Event Forwarding Scenario
For best results, consider using a dedicated repository for event forwarding. You can create the repository in advance in the Storage view of InTrust Deployment Manager. Alternatively, you can select to create a new repository when you create your new forwarding-oriented collection in the Collections view.
To make sure your repository doesn't waste disk space, set up daily cleanup for it. Cleanup is configured in the repository properties in the Storage view.