Overview

Snare Central (Reflector) can forward log data to Microsoft Sentinel using the Logs Ingestion API in Azure Monitor, enabling seamless and customizable integration with the Microsoft security stack.

By leveraging Snare Reflector’s powerful filtering, transformation, and remapping capabilities, organizations gain fine-grained control over what data is sent, how it is structured, and which Sentinel tables it reaches, while ensuring that logs are sent in the correct format for the target Log Analytics Workspace tables, minimizing or even eliminating the need for post-ingestion transformation.

This guide outlines the steps to set up log delivery from Snare Reflector to Microsoft Sentinel using the Logs Ingestion API. It covers how to define the necessary Azure components and configure Snare Reflector to forward logs into your Log Analytics Workspace, where Sentinel can access and analyze them for cyber-threat detection, investigation, response and proactive hunting.

Open

Sending Logs To Microsoft Sentinel Overview

Azure Components Preparation and Setup

To enable log forwarding from Snare Reflector to Microsoft Sentinel via the Logs Ingestion API, a set of Azure components must first be configured. These components define how data is received, where it is stored, and how access is secured.

The Logs Ingestion API in Azure Monitor allows external applications like Snare Reflector to send data directly to a Log Analytics Workspace using a secure REST API. In this setup, Snare Reflector will act as the sender, pushing processed log data into a table that Sentinel can query and analyze.

This section will walk you through preparing the required Azure resources using the Azure portal.

You will configure the following components:

1. Microsoft Entra Application – Authenticates Snare Reflector against the Logs Ingestion API.

2. Data Collection Endpoint (DCE) – Serves as the HTTP endpoint to receive data.

3. Data Collection Rule (DCR) – Routes incoming logs from the DCE to the appropriate table.

Once these components are in place, you'll be ready to connect Snare Reflector and begin sending log data to Sentinel using the API.

Create Microsoft Entra Application

First, to authenticate Snare Reflector against the Logs Ingestion API, you'll need to register a Microsoft Entra application. This application will be used to securely authenticate API requests when sending logs to Azure Monitor.

• Register a new application in Microsoft Entra ID.

• Take note of the App Name (Name used in the Register an application.)

• Create a client secret for authentication.

• Record the following values for later use in Snare Reflector’s configuration:

  • Application (client) ID for Snare configuration entry: Client ID

  • Directory (tenant) ID for Snare configuration entry: Tenant ID

  • Client secret value for Snare configuration entry: Client Secret

Follow the detailed steps here: Create a Microsoft Entra ID application and client secret

Create Data Collection Endpoint (DCE)

Next, create a Data Collection Endpoint (DCE) to act as the HTTP endpoint that will receive log data from Snare Reflector. This is the URL that Snare will send data to via the Logs Ingestion API.

• In the Azure portal, create a new Data Collection Endpoint.

• Select the same region as your Log Analytics Workspace.

• Use a clear and recognizable name for the endpoint (e.g., snare-dce).

• After creation, take note of the Log Ingestion URI value, which will be used in Snare Reflector for IP/Hostname.

Follow the detailed steps here: Create Data Collection Endpoint

Create a Data Collection Rule (DCR)

The Data Collection Rule (DCR) defines how incoming data is processed and routed to your Log Analytics Workspace.

When configuring your DCR, you have two main options where your logs can be sent depending on your needs.

1. Send log data to a Custom Table

Use this option if you want full control over your log schema. This approach offers flexibility to define fields tailored to your specific log formats.

• Create a custom table (e.g., Custom-SnareLogs_CL) within your Log Analytics Workspace.

• The DCR you create will map incoming data to this custom table.

Follow the detailed steps here: Create new table in Log Analytics workspace

2. Send log data to a Supported Native Table

Use this option if you want to send logs directly to one of the azure native tables officially supported by the Logs Ingestion API.

• Create/Load a DCR ARM Template: DCR ARM Template

• Define the native columns of the target table. e.g. the DCR ARM Template windowsEventColumns

• Define the TransformKql of the target table e.g. the DCR ARM Template windowsEventTransformKql

• Define the streamDeclarations

• Define the dataFlows: destinations, outputStream, streams, transformKql

• To send data to a native table, specify the outputStream in the DCR as Microsoft-<TableName> (e.g., Microsoft-WindowsEvent).

Follow the detailed steps here: Appendix F - Microsoft Sentinel HTTP Log Delivery - DCR ARM Template

Collect information from the DCR

After creating the Data Collection Rule (DCR), you’ll need to gather key information to allow Snare Reflector to send data to Azure.

• Take note of the the following values:

  • immutableId for Snare configuration entry: DCR Immutable ID

  • dataFlows streams for Snare configuration entry: DCR Stream Name

Follow the detailed steps here: Collect information from the DCR

Assign permission to the DCR

The final step is to grant the application access to use the Data Collection Rule (DCR). Once permission is assigned, any client using the correct Application (Client) ID and secret can send data to the designated Data Collection Endpoint (DCE) and have it processed by the DCR.

• Add role assignment to Monitoring Metrics Publisher

• In the Select members use the App Name you use in Microsoft Entra App registration step.

Follow the detailed steps here: Assign permission to the DCR or the Step 7 in Creating a Data Collection Rule for Snare Central’s HTTP Log Delivery to Microsoft Sentinel

Snare Reflector Setup for Microsoft Sentinel Destination

Following the completion of the Azure Components Preparation and Setup, which included registering the Microsoft Entra application, configuring the Data Collection Endpoint (DCE), and defining the Data Collection Rule (DCR), we now move forward with configuring Snare Reflector Destination to send log data directly to Microsoft Sentinel via the Logs Ingestion API.

Destination Configuration

To configure Snare Reflector to send logs to Microsoft Sentinel, follow these steps:

• Navigate to Reflector UI and open Configure Destination page.

Open

• Select + Add Destination tab on the Reflector > Configure Destination page.

Open

• Define the following destination details:

Open

• Click TEST CONNECTION button to validate if the destination is properly configured and can established a proper connection.

Open

• Once the Test Connection were successful, click ADD DESTINATION then select ADD AND RESTART to save the new destination and restart Snare Reflector services to apply the changes. The configured Microsoft Sentinel destination will now show in the Destinations list and will start sending data (if enabled).

Open

Remapping Template

When sending data to HTTP-based destination format like Microsoft Sentinel, an additional layer of transformation is available using Remapping Template through Fields Remapping. This feature allows Snare log fields to be further refined and mapped to the specific schema expected by the target platform, ensuring compatibility and usability within the receiving system.

Field remapping ensures that log data forwarded from Snare Reflector is correctly understood, searchable, and actionable by the receiving system. This is especially important when forwarding to platforms that require specific schemas or follow normalization models.

To use this feature, user needs to create a Field Remapping(s), there are 3 Field Remapping templates for Microsoft Sentinel provided to help you get started quickly.

Detailed steps on how to create/modify Remapping Template can be found in this Fields Remapping user guide link: Fields Remapping.

Different Destination Configuration for Microsoft Sentinel

When setting up Snare Reflector to send logs to Microsoft Sentinel, there are several configuration options available depending on the scale of your deployment and your logging requirements. Each setup approach offers flexibility in how you manage and route log data to Azure Log Analytics Workspaces for processing in Sentinel.

In this section, we will explore three different setup configurations for integrating Snare Reflector with Microsoft Sentinel:

1. Single DCE and Single DCR with Multiple Streams and Output Tables

Open

• Setup Overview: A single Data Collection Endpoint (DCE) is used to receive log data, and a single Data Collection Rule (DCR) handles multiple streams and routes them to different output tables within your Log Analytics Workspace.

• Best for: Simplicity in management, but this comes with complexity in DCR definitions. Since the DCR is responsible for multiple streams and tables, the complexity increases as more streams are added, requiring careful design of data transformations to match the schema of different tables. Handling multiple streams within a single DCR may result in higher management overhead as the DCR grows in size and complexity.

• Key Considerations:

  • Centralized configuration: Only one DCR needs to be maintained for all streams, which could be more convenient in terms of high-level oversight.

  • Suitable for low to moderate load environments, but complexity increases with more streams.

2. Single DCE and Multiple DCRs, Each Handling One Stream and Output Table

Open

• Setup Overview: In this configuration, a single DCE is used, but multiple DCRs are deployed, with each one handling a single stream and routing it to a specific output table.

• Best for: Easier DCR maintenance, as each DCR only needs to handle one stream and one output table. While this may not necessarily provide performance advantages, it does offer a more modular and manageable setup. With multiple DCRs in place, it becomes easier to update or troubleshoot each stream individually without the complexity of a larger, all-in-one DCR configuration.

• Key Considerations:

  • Simplified DCR management: Each DCR is simpler to define and maintain, as it deals with only one stream and table although this requires managing multiple DCRs in total.

  • No inherent performance boost: While this configuration may offer easier maintenance, there’s no significant performance advantage, as the log load is still handled by the same DCE.

  • Suitable for environments where modularity and easier troubleshooting are preferred.

3. Multiple DCEs, Each Handling One or More DCRs Depending on Load

Open

• Setup Overview: In this configuration, multiple DCEs are deployed to handle higher log loads, and each DCE can have one or more DCRs based on the required throughput. The idea is to distribute the load to prevent a single DCE from becoming a bottleneck.

• Best for: Managing high log ingestion volumes, particularly in environments with significant log traffic. This setup helps prevent a single DCE from becoming a bottleneck by distributing the log load across multiple DCEs, thereby enhancing scalability and reducing latency.

• Key Considerations:

  • Improved scalability: Distributing the load across multiple DCEs ensures that log ingestion performance remains optimal, even with high throughput.

  • Prevents bottlenecks: Helps mitigate the risk of a single DCE slowing down or becoming overwhelmed, ensuring consistent performance even with growing log data.

  • Suitable for environments with high log volumes or dynamic workloads where performance is critical.

Troubleshooting Guide

When configuring a Snare Reflector Destination to send logs to Microsoft Sentinel, various issues may arise during the setup. This guide covers the common errors that you may encounter:

• Cannot feed data to the Sentinel instance: 400

Open

Typically cause by incorrect DCR Stream Name.

• Cannot feed data to the Sentinel instance: 404

Open

Typically cause by incorrect DCR Immutable ID.

• Could not get sentinel bearer token

Open

Typically cause by incorrect TenantID and/or ClientID and/or Client Secret.

• Cannot connect to Sentinel instance:Post "https://…: no such host

Open

Typically cause by incorrect or invalid IP/Hostname.

• Cannot connect to Sentinel instance:Post "https://…: context deadline exceeded

Open

Typically cause by incorrect or invalid IP/Hostname and/or Port or internet connectivity issue.

• Remapping Template is invalid

Open

Typically cause by invalid Remapping Template.