Working detections

A detection is something a detection rule or a security integration found: a brute force that got in, a new country sign-in, malware on a laptop. Detections are what your technicians work through; the events behind them are there to explain them.

The detections list#

Security > Detections lists detections worst first. Each shows its Severity, the Detection title (the rule and what it is about, for example "Windows logon brute force: administrator"), Status, Customer, how many Events it covers and when it was Last seen. Columns adds more, such as the assignee. The list follows the customer switcher: with one customer chosen it shows only theirs and names them under the heading.

Filter by severity, status, Past a response target, VIP or critical, customer, what found it (a rule or an integration), assignee, MITRE tactic, last active and when it was closed. The Views picker has New, Mine, High and critical, VIP and critical, Breaching, This week, Resolved (which includes false positives), Closed in 7 days, False positives and All detections, and you can save your own. The Due time shows how long is left to take or resolve each one. A detection inside an open incident is on the incident's clock, so its Due names the incident: see Incidents and response.

Keyboard#

Select several rows to take them, mark them investigating, resolve them or mark them false positives in bulk, or to group them with New incident from these or Add to incident. Anything that could not be done is reported.

The side panel#

Click a detection to open it in a side panel: why it fired, the grouped values (host, source IP, user), the steps of a sequence rule, customer, device, what it is about, the rule that found it, its MITRE ATT&CK tactic and technique, event counts, first and last seen, sample events, and the alert and tickets it raised.

Every value links on: the customer and device to their pages, an address or user to the events for it, the rule to its page, and the technique to MITRE's site. Press Open detection for the full page.

The detection page#

The full page shows the same, with more room:

• The header: severity, status, any importance badge (VIP, or the device's criticality), Open in event search (the exact search the rule ran, over the detection's time), Take it (or Take it over when someone else has it) and a menu with Resolve, False positive, Assign to and unassign.
• Why it fired: in plain words, with the numbers against the threshold, for example "34 (threshold 10)", and everything the rule worked out about it (where an MFA registration really came from, how many downloads were counted) from the moment it is recorded. Addresses on a threat intelligence list carry a Known bad badge: see Threat intelligence and MITRE coverage.
• Found by: each source that found it, when more than one did (see below).
• Response and Incident: the time left to take or resolve it, and the incident it belongs to, if any.
• Evidence: events pinned to it, kept after the event store lets them go.
• Sample events: a timeline of up to ten of the events it saw. Click one to see the whole event.
• Notes: every note and status change, with who and when.
• AI, Details, Alert and tickets, Telling the customer and Related: other detections for the same user, host, address or device in the last week.

Working a detection#

1. Take it. Press Take it (or t). It becomes yours and Investigating. To give it to someone else, use Assign to in the menu; they are notified.
2. Investigate. Use Open in event search, the sample events and Related to see what happened before and after. Check the device page and the user in Microsoft 365.
3. Write notes as you go. Type in the notes box and press Add note (or Cmd+Enter). Attach files adds screenshots or exported logs (or paste or drop them). Notes are for whoever looks next.
4. Close it. From the menu choose Resolve or False positive, with a note, and answer How did it end?: actioned, false positive, Expected or harmless, our own work or vendor routine. The answer feeds each rule's noise figures (see Detection rules and suppressions).

When the detection belongs to an incident that has other open detections, the same dialog asks whether to close Just this one (the default) or All of them: all of them closes the incident and every open detection in it with your note. Bulk closes on the list ask the same per incident. Closing the last open detection of an incident closes the incident too: see Incidents and response.

Closing a detection clears the alert it raised, and resolving that alert (by hand, by automation or with its ticket) resolves the detection with the alert's note. Reopening it raises the alert again. Events already counted towards a closed detection never count towards a new one, so a resolved detection does not come back from the same events.

Tip: From the menu you can also Raise ticket, pin events as evidence and Notify the customer, on any detection, including ones below the alerting severity. See Incidents and response.

Found by more than one source#

A security console's alert and a rule's detection of the same action are one detection, not two. When Microsoft Defender raises "Permission on mailbox" and the Mailbox permission granted rule finds the same audit event, the detection says "Found by Microsoft Defender and the Mailbox permission granted rule", carries the higher of the two severities and both sets of evidence, and raises one alert. They are joined when they are about the same customer, account and target, the same kind of action, and close in time: within 10 minutes by default (Merge a vendor alert with a rule's detection of the same action within, on the Integrations tab of Settings > Security monitoring; 0 keeps them apart).

The Found by section lists each source with what it said, its time window, why it was joined and, for a console, the alert in the vendor's console. Separate gives a source back its own detection, with its own number, status and alert, and Merge another detection in joins one by its number. When the vendor resolves its alert, the detection gets a note and stays open while a rule's finding still keeps it open.

In the same way, when two rules see the same events on one device, the second is added to the open detection as an "Also" line rather than opening a detection of its own.

When a detection raised no alert#

The Alert and tickets part of a detection says why when it raised no alert, for example "No alert: Low is below Medium, the least that raises one (Settings > Security monitoring > Alerting)." or that the customer is in takeover mode and is watched only. Other reasons are an onboarding or first-scan findings window, the alert type switched off, a noise rule, a PowerShell detection waiting for the AI, or Tenvara's own activity.

People who manage security can press Raise an alert anyway: the alert is raised past the threshold, the customer's mode, the alert type switch and the noise rule, a note says who raised it and why it had none, and it is audited. High and Critical detections at a customer in takeover mode raise alerts anyway while High and Critical detections alert in takeover mode is on (on by default, on the Alerting tab of Settings > Security monitoring).

AI on detections#

When AI is set up with your own Anthropic key and the Security AI feature is on (see Setting up AI), each detection has an AI card:

• Explain with AI reads the detection, related detections and the events around it with read-only tools, then answers what the rule saw, why it matters, whether it looks likely benign, likely malicious or unsure (with a confidence and reasons), the next steps and the event searches worth running. The answer is posted as a note marked as AI and kept as the detection's verdict. It never changes the detection's status: a person still decides.
• Ask AI takes a question about the detection or incident ("did this account sign in from anywhere else this week?") and posts the answer as a note.
• Triage new high and critical detections with AI (the Response tab of Settings > Security monitoring, per customer) gives each new high or critical detection a suggested verdict as soon as it is recorded, shown as Automatic triage. A verdict below the lowest confidence you set (70% by default) shows as unsure.

Every run counts against the AI caps, is listed on the Activity tab of Settings > AI with what it looked at, and is refused clearly for a customer who has opted out of AI.

VIPs and critical devices#

Some people and machines matter more: the managing partner's mailbox, the domain controller. Mark them once and every detection, alert and ticket about them says so.

• VIP people: give a contact the VIP contact role. A Microsoft 365 user linked to that contact is a VIP too; a user with no contact can be marked VIP on their own from Cloud > Users.
• Device criticality: set a device to low, normal (the default), high or critical from its page's menu, Edit, or Set criticality on several devices at once.

Detections about a VIP's account, or on a high or critical device, show a badge and are recorded one severity higher, with the reason ("Raised because the device is high criticality, from High"). The list's Importance column and filter, and the VIP and critical view, find them. The VIP and critical tab of Settings > Security monitoring decides whether detections are raised, which devices count as important (high and critical, or critical only), whether alerts on critical devices are raised, and whether new tickets from VIPs or about critical devices get the next priority up (off by default). A repeat never raises twice.

Your own Microsoft 365 app#

Tenvara connects to each customer's Microsoft 365 through its own app, for backup and management. When Microsoft Defender raises an alert about that app (for example unusual downloads after a credential was added), or Microsoft records consents and role grants to it, Tenvara checks it against what it was doing at the time: its backups, syncs and changes, the addresses they came from, and any secret it added.

Consents to your own app given from inside Tenvara count as explaining the matching events: updating the app registration, Fix it for me and the admin consent that follows, the partner sign-in, connecting or reconnecting a tenant, turning on a feature that needs consent, and the directory roles Tenvara gives its own app. A download is never explained by a consent: it still needs a backup or export at the time.

Each event Microsoft saw is judged in its own window: its time, plus or minus Time around a job that still counts (30 minutes to start with, on the Our own apps tab of Settings > Microsoft 365). The detection's panel lists What Microsoft saw, and what Tenvara did at the time: each event with its time and window, and under it the actions that explain it, with who did them, or Nothing of Tenvara's at that time. The reasons name only the events nothing explains. An event found unexplained stays so until a person decides: a later action never explains an earlier event.

• Explained (every event is covered, and nothing else, such as an unknown address or a secret not added through Tenvara, says otherwise): the detection is marked Our app, expected, rated information, kept out of incidents and off the response clock, shows what Tenvara did at the time, and is closed as expected straight away.
• Not explained: it stays at least high, marked Our app, NOT explained, with "Treat it as a possible stolen credential until you know otherwise" and the reasons. It goes through the normal alert, incident and response clock, and cannot be closed as expected.

Explained detections close as expected by themselves, with a note listing the actions and who did them; several explained events of the same kind in one day join one closed detection rather than one each. Someone who reopens an explained detection has the last word: it is never closed again automatically. Add your Tenvara server's public addresses on the Our own apps tab of Settings > Microsoft 365 so the addresses can be checked too. Suppress in Microsoft Defender explains how to tune the alert in Defender itself.

A tool's routine scripts#

Management and security tools run PowerShell of their own as SYSTEM: inventories, health checks, patching. Some of it looks like an attack (a script written to a temporary file and run from Base64), so it can raise Suspicious PowerShell script every time it runs, typically at a customer you are taking over while the previous provider's agent is still installed.

The rule already weighs where a script came from (its folder, who signed it, what started it and how common it is) and scores the whole script, so most vendor scripts never fire. For the ones that do:

1. Open the detection and press This is routine for a tool (in the panel above Why it fired, or in the menu).
2. Choose the tool from the list, or type another tool's name.
3. Choose the scope: this customer only, or every customer.
4. Choose the match: Same script, any values (the same code with different temporary paths, dates and numbers) or Exactly this script.

The detection closes as a false positive with the note "Routine for" and the tool, and so does every other open PowerShell detection whose scripts are all on the list. Later runs of the same script are stored as routine for that tool: still searchable in events, but they raise nothing. A changed script is scored again from scratch.

The list is on the Known tools tab of Settings > Security monitoring: each entry with the tool, the script, the customer, the match, how often it was seen in the last 30 days, who added it and Remove. For a customer in takeover mode, the detection suggests the outgoing provider's tool for you.

False positives#

When a detection is not a problem (a backup agent's scheduled task, a rollout's new service), mark it a false positive:

1. Choose False positive from the menu (or press f).
2. Enter a Note saying why it is not a problem.
3. Tick Do not show hits like this again to add a suppression in the same step, for the rule, the customer and the values it was grouped on, with an expiry.
4. Press Mark as a false positive.

Suppressions are listed on the Suppressions tab of Security > Rules; see Detection rules and suppressions.

How detections are kept tidy#

• Repeats merge. Further hits for the same rule and the same values within the rule's window join the open detection: the event count grows, the times widen and the severity can only rise. Some rules keep one open detection that grows for a day, so a password spray is one detection listing every address seen so far.
• After a quiet spell, a new hit opens a new detection beside the old one.
• Daily summaries. Routine findings such as signed services installed in protected folders are gathered into one information detection per device, rule and day ("Services installed on HOST-01: 12 signed services in protected folders"), listing each item. It raises no alert and closes when the day ends.
• Undone within the grace. Defender or the Windows firewall switched off and back on within 10 minutes closes as harmless, with a note, instead of telling anyone.
• Our own work. Agent updates, scripts, patch runs, scans, backups, syncs and Tenvara's own changes in Microsoft 365 are recorded as they run, and a detection they explain is closed as our own work at information level. Your own server, sensors and other addresses are listed under Our own work in Settings > Monitoring.
• Integration findings (Microsoft Defender, SentinelOne) are detections too, one per vendor alert. While one is open, each sync refreshes its title, subject and evidence from the vendor. When the vendor resolves an alert, the detection follows with a note; for SentinelOne, resolving the detection in Tenvara can resolve the threat in the console.
• Rule updates judge open detections again. When an update narrows a built-in rule, each open detection it raised is checked against the new conditions. One that no longer matches closes as a false positive with the note "No longer matches rule version" and the number, and its alert clears.
• Closed automatically. A detection Tenvara closes itself (a vendor resolving its alert, a rule update, a daily summary, an explained alert about your own app or your own work) says Closed automatically and is left out of the mean time to resolve.
• One consent, one detection. An application consent in Microsoft 365 is one detection however many records Microsoft writes for it, and an inbox rule is only treated as suspicious when it carries a sign of an attacker.
• Names, not ids. Microsoft 365 detections name the mailbox and the person, for example "Mailbox permission granted: Marketing (shared mailbox) to priya.shah", even when Microsoft's record only held object ids.

Alerts and tickets#

A detection at or above the alerting severity (medium by default) raises an alert in the Alerts list. Your alert rules can open a ticket from it, which resolves when the detection closes. Both are linked under Alert and tickets. See Integrations and alerting.