Tooling is the easy part
Buying a SIEM is straightforward. Making it useful is not. Most failed deployments we inherit have the same profile: logs from half the estate, hundreds of default rules nobody tuned, and an alert queue everyone has learned to ignore.
A SOC is a process supported by tooling, not the other way around. Get the process right and even a modest open-source stack outperforms an expensive platform nobody watches.
Get log coverage before detection rules
Detection can only see what is ingested. In priority order, we onboard:
- Firewall traffic and threat logs, including denied outbound
- Active Directory authentication and privilege changes
- Endpoint protection alerts and process telemetry
- VPN and remote access sessions
- Critical application and database audit logs
Retention matters as much as ingestion. Investigations routinely look back 30 to 90 days, and most audits expect at least a year of searchable history.
Fewer, better detections
We would rather deploy twelve tuned detections than four hundred defaults. The ones that consistently earn their place:
- Impossible travel and unusual geography on VPN or cloud sign-in
- Brute force followed by a successful authentication
- New privileged group membership outside change windows
- Endpoint alert on a server, not just a workstation
- Outbound traffic to newly registered or known-bad domains
- Disabled security tooling or cleared event logs
Each one needs a written response step. An alert without a runbook is just noise with a timestamp.
Someone has to be awake
Attackers do not respect business hours. The majority of the intrusions we have responded to began between 10pm and 5am local time. If a three-person IT team owns detection, the realistic mean time to detect is the following morning at best.
That is the actual argument for SOC as a service: continuous triage, a defined escalation path and named engineers who answer the phone. Our SOC clients typically see mean time to detect drop from days to minutes within the first quarter.