Before You Begin

​

Ensure that you have prepared your Azure Workspace. You must complete this step before you can send events through the Microsoft Sentinel Destination to the Microsoft Sentinel SIEM.

If you do not yet have Microsoft Sentinel up and running, please join us on Cribl’s Community Slack at https://cribl‑community.slack.com/ and let us know; very likely, a wise goat will offer time-saving suggestions.

Event Types

​

Of the many event types (also called “tables”) present in the Microsoft ecosystem, this topic provides what you need to get started quickly with any or all of the following four:

• CommonSecurityLog
• SecurityEvent
• Syslog
• WindowsEvent

We’ll also explain how you can bring additional event types into your deployment.

To plan your Cribl/Sentinel integration, start by deciding which event types (a.k.a. tables) you want to send to Sentinel.

If the answer is “more than one,” you should use an Output Router and multiple Destinations. You’ll configure one Destination per table, but a single URL will ingest all the data. The Output Router can then route a given event type to the correct Destination.

The four event types above belong to the much larger set of event types that the Azure Monitor provides in its Logs Ingestion API. You can work with any of these event types as you would the four types above. See the Appendix below for the full list.

Creating Data Collection Rules

​

The Sentinel SIEM can have multiple ingestion endpoints, called Data Collection Endpoints (DCEs). In turn, each DCE can have multiple Data Collection Rules (DCRs). A DCR can dictate the structure of the data flowing into one table, or multiple tables.

Ensure that the field names in your data match the schema defined in the Data Collection Rule (DCR) for Microsoft Sentinel. The DCR specifies the expected structure, including field names and types. Mismatched field names can result in dropped events.

Cribl’s template is an example of a custom DCR that sends data to four different tables, one for each of the four event types enumerated above.

Alternatively, you could populate one table with different kinds of data. For example, you could define a table for the Syslog event type, and then create a separate DCR for Windows, Linux, and Mac system logs, respectively, all of which would populate that single table.

Besides the Azure documentation, you can study the Cribl template to understand how DCRs are structured. For example, each table’s columns are defined in a sub-element of the resources > properties > streamDeclarations element. The dataFlows element – at the same level as streamDeclarations – specifies the table that a given type of data should populate, via the outputStream sub-element. It also specifies the query that will translate incoming fields into values in the table’s columns, via the transformKql sub-element.

Read more about DCRs in the Microsoft Sentinel documentation.

Custom DCR Template Errors

​

If you get an error such as Table for output stream 'Microsoft-CommonSecurityLog' is not available for destination 'logAnalyticsWorkspace'), it is probably because you don’t have Sentinel assigned to your Log Analytics workspace. Please add Microsoft Sentinel to your Log Analytics Workspace to correct this error.

Obtaining Your URL

​

To configure your Cribl Stream Microsoft Sentinel Destination, you must know the ingestion URL to send data to. This is in General Settings > Endpoint configuration, where you choose between the URL and ID options. The ID option is just a somewhat roundabout method for generating the URL – in this section, we’ll ignore ID in favor of an easier way to obtain the URL.

In your Azure portal:

1. Navigate to the Azure Resource Graph Explorer. The Resource Graph Explorer queries across your whole Azure cloud.

2. Run the following query in the Explorer to list all your Data Collection Endpoints (DCEs) and Data Collection Rules (DCRs).

   Resources
   | where type =~ 'microsoft.insights/datacollectionrules'
   | mv-expand Streams= properties['dataFlows']
   | project name, id, DCE = tostring(properties['dataCollectionEndpointId']), ImmutableId = properties['immutableId'], StreamName = Streams['streams'][0]
    | join kind=leftouter (Resources
   | where type =~ 'microsoft.insights/datacollectionendpoints'
   | project name,  DCE = tostring(id), endpoint = properties['logsIngestion']['endpoint']) on DCE
   | project name, StreamName, Endpoint = strcat(endpoint, '/dataCollectionRules/',ImmutableId,'/streams/',StreamName,'?api-version=2021-11-01-preview')

   Copy

3. If you are using all four of the tables mentioned above, the output should look something like this:

   

   

   Problems with Resource Graph Explorer Queries

   ​

   If you get zero returns or the query returns unexpected data, be sure you have properly prepared your Azure workspace. This step is a preprequisite.

4. Click a DCE of interest to open its Details drawer.

5. Find the Endpoint field and click its Copy to clipboard icon.

   • Microsoft defines the Endpoint URI as follows:

   {Data Collection Endpoint URI}/dataCollectionRules/{DCR Immutable ID}/streams/{Stream Name}?api-version=2021-11-01-preview

   Copy

6. In your Cribl Stream Microsoft Sentinel Destination, paste the copied Endpoint URI into the URL field.

Configuring Your Destinations, Continued

​

In most respects, Cribl Stream’s Microsoft Sentinel and Webhook Destinations are alike. This section notes the few differences, while highlighting key points about configuring Microsoft Sentinel Destinations.

In Microsoft Sentinel Destination, General Settings > Authentication offers fewer options than the Webhook Destination. This is because OAuth is Cribl Stream’s only supported option for Microsoft Sentinel, for now. Some fields that present in other Destinations always have the same values for Microsoft Sentinel, and Cribl Stream fills those out for you without exposing them in the UI.

The Microsoft Sentinel Destination does not support client-side TLS.

The value for Advanced Settings > Max body size (KB) value defaults to 1000. The intent here is to keep request bodies from exceeding Microsoft Sentinel’s limit of 1 MB, meaning 1024 KB including headers. If necessary, you can lower Max body size (KB) even further.

Appendix: Azure Monitor Logs Ingestion API Event Types

​

Here’s the whole list – note that this includes event types for AWS and for Google Cloud Platform (GCP).