InTrust 11.4.2 - Integration into SIEM Solutions Through Event Forwarding

Event Filtering

You can select one or more filters for forwarding your repository contents. InTrust will forward events that match any of the filters you select. Remember that each filter you add broadens the scope instead of narrowing it.

To manage the set of filters, click the button next to the list of current filters. In the filter browser that opens, select the check boxes next to the filters you need. Avoid selecting more than just a few filters, because that can adversely affect performance. A better approach is to create a dedicated Repository Viewer search with the right options.

Also note the following details:

• Searches that are currently used for event filtering are marked with special icons to help prevent accidental modification. In addition, if you try to edit such a search, you are prompted to confirm this. Deleting a filtering search (or a search folder that contains it) is disallowed. Scheduling reports on filtering searches is also disallowed.
• If you want to create a forwarding filter from a regular search or from another filter, it is convenient to right-click the search and select Make a Copy. This way, you avoid the risk of making unwanted changes to the original search.
• Repository Viewer searches support grouping and sorting, but these settings have no meaning for message forwarding and will be ignored.
• If you edit a search that is already used as a filter, your changes will affect the filtering. Consider making dedicated searches for filtering purposes.
• If a filtering search is deleted, forwarding configuration becomes invalid for the repositories that used it, and forwarding stops for these repositories. This is a deliberate design choice to prevent incomplete data from being forwarded. The deleted filter is listed as invalid for the repositories. To resolve this situation:
  • In the list of repositories, look for repositories that are marked with an exclamation mark icon.
  • For each affected repository, remove the invalid filter from the filter list. If necessary, you can still view the location that the search used to be at. For that, open the filter browser.
• If you use predefined searches as a filters, note that changes made to them in Repository Viewer are not applied.
• Be careful when specifying the time range for the searches that will be used as filters. If you set the wrong type of range, this can effectively turn off message forwarding. For example, if you set a time range based on the “Last” keyword, no matches will ever occur. You should not specify a time range for a filtering search.

Choosing Event Filters

Generally, you don't want to forward all the data that you collect. If you are targeting a SIEM system, you are likely to concentrate on specific activities to reduce costs and level of noise and make threat hunting and security analysis as efficient as possible.

For these exact purposes, InTrust provides a set of Repository Viewer searches designed to work as event forwarding filters (they are in fact better used as filters). They are available in the Threat Hunting | Windows | Native OS Logs Telemetry search folder. These filters accommodate knowledge from important sources such as the following:

• MITRE recommendations
  https://github.com/MalwareArchaeology/ATTACK
• NSA recommendations
  https://github.com/nsacyber/Event-Forwarding-Guidance/tree/master/Events
• Ultimate Windows Security website
  https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/

You can combine these filters as you see fit or select all of them to fully cover your infrastructure security while still retaining focus.

Example: Set Up Forwarding to SecureWorks

Suppose SecureWorks is already in place in your environment and is used for tracking the operation of Syslog-enabled systems. For Windows network auditing, you use InTrust and Change Auditor. You would like to extend the scope of your SecureWorks coverage to include suspicious user activity in the Windows network.

Make Sure You Have the Data

To capture suspicious administrative activity, you would need to look at the following:

• User session events provided by InTrust
  These events provide a deep insight into user logons, logoffs and sessions.
• Change Auditor for Active Directory log
  This log provides fine-grained information about all changes to Active Directory.

Confirm that these data sources are used by the collections that work with your repository.

Configure the Forwarding

You need to enable forwarding for the repository that you have chosen for this purpose. Go to the properties of the repository and, on the Forwarding tab, select Enable forwarding and specify where the messages should go.

After you have completed the collection setup, confirm that the forwarding is really working. Wait a few minutes for the new settings to take effect. After that, log on to some of the computers that InTrust is watching, and try to make Active Directory changes. Then check on the SecureWorks appliance whether it has registered your activity.

Example: Set Up Forwarding to Splunk

Suppose Splunk is deployed in your environment for analyzing Windows security events. You would like to use InTrust as the forwarding mechanism. The data you need goes to a repository that is set aside specifically for forwarding purposes. The repository has only Windows Security log data.

Get Splunk Ready

You need to perform some preparatory procedures in Splunk. An example of the configuration is described below, but it may differ for your Splunk deployment.

Step 1: Define a Source Type

To make sure that event fields are recognized correctly, make a specialized source type for incoming InTrust data. If you want to use the Splunk UI for this, configure the options as follows (the last three options are set up in the Advanced group):

If you want to skip configuration through the Splunk UI, include the following snippet in the <Splunk_installation_folder>\etc\apps\search\local\props.conf file:

[InTrust]
DATETIME_CONFIG =
INDEXED_EXTRACTIONS = json
NO_BINARY_CHECK = true
SHOULD_LINEMERGE = false
category = Structured
pulldown_type = 1

Step 2: Configure a Network Input

In Splunk, add a new TCP or UDP network input and apply your new source type to it. Configure the network input as necessary, but make sure you set up the following:

1. The protocol must match the one specified in your forwarding configuration: either TCP or UDP.
2. Specify the source type you defined earlier; in this example, it is InTrust.

Make a note of the port number where Splunk will listen for forwarded traffic. You are going to need it for InTrust forwarding configuration.

If you want to skip configuration through the Splunk UI, include a snippet like the following in the <Splunk_installation_folder>\etc\apps\search\local\inputs.conf file:

[tcp://514]
connection_host = ip
index = main
sourcetype = InTrust

If you are forwarding events over UDP, the first line in the snippet above should be [udp://514].

For details about the various ways that you can add network inputs in Splunk, see the "Get data from TCP and UDP ports" article in the documentation of your version of Splunk.

Step 3 (Conditional): Restart Splunk

If you made your changes by editing configuration files, restart Splunk to apply them; use either the splunk stop and splunk start commands or the Restart action in the Splunk UI. For details, see the Splunk documentation.

Configure the Forwarding

To send data to Splunk, enable forwarding for the repository with the necessary data. Go to the properties of the repository and, on the Forwarding tab, select Enable forwarding and specify where the data should go.

Select Splunk JSON as the message format, and specify the correct Splunk host name and the port where the forwarded data is expected.

After you have completed the collection setup, confirm that the forwarding is really working. Wait a few minutes for the new settings to take effect. After that, log on to some of the computers that InTrust is watching, and try to make Active Directory changes. Then open Splunk and check whether your activity has registered.

Example: Mirroring InTrust Real-Time Alerts in SIEM

InTrust real-time alerts, which are produced by real-time monitoring rules, cannot be directly transferred to a SIEM system. However, InTrust provides a way to get real-time alert data in event log form, which is compliant with SIEM technology. What you need to do is make your rules use Event Log Recipient as their notification destination, as described in Configuring Notification Groups and Recipients.

After you have set up event log-based notification as instructed in that topic, take the following steps in InTrust Deployment Manager:

1. Create a collection that includes all of your InTrust servers, because generally there is no telling which server processes which rules (unless you have a strict convention about this).
2. Select only the InTrust Server Log data source for the collection.
3. Enable event forwarding for the repository you use for the collection.
4. Apply the InTrust Alerts | Alert triggered forwarding filter. This filter skips everything except event ID 17408, which is the rule match event.

When you are done, your SIEM solution will receive the equivalent of InTrust real-time alerts, with all the benefits of InTrust event correlation and none of the event log noise.