Skip to main content

5. See Your First Detection

The fifth step of the Quickstart: move from searching raw events to reading what the platform has concluded about them. This page is for the analyst. It introduces the ticket queue, the severity bands, and the behavior summary: together, where an analyst spends most of a working day.

Before You Begin​

Data arriving and searchable (steps 3 and 4), and enough elapsed time for detection content to have evaluated it.

Set your expectations honestly: a brand-new instance with one source connected an hour ago may have no tickets at all, and that is a correct outcome. Detection here is not a per-event rule firing on arrival: behaviors accumulate against an entity, and a summary has to accumulate enough to be worth raising. A quiet queue on day one means your tenant has not done anything unusual yet.

If your instance has no tickets yet​

Read this page against the screenshots, come back after a day or two of collection, or ask for access to a populated demonstration instance. Do not manufacture synthetic alerts to have something to look at: you will learn the wrong shape, and you will have to clean them up afterwards.

Every page below also works on an empty queue: the layout, the filters, and the facets are all visible and safe to explore with zero records.

The Ladder You Are Climbing​

Four words describe the same activity at four levels, and this step walks up all four. Keeping them apart is the single most useful thing to take from this page:

What it isWhere you see it
EventOne stored record: one audit entry, one sign-inDatalake Search (v1: Data Lake → Search)
BehaviorA scored observation raised when a behavior rule matches, attached to an entityNotable Events (v1: SIEM → Behavior Timeline)
Behavior summaryEvery behavior for one entity over one day, carrying that entity's accumulated risk scoreBehavior Summary, opened from Cases Search (v1: SIEM → Behavior Summary)
TicketThe queue item raised from a summary, the thing that gets worked and closed; the v2 interface calls it a caseOverview Summary (v1: SIEM → Overview Summary)

The score belongs to the entity and its accumulated behaviors, not to any single event. A sign-in from an unusual country is not, on its own, a critical incident; the same account also resetting MFA and granting an application consent within the hour is what a summary is for. See Risk Scoring.

Step 1: Open the Ticket Queue​

In the navigation rail, open Overview Summary.

Overview Summary page with the Open, Closed by AI and MTTR counters, the five severity tiles, the Window, Status and Sort filters, and an empty summary list

The page runs top to bottom as:

  • Three counters: OPEN, CLOSED BY AI, and MTTR.
  • A SEVERITY BREAKDOWN row with one tile per severity level.
  • A filter bar: Window, Status, Sort, the Show 0 score events checkbox, and Refresh.
  • The summary list, a table with the columns SUMMARY, ALERT DATE, RISK, and STATUS.

On a fresh instance the counters read zero (MTTR shows a dash) and the list reads No summaries match this filter. The Home dashboard's Open cases panel lists the same open records, and its All cases link opens this page.

Step 2: Set the Time Range​

The Window drop-down in the filter bar offers 1D (selected by default), 3D, 7D, 30D, 90D, and ALL TIME.

Choose a range that covers the period since your source was connected; 7D is a reasonable first choice on a new instance. Both the counters and the record list follow this range, so a zero counter with 1D selected tells you nothing about the week.

Step 3: Read the Ticket Counters​

  • OPEN: the open behavior summaries.
  • CLOSED BY AI: the records closed automatically by the AI.
  • MTTR: the mean time to respond, measured on AI responses, with the number of responses it is based on beneath it (AI response · n=0).

Read them as a workload and posture summary, not as a to-do list. OPEN tells you how much of the period's activity is still unhandled; CLOSED BY AI against it tells you how much never needed a person. A high closed-by-AI count with a low open count is a healthy instance, not a busy one.

Below the counters, the SEVERITY BREAKDOWN row has a tile for each severity level, giving the records of that severity shown in the list and, after the slash, the number of records of every severity that match the filters.

The five severity levels​

Critical, High, Serious, Medium, and Low. These are score bands rather than independent labels: a summary's severity chip follows its accumulated risk score, which is why the same rule can contribute to a Low summary on one entity and a Critical one on another. Risk Scoring covers the scoring model itself.

Step 4: Filter the Record List​

  1. Click a severity tile in the SEVERITY BREAKDOWN row to narrow the list to that severity. The tile is outlined, and a Clear filter - Severity link appears at the right end of the filter bar; click it to show every severity again.

    Overview Summary with the Critical tile outlined in red and a Clear filter - Critical link at the right end of the filter bar

  2. Leave Show 0 score events unticked. It is a checkbox, off by default, which keeps the list to the summaries at or above the notification threshold of 3,000; ticking it lists every summary in the window, down to zero-score ones, which on a new instance will bury the few records worth looking at.

  3. Narrow by status with the Status drop-down: All (the default), New, Acknowledged, Closed, and Closed By AI.

  4. Order the list with Sort: Highest risk first (the default), Newest first, or New / unclosed first.

Choosing a good first record to read​

Pick a mid-severity record with several contributing behaviors rather than the single highest-scoring one. The highest score is usually one loud rule firing repeatedly, which teaches you nothing about how the score is assembled; a Medium summary built from four different rules shows you the whole mechanism in one screen.

Step 5: Read a Behavior Summary​

In the navigation rail, open Cases Search, or click a summary in the Overview Summary list, which opens it on the Behavior Summary page directly. The records on the Overview Summary and the cases here are the same underlying objects; this page is where you search them.

Cases Search page with the search field, the 1D to Custom time-range buttons with 7D selected, the Filters panel listing eight facet groups, and an empty results table

The page is headed Cases Search, subtitled Faceted search across case summaries., with a free-text search field, the time-range buttons 1D, 3D, 7D, 30D, and Custom (it opens on 7D), and Search.

The FILTERS panel on the left holds one group per facet (Incident Status, Score Level, Entity / Key, Entity / Key Type, Behavior Rules, Behaviors, Risks, and Analyst), each listing the values found in the selected range. Use Entity / Key to jump straight to a user, or Behavior Rules to see everything one rule contributed to. The results table on the right shows each case's Last Seen, Summary, Entity / Key, Status, Score, and Level by default; ⚙ Columns adds others.

Click a case to open its detail panel, then Open case at the top of the panel to open it on the Behavior Summary page, for that entity and day:

Behavior Summary page for one entity on one day, with the Entity and Day search fields, the case header with its CRITICAL severity, New status, score, and last update, the AI Report, AI Analysis, Info, Comments and JSON tabs, and one triggered behavior rule expanded to its correlation alerts and fields

The case header shows:

  • The entity the summary covers, such as an email address or an AWS ARN, with its type and the day beneath it.
  • The severity, for example CRITICAL.
  • The status drop-down: New, Acknowledged, or Closed.
  • Score, Last Updated, and Classification (a dash when unset).

Read the header in that order and you have the whole triage question in one line: which entity, on which day, at what score, in what state. The Entity and Day fields above it load another summary; the URL carries both, so a summary can be linked to directly.

Reading what the score is made of​

The page opens on its Info tab, which answers that directly. Triggered Events lists each behavior rule the entity triggered that day, with a chip for each correlation alert it raised and its Score, Count, Alerts, and Fields. Below it, a calendar of the entity's notable events puts the day in context, and Behavior Rollup totals the entity's events by name.

For the record itself, open the JSON tab, which shows the summary's JSON with a Copy JSON button. It is worth doing once on your first summary even though you will not do it on every one afterwards.

The record holds the identity and range fields (id, from, to, count, key, keyType, dayIndex), the behaviorRules and behaviors arrays naming what contributed, the overall riskScore, and a summaryList array that breaks the score down per rule, each entry with its own hits, risks, count, riskScore, ruleID, behavior, and attributeSummaries.

summaryList is the answer to "why is this score what it is".

The Behavior Summary walkthrough works one of these end to end, and Investigating a Behavior Alert is the full triage procedure.

Step 6: Trace a Behavior Back to Its Events​

A summary tells you an entity accumulated risk. To see when and from what, stay on its Info tab and click a rule's row under Triggered Events to expand it:

  • Correlation Alerts: each alert the rule raised, as a chip such as ALERT_SEVERITY_MEDIUM or ML_NEW_USER, with its description.
  • Fields: the triggering event's fields and their values. The fields depend on the source; an Entra ID sign-in shows Application, ClientApp, Country, IPAddress, OS, and so on.
  • Datalake Search, View Rule, Add Suppression, and Test Suppressions buttons.

Fields is the step that closes the loop. If your source is the Microsoft 365 application from step 2, those fields are the same sign-in details you were faceting on in step 4: the same data, now attached to a scored observation rather than sitting in an index.

To go all the way to the original record, click Datalake Search on the expanded rule, which searches the data lake for the matching events; click an event there to open it with every field and its raw JSON. That record is the point at which the detection stops being a claim and becomes the vendor's own record.

For behavior events across every entity, open Notable Events in the navigation rail: a faceted search with the same layout as Cases Search, whose facets are Score Level, Entity / Key, Entity / Key Type, Behavior Rule, Behavior, and Risks, and whose table shows each event's Time, Entity / Key, Behavior Rule, Behavior, Score, and Level.

Notable Events page with the search field, the 1D to Custom time-range buttons with 1D selected, the Filters panel listing six facet groups, and an empty results table

Step 7: Look at the Rule Behind It​

Open Configuration → Behavior Rules and find the rule that raised one of the behaviors you just read; its name is on the triggered rule in the summary, and in the summary's behaviorRules array. View Rule on the expanded rule opens the same rule read-only without leaving the summary.

Behavior Rules page showing the search bar with the sort drop-down and the Search, Behavior Filters, and Create Rule buttons, the facet panel on the left, and the rule table with name, category, tags, active switch, and last-updated columns

The page is subtitled Listing of Behavior Rules. Its search bar holds a full-width search field, a sort drop-down (Rule Name: A-Z, Rule Name: Z-A, Last Updated), and the Search, Behavior Filters, and + Create Rule buttons. Below it, a FILTERS panel groups the rules by Category, Behaviors, Filter, Event Type, Aggregation Type, Tags, Repository, and Disabled, beside the rule table itself: one row per rule with its name, category, tags, active switch, and last update.

Read the rule's description and category, and notice which Behaviors it is filed under. That is enough for now.

Where tuning happens, but not yet​

Behavior Filters opens a separate page, subtitled Exceptions for Behavior Rules. It holds a search field, a Return to Rules button to come back, + Add Wildcard Filter, a FILTERS panel, and a table of filters with ENABLED, NAME, DESCRIPTION, BEHAVIORS, and CREATED ON columns. Add Suppression on a triggered rule in a behavior summary opens the same kind of filter, pre-filled from that event.

A behavior filter is an exception to a rule: the mechanism for saying "this rule is right in general, but not for this service account". It is the correct answer to a noisy rule and the wrong answer to a rule you have not yet understood, which is why this quickstart stops at reading. See Managing Rules when you are ready to change something.

How to Tell It Worked​

  • The Overview Summary loads, and its counters follow the Window you set.
  • Filtering by severity tile and by Status changes the summary list in the way you expect.
  • On Cases Search you can find at least one case, open it on Behavior Summary, and name the entity it covers, its day, its score, and its severity.
  • Its Triggered Events, and its JSON tab, read as an explanation of the score.
  • Expanding a triggered rule shows the Fields of the event behind it.
  • You can name the rule that raised it, and say in one sentence what a Behavior Filter would do to it.

On an instance with no tickets yet, being able to describe all six from the screenshots is a pass. Come back and do it for real once there is data.

If It Did Not Work​

SymptomWhat it meansWhat to do
No tickets at allExpected on a new instance with one sourceTime and more data, not configuration. Re-check with a wider Window first
The summary list is empty but the counters are notA severity tile or the Status filter is excluding everythingClick Clear filter - Severity and set Status back to All
Summaries you expect are not listedShow 0 score events is unticked, so summaries below the 3,000 notification threshold are hiddenTick it
Tickets exist, but none relate to your new sourceDetection content for that source may not be enabled, or its data is not yet normalized into the fields the rules useManaging Rules
A flood of low-severity ticketsNormal on a first connection, before any tuningNote them and move on; tuning with Behavior Filters is a later activity
A ticket you cannot openA permissions question, not a detection oneCheck the role assigned to your user: Managing Roles

Next Step​

6. Set Up Your First Notification: so you do not have to watch the queue.

Last updated on