I see more-and-more people we work with starting to use Microsoft Sentinel.

Sentinel, whilst not exclusively a SIEM (it started life as a log aggregation platform), it is now beginning to compete well with other SIEM’s in the market that have grown from similar beginnings (Splunk, Elastic, etc.).

Given many organisations are still heavy Microsoft shops, it is not surprising. Exchange for email. Azure for cloud servers. Windows OS’s.

Last year I started to explore ingesting threat intelligence via the Sentinel TAXII Connector.

The following post introduces the types of Sentinel Rules and how they can be used (including with threat intelligence).

Sentinel Rule YAML Structure

First, it’s important to make the distinction in Sentinel between the rule and the query.

A rule is structured as yaml and contains information about the rule and the all important query used for detection and hunting.

For example, a rule has a name, description, query, etc.

Sentinel Hunting query example

Above is an example of an entire Sentinel hunting rule (available to download here).

Hunting vs. Detection Rules

Sentinel has two types of security content; hunting rules and detection rules.

The two are very similar, but it is important to understand the difference in there intended use.

A Detection Rule is typically used for automated analysis. It is designed to be run on a schedule (inc. real-time) to identify known security incidents.

Hunting queries are designed to be run on-demand, typically during a hunt.

What this means in terms of the structure for each type of rule is that Detection rules have time and threshold fields that can be defined to reduce noise on scheduled runs. e.g.

queryFrequency: 1d
queryPeriod: 1d
triggerOperator: gt
triggerThreshold: 0

Hunting Rules do not have such fields because they are not triggered by time or by a condition.

Here’s a good example of the difference between the two types of Rules.

And a useful style guide for an exhaustive reference of the fields required for each here.

The Sentinel content repository also contains directories with sample Rules of each type;

Let’s first look at the key fields that are used in both Detection and Hunting Rules…

1. Rule Metadata

name: Azure storage key enumeration
description: Listing of storage keys is an interesting operation in Azure which might expose additional secrets and PII to callers as well as granting access to VMs.

Fairly self explanatory, these fields add context to the rule which are used in the Sentinel UI.

2. Data Connectors

Microsoft Sentinel comes with several data connectors for Microsoft and non-Microsoft products to help get data in.

Sentinel data connectors

In the context of a Rule, this section defines the data sources the Rule should consider (search through on execution).

requiredDataConnectors:
  - connectorId: AzureActivity
    dataTypes:
      - AzureActivity

In the above example the Azure Activity connector is being used, and only data of the Azure Activity data type this connector produces should be searched (note, data connectors can produce one or more data types).

3. MITRE ATT&CK classification

MITRE ATT&CK provides a standard way to classify the behavior of a threat using tactics and techniques.

For example a query identifying phishing attempts can be classified as MITRE ATT&CK in a Sentinel Rule as;

tactics:
  - InitialAccess
relevantTechniques:
  - T1566

As you can see in this example, you need to specify a MITRE ATT&CK tactics and, optionally, a relevantTechniques that belongs to the selected tactic.

Tactics are passed by name (remove any whitespace, e.g. the tactic Initial Access becomes InitialAccess). Techniques can be defined using their ATT&CK ID.

Note, at the time of writing, sub-techniques are not supported.

Entity Mappings

Entity Mappings allow Sentinel to recognise entities and form the core of analysis which help you to investigate incidents effectively and efficiently (once the rule has triggered).

entityMappings:
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: IPCustomEntity
  - entityType: URL
    fieldMappings:
      - identifier: Url
        columnName: URLCustomEntity

Above, we are mapping fields returned by the query (Address and Url) to IP and URL entity types respectively.

Sentinel will now recognise the results of the query as containing the defined entity types, which can then be used with other Sentinel features (e.g. right Quick Investigation function for entities).

You’ll find a useful reference table of entity types and supported identifiers available here.

Query

The query is the part of the rule responsible for the detection. It defines how and what data is returned.

Queries are written in the Kusto Query Language (KQL).

I’ll explain more about Kusto in part 2 of this post next week (subscribe on Obstracts to be the first to know when it’s published).

2022-03-28 Update

Read part 2 of this post: How to write detection and hunting queries using Kusto in Microsoft Sentinel (Part 2).




Join the Signals Corps on Discord

Join our public community of intelligence analysts and researchers sharing new content hourly.


Obstracts

Obstracts

Turn any blog into structured threat intelligence.

Stixify

Stixify. Extract machine readable intelligence from unstructured data.

Extract machine readable intelligence from unstructured data.


Vulmatch

Vulmatch

Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.

SIEM Rules

SIEM Rules. Your detection engineering database.

View, modify, and deploy SIEM rules for threat hunting.