All the normalizing parsers can be deployed in a click using an ARM template. The initial release contains normalizing parsers for Infoblox, Cisco Umbrella, and Microsoft DNS server.
We have migrated analytic rules that worked on a single DNS source to use the normalized template. Those are available in GitHub and will be available in the in product gallery in the coming days. You can find the list at the end of this post.
With a single click deployment and support for normalized content in analytic rules, we believe we will see an accelerated adaption of the Azure Sentinel Information Model.
Join us to learn more about Azure Sentinel information model in two webinars:
The Information Model: Understanding Normalization in Azure Sentinel
Deep Dive into Azure Sentinel Normalizing Parsers and Normalized Content
Why normalization, and what is the Azure Sentinel Information Model?
Working with various data types and tables together presents a challenge. You must become familiar with many different data types and schemas, write and use a unique set of analytics rules, workbooks, and hunting queries for each, even for those that share commonalities (for example, DNS servers). Correlation between the different data types necessary for investigation and hunting is also tricky.
The Azure Sentinel Information Model (ASIM) provides a seamless experience for handling various sources in uniform, normalized views. ASIM aligns with the Open-Source Security Events Metadata (OSSEM) common information model, promoting vendor agnostic, industry-wide normalization. ASIM:
Allows source agnostic content and solutions
Simplifies analyst use of the data in sentinel workspaces
The current implementation is based on query time normalization using KQL functions. And includes the following:
Normalized schemas cover standard sets of predictable event types that are easy to work with and build unified capabilities. The schema defines which fields should represent an event, a normalized column naming convention, and a standard format for the field values.
Parsers map existing data to the normalized schemas. Parsers are implemented using KQL functions.
Content for each normalized schema includes analytics rules, workbooks, hunting queries, and additional content. This content works on any normalized data without the need to create source-specific content.
Why normalize DNS data?
ASIM is especially useful for DNS. Different DNS servers and DNS security solutions such as Infoblox, Cisco Umbrella & Microsoft DNS server provide highly non-standard logs, representing similar information, namely the DNS protocol. Using normalization, standard, source agnostic content can apply to all DNS servers without customizing it to each DNS server. In addition, an analyst investigating an incident can query the DNS data in the system without specific knowledge of the source providing it.
Analytic Rules added or updated to work with ASim DNS
Excessive NXDOMAIN DNS Queries (Normalized DNS)
DNS events related to mining pools (Normalized DNS)
DNS events related to ToR proxies (Normalized DNS)
Updated to include normalized DNS:
Known Barium domains
Known Barium IP addresses
Exchange Server Vulnerabilities Disclosed March 2021 IoC Match
Known GALLIUM domains and hashes
Known IRIDIUM IP
NOBELIUM - Domain and IP IOCs - March 2021
Known Phosphorus group domains/IP
Known STRONTIUM group domains - July 2019
Solorigate Network Beacon
THALLIUM domains included in DCU takedown
Known ZINC Comebacker and Klackring malware hashes