What is a SIEM, and how do you approach security monitoring and log analysis?

A SIEM (Security Information and Event Management) platform centralises logs from across the estate, correlates events, and raises alerts. Its value is correlation: a failed login on one system is noise, but failed logins across twenty systems from one source followed by a success is an attack, and only a central view reveals that.

What to feed it, in rough priority:

• Authentication logs — domain controllers, VPN, cloud identity providers. Most attacks involve credentials at some point.
• Endpoint detection and response telemetry — process creation, and parent-child relationships, which is where malicious activity actually shows.
• Firewall, proxy, and DNS logs for command-and-control and exfiltration.
• Cloud audit logs — CloudTrail or Azure Activity Log.
• Critical application and database logs.

Making it work:

• Start with high-fidelity detections rather than enabling every rule. A SIEM producing 500 alerts a day is ignored, which is worse than no SIEM.
• Tune continuously. Every false positive should either be suppressed or the rule refined.
• Map coverage to MITRE ATT&CK to find gaps deliberately instead of hoping.
• Protect the logs. Ship them off-host immediately and make them immutable — attackers clear logs, and a log an attacker can delete is not evidence.

Note: Measure with mean time to detect and mean time to respond. Alert volume is not a success metric.