Advanced Event Source Settings

Multi-Domain Environments

If you have multiple domains in your environment, it is important that you specify a default domain for all event sources. This setting ensures that SIEM (InsightIDR) knows which domain should be used to attribute users to, particularly when that data is not provided in the event log. A default domain can be set for all event sources when configuring user attribution settings. To use a different domain for a specific event source, you can customize it directly in the event source’s configuration settings.

Rapid7 Encryption Certificate

When using TCP to send event source data by syslog, you can also choose to encrypt that data. When configuring an event source, choose TCP under collection methods and select the “Download Certificate” button. The certification is called Rapid7CA.pem and will allow SIEM (InsightIDR) and the event source to “trust” each other during log forwarding.

Rapid7 Recommends importing the certificate file on the same machine as the vendor or application you are connecting to SIEM (InsightIDR) as an event source. Use your administrative tool or vendor in order for your machine to ingest the certificate.

The certificate file contains two keys: a public key for your organization, and the Rapid7 key, which created the org-key.

Inactivity Timeout Threshold

This setting applies only to DHCP and VPN event sources. The inactivity Timeout Threshold setting allows you to specify in minutes how long an event source should be inactive before it enters an error state.

Active Failover Partner

If you have two DHCP servers configured in an active/passive relationship, you can specify the active partner.

Unparsed Logs

Learn about how unparsed logs affect your event source.

Attribution Source

In SIEM (InsightIDR), attribution refers to the attempts the system makes to identify which assets, accounts, and users are involved in the collected log activity. For example, when an event log states that the activity was performed by the account jdoe, SIEM (InsightIDR) uses previously collected information from other event sources to determine whether that account is associated with the user Jane Doe or John Doe.

Attribution source can be set for all event sources when configuring user attribution settings. To use a different attribution source for a specific event source, you can customize it directly in the event source’s configuration settings.

Filter Response Data

For event sources that receive high volumes of data, you can add a filter to capture only the specific items you need.

This filter setting is optional and is only available for cloud collection method event sources. If you leave this field blank, all data is collected without filtering.

Add a Filter

To add a filter to a new event source:

1. From the Command Platform main menu, go to Data Connectors > Data Collectors.
2. Go to the Event Sources tab, then click Add Event Source.
3. Configure the event source as required.
4. In the Alert filter field, enter a JSON filter configuration to specify which items to include. Only items that match your filter criteria will be included in the data collected by the event source.
5. Click Save.

To add a filter to an existing event source:

1. From the Command Platform main menu, go to Data Connectors > Data Collectors.
2. Go to the Event Sources tab.
3. Find the event source you want to update, and click Edit. This opens the configuration panel.
4. In the Alert filter field, enter a JSON filter configuration to specify which items to include. Only items that match your filter criteria will be included in the data collected by the event source.
5. Click Save.

Filter Configuration Format

Your filter configuration should be a valid JSON string following one of these formats:

Single Filter Rule

{"value": ["high"], "fields": ["severity"]}

Multiple Filter Rules

[
  {"value": ["high"], "fields": ["severity"]},
  {"value":["@example.com"],"fields":["userPrincipalName"]}
]

Filter Rule Structure

Each filter rule must contain:

• value (required): A list of strings to search for in the response data
• fields (optional): A list of field paths to search in, or omit/set to null to search all fields

Best Practices

Follow these best practices when you create your filter configuration:

• Leave the filter empty to collect all data. If you don’t provide any filter configuration and the field contains an empty string, all items are collected without filtering.

• Substring matching is used. A filter value will match if it appears anywhere within a field value. For example, "example.com" will match "user@example.com" or "admin@example.com".

• Nested fields are supported. Use dot notation to access nested fields (for example, "user.email"), and the filter will recursively extract all string values from that location.

• Use specific field paths for better performance. When you know which fields to filter on, specify them explicitly (for example, ["severity"], ["user.email"]) rather than searching all fields.

• The filter uses OR logic. If you specify multiple filter rules, an item will be included if it matches any of the rules.

• Matching is case-insensitive. Your filter values will match regardless of case. For example, "high" will match "HIGH", "High", or "high".

Filter Examples

Example 1: Filter by Severity

To include only high and critical severity alerts, use this JSON format:

{"value": ["high", "critical"], "fields": ["severity"]}

This filter includes only the alerts where the Severity field contains “high” or “critical”.

Example 2: Filter by User Email

To include only related to a specific user, use this JSON format:

{"value": ["user@example.com"], "fields": ["userPrincipalName"]}

In this example, only alerts where the userPrincipalName field contains “user@example.com” will be included.

Example 3: Filter by Multiple Criteria

Include alerts matching multiple different criteria:

[
  {"value": ["user@example.com"], "fields": ["userPrincipalName"]},
  {"value": ["critical"], "fields": ["severity"]}
]

This will include alerts if they contain “user@example.com” in the userPrincipalName field OR if they contain “critical” in the severity field.

Example 4: Search Across All Fields

Include only items containing “malware” anywhere in their data:

{"value": ["malware"], "fields": null}

This searches the entire data structure for the string “malware”.

Example 5: Filter by Nested Field

Include only items based on a nested field path:

{"value": ["suspicious"], "fields": ["category.subCategory"]}

This will navigate to the nested field and include only items with matching values found there.

How Field Matching Works

When you specify a field path, the filter navigates to that location in the data and extracts all string values within that structure, including any nested fields.

• Simple string values are extracted and matched directly
• Objects have all their string values recursively extracted
• Arrays have all their string values recursively extracted
• Nested structures are fully traversed to find all strings