Hello everyone,
Last quarter we focused on Azure Sentinel Information Model (ASIM) foundations and defined schemas. This quarter we focused on making ASIM more useful to you:
- ASIM is now simpler and faster to deploy - you can now deploy all ASIM parsers in a single, easy deploy. And since it costs nothing, takes a minute, and, using query time technology, does not actually change your data, why not test drive? See the new getting started guide to get you going.
- ASIM is now lightning fast - One of the concerns we keep hearing about ASIM is that using query time parsing can slow things down. To address this, we have designed parametrized parsers. Parametrized parsers let you pass filtering conditions to the parser itself, ensuring filtering precedes parsing, leading to a significant performance gain. In many cases, filtering using parser parameters will result in much better performance than using non-normalized data.
The first schema to use parametrized parsers is the DNS schema. DNS is a high-volume source, and using optimized parsers enables the new normalized Threat Intelligence Analytics Rules (Domains, IPs) to match your TI to even the highest volume of DNS data. And with out-of-the-box optimized parsers for a wide variety of DNS servers and clients, including Windows DNS Server, InfoBlox, Cisco Umbrella, Corelight Zeek, Google Cloud DNS, and Sysmon, you get this detection across much more of your data.
Join us to learn more about parametrized parsers in our upcoming webinar “Turbocharging ASIM: Making Sure Normalization Helps Performance Rather Than Impacting It” on Oct 6th. Register, as usual on https://aka.ms/securitywebinars.
- ASIM covers more scenarios – We released an updated network, proxy, and IPS schema. It now clearly document how to use the network schema to normalize common network sources such as Firewalls, Proxy Servers, Web Security Gateways, and Intrusion Preventions Systems (IPS). It also more closely adhere to the latest ASIM guidelines.
- ASIM supports your sources – apart from ASIM harmonizing different sources, ASIM can help you analyze data from specific products, overcoming the limitation of the raw information. We now provide product-specific deployment for:
- Sysmon – providing parsed and normalized events instead of the raw, hard to use Sysmon events. Also, it does not matter if you collected the Sysmon events locally to the Event table or used WEF from remote systems: ASIM will combine them all for you in a uniform, easy-to-use format.
- And we also support the upcoming Sysmon for Linux.
- Windows Events – Seamlessly use Security Events, and the upcoming Windows Events collected using WEF using a single schema.
- Use Microsoft Defender for IoT – Endpoint to monitor your endpoints without learning a new event structure.
- Interested? We have updated the documentation – to help you get value out of ASIM, we have extended and refreshed our documentation. We now have dedicated sections for ASIM schemas, ASIM parsers, and ASIM-based content. And don’t forget our ASIM intro and deep dive Webinars!
Special thanks to @Yaron Fruchtmann and @Yuval Naor, who made all this possible.
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.
Ofer Shezaf
Principal Product Manager, Azure Sentinel
Posted at https://sl.advdat.com/3k7uKzu