Logs and SIEM: turning millions of events into a few good alerts

Almost everything a computer does can leave a trace: a login, a failed password, a new program installed, a connection to a server abroad. These traces are logs. On their own, most log lines are boring. Together, collected in one place and read in context, they tell the story of what happened, and they are often the only way to prove it afterwards.

Why logs matter

NIST’s guide to log management (SP 800-92) describes logs as essential for identifying security incidents, policy violations and operational problems, and for supporting investigations. CISA’s guidance on event logging makes the same point from the other side: when an incident happens, organisations without good logs often cannot say how the attacker got in, what they touched or whether they are still there.

What to log

Logging everything is expensive and makes the useful lines harder to find. Logging too little leaves blind spots. A reasonable starting set covers the places attackers must pass through:

• Identity: sign-ins, failed sign-ins, multi-factor prompts, password resets, new administrator accounts.
• Endpoints: processes started, software installed, security settings changed, persistence items added.
• Network: connections in and out, DNS lookups, firewall decisions, VPN sessions.
• Cloud and SaaS: changes to permissions, sharing links, storage made public, API keys created.
• The logging system itself: when logs stop arriving from a source, that silence can be the alert.

Two details make logs trustworthy. Clocks must be synchronised, or you cannot put events in order across machines. And logs should be sent off the machine that produced them, because an attacker with control of a computer can also edit its local logs.

What a SIEM does

A SIEM, for Security Information and Event Management, is the system that collects logs from many sources, normalises them into a common format, stores them and lets analysts search and correlate them. Well-known examples include Splunk and the Elastic stack (Elasticsearch, Logstash and Kibana, often called ELK), alongside cloud-native services from the major providers. The product matters less than what you do with it.

Correlation: the real value

A failed login is normal. A thousand failed logins against different accounts from one address is a password-spraying attempt. A successful login from a new country followed within minutes by a mailbox rule that forwards all mail outside the company is a classic sign of a compromised account. None of those events is alarming alone; the SIEM’s job is to see them together.

Fighting alert fatigue at the source

• Start with a small set of high-value detections and tune them until they are rarely wrong.
• Add context to every alert automatically: who owns the machine, what the user normally does, whether the address is known.
• Review each rule’s track record regularly, and retire rules that never catch anything real.
• Write a short playbook per alert type so triage is consistent across analysts and shifts.

Logs on a single Mac

macOS keeps its own unified log, which is detailed but hard to read without practice. For network activity specifically, FireAI keeps a local connection history that shows which app connected where, newest first, and lets you search the last seven days in plain language. Like any good log, it stays on the machine that produced it and never goes to a cloud service. It is not a SIEM, but it answers the same first question an analyst asks: what did this machine talk to, and when?