Investigations
Search is where you answer questions the alert queue cannot: what else did that account do, when did this first happen, what else touched that host.
Search works without detection enabled. Events are searchable as soon as they are stored, so the entire investigation surface is available on a collect-and-search organization that has never turned a detection on. That is also the cheapest way to validate collection end to end.
Event categories
Events are normalized into one model and stored by category. Knowing the categories is how you narrow a search quickly:
| Category | Covers |
|---|---|
| Endpoint | Process, file, and host activity |
| Network | Traffic, firewall, and appliance logs |
| Identity | Authentication, directory, and access changes |
| Cloud | Control-plane and audit activity |
| Application | Application and web server logs |
| Mail flow and message events | |
| Container | Container and orchestration activity |
Normalization is what makes one query span a firewall, a cloud audit log and an endpoint agent. The source's original fields are preserved alongside the normalized ones, so you can always get back to exactly what the device said.
Searching
Start from what you know and widen:
- An indicator - an address, a hostname, an account, a hash.
- A window. Bound the time range before adding conditions; it is the single biggest factor in how fast a search returns.
- A category, once you know roughly where to look.
The common investigation shape is a pivot rather than a single query: find one event, take an identifier off it, search that identifier across categories, repeat. An account name from an identity event pivots to endpoint activity; a host from endpoint activity pivots to network.
Identity activity
A dedicated view of authentication and directory events, because identity is where most investigations either start or end.
It is vendor-agnostic - Entra ID, cloud providers, and anything else that reports authentication normalize to the same shape - so "everything this person did" is one question rather than one per directory.
Worth looking at when you are asked:
- Where has this account signed in from, and when did that change?
- What directory changes happened around an incident?
- Which accounts were touched by the same source?
What you can and cannot find
Only what was collected. A source that is not sending logs leaves no trace, and an empty result means "nothing was recorded" rather than "nothing happened". If a search comes back empty for something you are confident occurred, check Telemetry and collection before concluding anything.
Only within retention. Events age out on the retention you have. Beyond that they are in archive tiers or gone, depending on what you purchased.
Regardless of detection tier. A source set to search rather than detect is fully searchable - it simply is not evaluated by rules. That is exactly the trade for high-volume sources: still there when you need them in an investigation, not paying detection cost on every event. See Detection engineering.
From a search to a detection
An investigation that finds something worth catching next time becomes a rule. Write it, then use Replay to test it against the history you just searched - that tells you both whether it catches the thing and how noisy it would have been, before anyone is paged.
API
The endpoints behind this section are in the API reference.
Next
- Detection engineering - turning a finding into a rule
- Monitor and respond - the alert and incident queues