Cloud / Microsoft Sentinel Interview questions

Microsoft Sentinel is Microsoft's cloud-native SIEM (security information and event management) and SOAR (security orchestration, automation and response) platform. It collects security data from users, devices, applications and infrastructure, detects threats with analytics, and helps analysts investigate and respond from one place.

It is built on top of an Azure Monitor Log Analytics workspace, so everything it collects lives in workspace tables that you query with KQL. There are no servers to size or patch, and cost follows the volume of data you ingest.

Sentinel is now managed in the Microsoft Defender portal, where it sits next to Defender XDR as part of the unified security operations experience. The older Azure portal experience is on a retirement path.

Sentinel is a set of cooperating pieces layered on a Log Analytics workspace. Data comes in through connectors, rules turn it into alerts, and automation and investigation tools handle what happens next.

UEBA and the data lake extend this core with behavior baselines and low-cost long-term storage.

The Log Analytics workspace is Sentinel's data store and query engine. Sentinel is enabled on a workspace, and every connector writes into tables inside it, such as SecurityEvent, SigninLogs and CommonSecurityLog.

The workspace also decides several things people often overlook:

• Data residency: data stays in the region where the workspace was created.
• Retention: set per workspace and overridable per table.
• Access control: Azure RBAC at workspace scope, with table-level RBAC for finer control.
• Billing: ingestion and commitment tiers are applied per workspace.

Data connectors are the integrations that move log data from a source into a Sentinel workspace. Each connector writes to one or more known tables so that built-in rules, workbooks and hunting queries can use the data.

They fall into a few families:

• Service to service: Microsoft Entra ID, Microsoft 365, Azure Activity and Defender XDR connect without an agent on the source.
• Agent based: the Azure Monitor Agent collects Windows Security events, Syslog and CEF from servers and forwarders.
• API and codeless: REST based connectors for SaaS products, many built with the Codeless Connector Framework.
• Custom: Logic Apps, Azure Functions or the Logs Ingestion API for sources with no ready connector.

Most solutions in the Content hub ship their own connector together with matching detections.

KQL is the read-only query language used across Azure Monitor, Log Analytics and Microsoft Sentinel. A query starts from a table and passes rows through a chain of operators joined by the pipe character |.

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType != "0"
| summarize Failures = count() by UserPrincipalName
| top 10 by Failures desc

In Sentinel, KQL powers analytics rules, hunting queries, workbooks, watchlist lookups and parsers. Table and column names are case sensitive, and string operators matter: == is case sensitive, =~ is not, and has is usually faster than contains.

Analytics rules are the detections that watch your data and raise alerts when suspicious patterns appear. Most contain a KQL query, a run schedule and a threshold; if the results meet the threshold, the rule creates an alert and, optionally, an incident.

A rule definition typically includes:

• the KQL query and how often it runs and how far back it looks
• severity and MITRE ATT&CK tactics and techniques
• entity mapping to accounts, hosts and IPs
• alert enrichment and custom details
• incident creation and alert grouping settings
• automated response through automation rules

You can start from built-in templates in the Content hub and tune them for your environment.

Sentinel offers several rule types, each suited to a different detection style.

Scheduled rules cover most custom detections. NRT is reserved for a small number of time critical ones.

An incident is the case file an analyst works on. It groups one or more related alerts, the entities involved and supporting evidence, so you investigate a single story instead of many separate alerts.

Each incident carries a severity, a status (New, Active or Closed), an owner, tags, comments, tasks and a timeline. When you close it, you pick a classification and add a comment:

• True positive: real malicious activity.
• Benign positive: suspicious but expected, such as an approved penetration test.
• False positive: the detection was wrong.
• Undetermined: not enough information to decide.

Entities are the normalized objects that appear in alerts: the account, host, IP address, URL, file, file hash, process, mailbox, cloud application and so on. They give raw columns a shared meaning so Sentinel can connect events across rules and data sources.

You create them with entity mapping in an analytics rule, pointing a query column at an identifier such as Name and UPNSuffix for an account or Address for an IP.

Well mapped entities make the investigation graph and entity pages useful, let alert grouping match related alerts, and feed UEBA. Rules with weak or missing mappings tend to produce incidents that are hard to correlate.

Workbooks are interactive dashboards built on Azure Monitor workbooks. They run KQL against your workspace and present the results as charts, grids and tiles, with parameters such as time range or workspace to filter everything at once.

Common uses are monitoring connector and ingestion health, reporting SOC metrics like incidents by severity, and visualizing a specific data source such as Entra sign-ins. Many ship as templates inside Content hub solutions.

In the Defender portal they are found under Microsoft Sentinel > Threat management > Workbooks, and you can edit them there directly.

The Content hub is Sentinel's catalog of ready-made security content. It packages solutions, each bundling items for one product or scenario: data connectors, analytics rule templates, workbooks, hunting queries, parsers, watchlists and playbooks. Standalone items are available as well.

Installing a solution adds the content to your workspace, but it does not turn detections on by itself. You still create rules from the installed templates, review the query, and enable them.

Solutions are versioned, so you can see when an update is available and refresh the installed content.

A watchlist is a named reference dataset, usually imported from CSV, that you can join against log data in KQL. Typical entries are VIP accounts, approved admin IPs, terminated employees or asset inventories.

You read one with the _GetWatchlist() function and its alias, matching on the SearchKey column:

SigninLogs
| where UserPrincipalName in ((_GetWatchlist('VIPUsers') | project SearchKey))

Watchlists suit small to medium lookup data you maintain yourself. They are not meant for bulk logs, and unlike threat intelligence indicators they have no built-in expiry or confidence scoring.

Threat hunting is the proactive, hypothesis-driven search for malicious activity that existing rules did not flag. Instead of waiting for an alert, an analyst asks a question such as "has any account signed in from two countries within an hour?" and tests it in the data.

Sentinel supports this with several tools:

• Hunting queries: built-in and custom KQL mapped to MITRE ATT&CK.
• Bookmarks: save interesting results as evidence and attach them to incidents.
• Livestream: run a query continuously and get notified of new matches.
• Notebooks: Jupyter based analysis for heavier investigation.
• Search jobs: pull specific records out of large or archived data.

A hunting query that proves valuable can be promoted to an analytics rule.

A playbook is an automated response workflow built on Azure Logic Apps. It runs in response to an incident, an alert, or an entity you select manually, and chains actions through Logic Apps connectors.

Typical playbook actions include enriching an IP with a reputation lookup, posting to a Teams channel, opening a ServiceNow ticket, disabling a compromised user in Microsoft Entra ID, or isolating a device. Playbooks can be started by an automation rule or run manually from an incident.

Both Consumption and Standard Logic Apps work. The Sentinel service needs the Microsoft Sentinel Automation Contributor role on the playbook's resource group to trigger them from automation rules.

Automation rules are Sentinel's built-in, lightweight way to handle incidents and alerts without writing a Logic App. They fire on a trigger, check conditions, and then run ordered actions.

• Triggers: incident created, incident updated, or alert created.
• Conditions: analytics rule name, severity, status, tags, entities and more.
• Actions: assign an owner, change status or severity, add tags or tasks, close an incident, or run a playbook.

Rules run in the order you set, can carry an expiration date, and are commonly used to auto-close known noise or route incidents to the right team. Anything needing branching logic or external APIs belongs in a playbook.

UEBA (User and Entity Behavior Analytics) learns what normal looks like for users, hosts and IPs, then flags activity that departs from it. It builds a baseline per entity and compares it with a peer group, such as colleagues in the same team.

Once enabled in settings with sources like Entra ID sign-in and audit logs, Azure Activity and Windows security events, it writes enriched output you can query:

• BehaviorAnalytics with activity insights and an investigation priority score
• UserPeerAnalytics and IdentityInfo for peers and identity context
• Anomalies for detected anomalous behavior

It does not replace rules. It adds context that helps analysts decide which users and hosts to look at first.

The Sentinel data lake is a cloud-native store for large volumes of security data at much lower cost than the analytics tier, with long retention (up to 12 years) and a clean split between storage and compute.

You can mirror analytics-tier data into it or send high-volume tables there directly, then work with it through:

• KQL queries over lake data
• KQL jobs that run on a schedule and can promote results to the analytics tier
• Jupyter notebooks in Visual Studio Code for heavier analysis
• an MCP server so AI agents can query the data

It suits historical investigations, compliance retention and bulk telemetry you rarely query. Real-time detection still belongs on analytics-tier tables.

Sentinel lets you place each table in a tier that matches how the data is used. The tier controls cost, query features and whether the table can power detections.

Microsoft is steering low-cost, long-retention scenarios toward the data lake, and Defender tables support Analytics and data lake tiers. A table's tier change applies to new data only.

Sentinel uses Azure RBAC, assigned at the workspace or its resource group. The main roles form a ladder of capability.

Give analysts the least role they need. Where the Defender portal's unified RBAC is enabled, it can be used alongside these.

You add Sentinel to an existing or new Log Analytics workspace, then connect data and content. The steps are:

1. Create a Log Analytics workspace in the region that meets your data residency needs, or pick an existing one.
2. Add Microsoft Sentinel to that workspace. You need Contributor rights on the subscription or resource group that holds it.
3. Connect data sources through data connectors, starting with free or high-value ones such as Entra ID, Azure Activity and Defender XDR.
4. Install relevant solutions from the Content hub and enable analytics rules from their templates.
5. Onboard the workspace to the Defender portal. New customers are onboarded automatically.

Nothing shows up until at least one connector is sending data.

Sentinel is billed on data ingested, not on users or alerts. The cost combines the Sentinel analysis charge and the underlying Log Analytics ingestion charge, and simplified pricing presents them as one per-GB rate.

• Pay-as-you-go: a flat per-GB rate for the Analytics tier.
• Commitment tiers: commit to a daily GB volume for a discounted per-GB rate.
• Cheaper tiers: Basic, Auxiliary and the data lake cost far less per GB.
• Included retention: the first 90 days are covered for Sentinel-enabled workspaces.
• Free sources: some data, such as Azure Activity and Office 365 audit logs, is not charged for ingestion.

Each workspace meets its commitment tier on its own, so splitting workspaces can cost you a discount. Check the Azure pricing page for current rates.

Microsoft Sentinel in the Azure portal will be retired on March 31, 2027. After that date it is managed only in the Microsoft Defender portal. The date was extended from the original target of July 1, 2026 after customer and partner feedback.

Your workspace, data and rules are not deleted. Only the management experience moves. New customers who onboard their first workspace have been taken to the Defender portal automatically since July 2025.

Plan the move early: check automation rules and playbooks, retrain analysts on the Defender portal, and confirm any tools that depend on the old portal paths.

An alert is one detection event, raised by an analytics rule or a Microsoft security product. An incident is the case that groups one or more alerts, with their entities and evidence, for an analyst to work.

A rule can be set to create alerts only, in which case no incident is opened. In the Defender portal, Sentinel and XDR alerts are correlated into the same incident queue.

Scheduled rules run a query at an interval you choose, while NRT (near real time) rules run roughly every minute for fast detection.

Use NRT for a few time-critical detections, like a break-glass account sign-in. Choose scheduled when you need aggregation over a longer window, such as counting failures over an hour.

By default each alert from a rule becomes its own incident, which floods the queue when a rule fires repeatedly. Grouping settings in the rule let related alerts roll into one incident instead.

The incident settings tab offers:

• Create incidents from alerts on or off.
• Group all alerts from the rule into a single incident, or group only alerts that match chosen entities, such as the same account or host.
• Match type: all selected entities must match, any of them, or specific ones.
• Time window: how long a matching incident stays open to receive more alerts, up to 7 days.
• Reopen closed incidents when a matching alert arrives.

Separately, event grouping decides whether one alert covers all query results or one alert is raised per event row. Incidents also have a cap on grouped alerts, so very noisy rules still need tuning.

An automation rule is a native, lightweight decision point. A playbook is a full Logic Apps workflow. In practice they work together: the rule decides, the playbook acts.

Use rules for triage housekeeping, such as auto-closing known noise. Use playbooks for integration work like ticketing, enrichment or blocking a user.

Playbooks authenticate through their Logic Apps connections. For Sentinel and other Azure resources the recommended option is a managed identity, system or user assigned, granted just the roles it needs, such as Microsoft Sentinel Responder on the workspace.

Other options exist but have drawbacks. A connection signed in with a person's account breaks when the token expires or that person leaves. A service principal works but adds a secret to rotate.

For third-party systems that use API keys or passwords, keep the secret in Azure Key Vault and read it from the workflow rather than pasting it into an action. Separately, the Sentinel service needs Microsoft Sentinel Automation Contributor on the playbook's resource group to start playbooks from automation rules.

Use them for data that is high in volume, low in detection value and queried only now and then. Everything that feeds scheduled or NRT rules, hunting at scale and workbooks should stay in the Analytics tier.

Many teams split one source: send the detection-relevant subset to Analytics and the bulk to a cheaper tier, using a split transformation in the data collection rule.

A data collection rule (DCR) can run a KQL transformation on incoming records before they are stored. By dropping rows and columns you do not need, you ingest less and pay less.

Inside the transformation, source stands for the incoming data. For example, to drop accepted firewall traffic and a bulky column:

source
| where DeviceAction != "Accept"
| project-away AdditionalExtensions

You can also parse fields, add columns, or use a split transformation to send different rows to different tables or tiers. Keep TimeGenerated, and test carefully, because dropped data cannot be recovered and only a subset of KQL operators is allowed.

The Azure Monitor Agent (AMA) runs on a Windows or Linux machine, or on an Azure Arc enabled server, and collects data as instructed by a data collection rule associated with that machine. It authenticates with a managed identity and sends the data to the workspace.

flowchart LR
A["Server with AMA"] --> B["Data collection rule"]
B --> C["Optional transformation"]
C --> D["Log Analytics workspace"]
D --> E["Sentinel rules and hunting"]

The DCR defines what to collect, such as Windows Security events filtered by XPath, Syslog facilities or CEF, and where to send it. A data collection endpoint is needed for some scenarios, such as private networks.

AMA replaced the legacy Log Analytics (MMA) agent, which was retired on August 31, 2024.

Both usually arrive over syslog on a Linux forwarder running AMA, but they land in different tables with different structure. Syslog keeps the raw message text; CEF (Common Event Format) carries key-value fields that are parsed into columns.

Prefer CEF when the device supports it. Avoid sending one stream to both, which doubles ingestion cost.

The Codeless Connector Framework (CCF) lets you build a connector for a REST API using JSON definitions, without writing or hosting an Azure Function. Sentinel runs the polling, scheduling and retries for you.

A CCF connector is assembled from a few parts:

• a connector definition that creates the page in the portal
• a data connector resource that sets the API endpoint, authentication such as API key, basic or OAuth2, and paging
• a data collection rule with a transformation that shapes incoming data
• a destination table, often a custom _CL table

Compared with function-based connectors, there is no compute to patch or scale, and the connector can be packaged into a Content hub solution.

When a workspace is connected to the Defender portal, Sentinel and Defender XDR share one incident queue, one hunting experience and one set of analyst workflows.

• Unified incidents: the Defender XDR correlation engine merges alerts from Sentinel rules and Defender products into a single incident.
• Two way sync: status, owner, classification and comments stay aligned between the portals.
• Advanced hunting: one KQL surface to query XDR tables and Sentinel workspace tables together.
• Shared context: entity pages and investigation views span both products.

Because Defender creates incidents from XDR alerts itself, Microsoft security incident creation rules are not needed there, and the older Fusion engine is replaced by Defender correlation.

Your workspace's incidents, alerts and hunting move into the unified Defender experience, and a few behaviors change because Defender XDR now owns incident creation and correlation.

• Sentinel and XDR alerts flow into one incident queue, with Defender incident IDs.
• Microsoft security incident creation rules are no longer needed, since XDR creates those incidents itself.
• The legacy Fusion engine is disabled and Defender correlation takes over multistage detection.
• Workbooks, content management and other Sentinel pages are reached from the Defender portal navigation.
• Azure RBAC on the workspace still applies to Sentinel data.

Your workspace data and analytics rules stay in place. After onboarding, re-test automation rules and playbooks, especially ones triggered on incident updates or filtering on incident source, and check queries that depend on SecurityIncident.

UEBA reads activity from enabled sources, such as Entra ID sign-in and audit logs, Azure Activity and Windows security events, and learns what is usual for each entity: typical locations, devices, applications and activity volumes.

It also derives peer groups from identity context like group membership and manager. A user's behavior is then compared with both their own history and their peers, and unusual activity gets an investigation priority score from 0 to 10 in BehaviorAnalytics.

BehaviorAnalytics
| where TimeGenerated > ago(7d)
| where InvestigationPriority > 5
| project TimeGenerated, UserPrincipalName, ActivityType, InvestigationPriority
| order by InvestigationPriority desc

The baseline needs time to mature, so expect better signal after a few weeks than on day one.

Filter failed sign-ins in a short window, group them by user, and alert when the count passes a threshold. In SigninLogs, ResultType is a string and 0 means success.

let threshold = 10;
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType in ("50126", "50053")
| summarize Failures = count(),
            DistinctIPs = dcount(IPAddress),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by UserPrincipalName
| where Failures >= threshold

Here 50126 is a bad username or password and 50053 is a locked account. To spot a possible compromise, join the result back to successful sign-ins (ResultType == "0") from the same user. Map UserPrincipalName to the Account entity and IPAddress to IP in the rule.

extend adds computed columns and keeps every row. summarize groups rows and aggregates them, so the output has fewer rows and only the grouping and aggregate columns.

SecurityEvent
| where EventID == 4625
| extend Hour = bin(TimeGenerated, 1h)
| summarize Failures = count() by Account, Hour

Here extend creates the hourly bucket, then summarize counts failures per account per hour.

Efficient queries run faster, cost less and are less likely to time out and fail. The main habits are:

1. Filter early. Put where clauses on time and key columns right after the table name.
2. Reduce columns early with project before joins and aggregation.
3. Prefer has over contains for whole-term matches, since it uses the term index.
4. Avoid wide searches such as search * or union *.
5. Put the smaller table on the left of a join, or use lookup for small reference data.
6. Reuse subqueries with materialize() when the same result is needed twice.
7. Use ASIM parsers with filter parameters so filtering happens inside the parser.

Test in the logs query window and compare run time and data scanned before saving the rule.

ASIM is Sentinel's normalization layer. It maps differently shaped logs, such as firewall, DNS or sign-in data from many vendors, onto common schemas with the same field names, so one query or rule works across all of them.

Schemas include Network Session, DNS, Authentication, Process Event, File Event, Registry Event and Web Session. Each has source-specific parsers and a unifying parser, such as _Im_NetworkSession for filtered use and _ASim_NetworkSession without parameters.

_Im_Dns(starttime=ago(1d), domain_has_any=dynamic(["bad.example"]))
| project TimeGenerated, SrcIpAddr, DnsQuery

The payoff is detection content that does not need rewriting when you add or replace a vendor.

Both are lookup data, but they serve different jobs. A watchlist is your own reference data. A threat intelligence indicator is an indicator of compromise (IP, domain, URL, file hash) with metadata about its source.

Put approved admin jump-host IPs in a watchlist. Put a feed's list of known malicious IPs in threat intelligence.

Several connectors and methods feed indicators into the workspace.

• Threat Intelligence - TAXII pulls indicators from TAXII 2.x servers, including ISAC and commercial feeds.
• Microsoft Defender Threat Intelligence brings in Microsoft's own indicators and enrichment.
• Upload Indicators API lets a threat intelligence platform push indicators in.
• Manual entry or file import adds one-off indicators from the TI page.

Indicators are stored in the legacy ThreatIntelligenceIndicator table, and newer connectors also write STIX-based tables such as ThreatIntelIndicators and ThreatIntelObjects. TI map analytics rules then match them against logs like CommonSecurityLog or DnsEvents and raise alerts.

Work from the source toward the workspace, ruling out one layer at a time.

1. Connector page: check the last log received time and any status message.
2. Health data: enable health monitoring and query it for failures.
3. Source and agent: confirm the agent heartbeat, the DCR association, the forwarder's syslog daemon and network or firewall access.
4. Credentials: expired API keys, secrets or revoked permissions break API connectors.
5. Workspace: look for a reached daily cap, a transformation that drops everything, or ingestion delay.

SentinelHealth
| where SentinelResourceType == "Data connector"
| where Status != "Success"
| order by TimeGenerated desc

Heartbeat
| summarize LastBeat = max(TimeGenerated) by Computer

Compare ingestion_time() with TimeGenerated to tell late data from missing data.

First prove whether the rule ran, then whether its query should have matched.

1. Confirm the rule is enabled and was not auto-disabled after repeated failures.
2. Check health data for query errors, missing tables or timeouts.
3. Run the query manually over the same time window and see if it returns rows.
4. Compare lookback, frequency and ingestion delay. If events arrive late, a lookback equal to the frequency misses them.
5. Review the alert threshold, event grouping and suppression settings.
6. Check whether the source table was moved to a tier that cannot back rules, such as Basic.

A lookback a little longer than the run frequency tolerates delay, and the rule's alert deduplication avoids duplicate alerts for the overlap.

Tune the rule rather than switching it off. Start with the incidents closed as false or benign positive and find what they have in common.

• Exclude known good accounts, IPs or scanners through a watchlist instead of hardcoding values.
• Raise thresholds or narrow scope, such as only privileged roles.
• Add context by joining to asset or identity data.
• Auto-close known noise with a time-limited automation rule.
• Review SOC optimization and incident statistics for the noisiest rules.

SigninLogs
| where ResultType == "50126"
| where UserPrincipalName !in ((_GetWatchlist('ServiceAccounts') | project SearchKey))

Document each change so a later analyst knows why a detection looks the way it does.

An incident moves from raw data to a classified, closed case in a predictable sequence.

flowchart TD
A["Connectors ingest logs"] --> B["Analytics rule matches"]
B --> C["Alert raised"]
C --> D["Incident created and grouped"]
D --> E["Automation rules tag and assign"]
E --> F["Playbook enriches or responds"]
F --> G["Analyst triages and investigates"]
G --> H["Close with classification and comment"]

1. A rule or Defender detection raises an alert.
2. Incident settings turn it into a new incident or add it to an open one.
3. Automation rules run in order: tag, set severity, assign, or run a playbook.
4. The analyst moves it to Active, reviews entities and the investigation graph, and adds comments and tasks.
5. On closure they choose a classification (true, benign or false positive, or undetermined) and a comment.

Those closure details feed later tuning, so they are worth filling in properly.

Each time a scheduled rule runs, it queries a time window and decides whether to raise alerts.

sequenceDiagram
participant S as Scheduler
participant W as Workspace
participant R as Rule engine
participant I as Incident logic
S->>R: Run at frequency
R->>W: Query over lookback period
W-->>R: Result rows
R->>R: Apply alert threshold
R->>R: Map entities and enrich
R->>I: Create alerts
I->>I: Group into incidents
I->>S: Trigger automation rules

1. The scheduler starts the rule at its query frequency.
2. The query runs over the lookback period.
3. If the row count meets the threshold, alerts are generated; with event grouping, one alert covers all rows or one per row.
4. Entity mapping, custom details and alert details are applied.
5. Alerts are written and grouped into incidents, then automation rules fire.

If the threshold is not met, nothing is raised for that run. Ingestion delay can make events miss a run if the lookback is too short.

Start with a single workspace. It gives the simplest queries, a single commitment tier and the lowest overhead. Add more only for a concrete reason:

• Data residency: regulation requires data to stay in specific regions.
• Ownership: separate tenants, subsidiaries or customers, as with an MSSP using Azure Lighthouse.
• Different retention or compliance regimes that cannot share workspace settings.
• Strict access separation that table-level RBAC cannot give you.

The costs are real: each workspace meets its commitment tier on its own, and cross-workspace queries are more complex. You can still query across workspaces with workspace("name").Table.

In the Defender portal you connect one primary workspace and any number of secondary workspaces per tenant, with incidents unified in one queue.

The Repositories feature connects a workspace to a GitHub or Azure DevOps repository and deploys content from it automatically, so detections are managed like code.

1. Create a repository with folders for content types: analytics rules, automation rules, hunting queries, parsers, playbooks and workbooks.
2. Store each item as an ARM template (JSON).
3. Connect the repository and branch to the workspace; Sentinel sets up the deployment workflow.
4. Work in a dev workspace on feature branches and open pull requests for review.
5. Merging to the main branch deploys the changes to the target workspace.

This gives version history, peer review, and repeatable deployment across multiple workspaces. Bicep, Terraform and the REST API are common alternatives for teams already using them.

SOC optimization analyzes the data you ingest and the detections you run, then recommends changes in two areas.

• Coverage: shows gaps against threat scenarios such as ransomware or business email compromise, based on your data and MITRE ATT&CK, and suggests rules or connectors to close them.
• Data value: flags tables you pay for but that no rule or hunting query uses, and suggests a cheaper tier or new detections.

Recommendations can be tracked and acted on from the portal. Combined with tiering and summary rules, it helps you spend ingestion budget on data that actually protects you.

A summary rule is a scheduled KQL query that aggregates data and writes the result to a custom table (_CL) in your workspace. It condenses large, noisy data into compact records you can query and alert on cheaply.

CommonSecurityLog
| where DeviceAction == "Deny"
| summarize Denies = count() by SourceIP, DestinationPort

Rules run in time bins from 20 minutes up to a day. The source can be Analytics, Basic or Auxiliary data, and the output lands in an Analytics tier table, so scheduled rules and workbooks can use it.

Typical use: keep raw firewall logs in a cheap tier, summarize denies per source hourly, and detect on the summary. The trade-off is added delay and loss of per-event detail.