Most organisations we work with are not short of security tools. They have a firewall, they have antivirus, sometimes they have bought an expensive EDR product too. But when we ask "where do all their logs end up?", the answer is usually silence.

The real problem isn't missing tools

Suppose an attacker gets into one of your servers using a leaked password. In a typical environment, the trace of that event is scattered across several places:

  • A successful login in /var/log/auth.log on that server
  • An unusual outbound connection in the firewall log
  • A new process that only the host agent saw
  • A configuration file change nobody recorded

Individually, each of these means nothing. Together they tell the whole story of the intrusion. But if they live in four separate systems, nobody ever puts them side by side.

In organisations without centralised logging, mean time to detection is measured in months, not hours.

What centralising actually means

Centralising is not "copy the files onto one server". It has three requirements:

  1. Complete collection — every source, not just the important servers. An attacker comes in through the weakest point, not the most important one.
  2. Normalisation — firewall logs, Linux servers and Active Directory each use a different format. Until they share a common structure, cross-source search is impossible.
  3. Trustworthy retention — if an attacker can delete the log, the log is worthless. Retention belongs on a separate, ideally append-only system.

Where to start

If you have nothing today, this order gives the best return:

1. Authentication  → successful and failed logins, password changes, new users
2. Network         → outbound connections, DNS, blocked traffic
3. State change    → file integrity, package installs, service changes
4. Application     → 5xx errors, failed authentication, sensitive path access

Step one alone makes more than half of the common intrusion scenarios detectable. And contrary to expectations, it takes days to implement, not months.

The part people forget

Collecting logs without alert rules is just an expensive data warehouse. For every source you add, define at least one specific question that source is supposed to answer. For example: "did any user log in outside working hours from an unknown IP?"

If you can't write such a question for a source, postpone collecting it. Aimless volume is exactly what stops teams reading their alerts.

In summary

Before your next purchase, measure this: if an account were compromised right now, how many minutes until you knew? If the answer is "I don't know", centralised logging is your first priority — not the next tool.