Security Operations
Security Operations is the SIEM: it collects logs from your estate, normalizes them, makes them searchable, and - if you turn it on - runs detections against them and raises alerts.
That conditional is the most important thing on this page.
The default is collect and search, nothing else
A new organization is collecting logs and doing nothing else with them. Ingestion, normalization, enrichment, storage and search all run. Detection and alerting do not.
Three switches, all off until you turn them on, under Detection Engineering → Alerting:
| Switch | Default | What stays off |
|---|---|---|
| Detection | Off | Events ingest and are searchable, but no rule ever matches |
| Alerting | Off | The organization-wide alert switch |
| AI triage | Off | No alerts enter the analyst queue |
So a freshly connected organization will show you logs and find nothing in them. That is working as intended, not a misconfiguration - and it is the single most common misunderstanding about this part of the product.
Turning an organization on means flipping those switches. Roles that can: soc_analyst,
org_admin, staff, superuser.
Analysis spends tokens, so it fails closed. If the service that gates it is unavailable, triage stops rather than proceeding - an outage can never start spending on your behalf.
What happens to an event
your sources ──▶ collection ──▶ normalize ──▶ enrich ──▶ store
│
detection ◀────┤
│ │
alerts search
Collection gathers from log agents and collectors you deploy, from cloud and identity providers, and from connected security vendors. See Telemetry and collection.
Normalization maps every source into one event model, which is what lets a single search span a firewall, a cloud audit log and an endpoint agent.
Enrichment adds context the raw log lacks - geolocation, IP reputation, and the asset tags you have already set.
Storage keeps events searchable for a base retention period, with longer retention purchasable per event category.
Detection evaluates rules, if you have enabled it.
Events are searchable as soon as they are stored. Nothing about detection has to be configured for search to work.
Where things are
| Section | For |
|---|---|
| Telemetry and collection | Getting logs in |
| Detection engineering | Rules, tuning, and what costs what |
| Monitor and respond | Alerts and incidents |
| Investigations | Searching events |
| Endpoint security | Devices, policy, and response |
Getting started
- Get logs flowing. Telemetry and collection. Confirm events are searchable before going further.
- Search them. Confirm you can find a known event. This validates collection end to end and costs nothing.
- Review your data sources. Which sources are evaluated by detections is the largest cost control in the SIEM, and it is worth deciding before you switch detection on rather than after. See Detection engineering.
- Turn detection on and let it run without alerting for a period. You will see what would have fired without anyone being paged.
- Tune, then enable alerting. Alerts nobody trusts get ignored, and the fastest way to get there is to enable alerting on an untuned rule set.
Events collected before detection is enabled stay searchable, and rules can be replayed against history. Taking time over steps 3 to 5 costs you nothing but time.
What you keep
Event data is retained for a base period, extendable per event category. Two things worth knowing:
- Ageing does not rewrite anything. Older data moves to cheaper storage; it is not transformed or summarized.
- Legal holds block every deletion path for their scope, including organization offboarding. A hold is released, never deleted - so "was this preserved?" always has an answer.