Logs as a data source, not garbage: what you can see before you have a SIEM

In most companies, logs exist because that is how software works: it writes them by default. They rotate somewhere, sometimes get archived, and are consulted in two situations: when something breaks, or when an auditor arrives.

That is a missed opportunity. Logs are a continuous record of what is happening in a system. Signals can be extracted from them long before a company grows into a SIEM or a specialised monitoring platform. The same principle applies more broadly: the first question is always inventory - knowing what data you already have before reaching for a platform.

What logs actually contain

Operating systems, web servers, databases, and business applications record different things, but in most cases logs contain:

• who did what and when (user identifier, timestamp);
• what exactly was done (request, operation, change);
• where the request came from;
• whether the action succeeded and if not, which error code;
• how long execution took.

Those are five dimensions, each carrying meaning. Together they make it possible to answer questions that otherwise have no answer.

What you can see without special tools

Even simple analysis of text logs with standard command-line tools yields a great deal:

• Activity anomalies. A user who normally works business hours suddenly generates requests at 3 in the morning. Or the volume of requests to a specific resource jumps by a factor of 20 in an hour.
• Authentication failures. A sequence of failed login attempts under a single username is either a forgotten password or a brute-force attempt. The difference is visible in the pattern.
• Slow operations. Queries that have become significantly slower than usual often signal performance degradation or unexpected load.
• Access to rarely-used data. If data that nobody normally requests suddenly starts being queried - that is worth noticing.

None of this requires a SIEM. It requires the habit of looking at logs regularly, not only after an incident.

Logs as audit material

In regulated industries - finance, healthcare, the public sector - logs are often the only evidence of what happened. "Who deleted that record?" If logs are not retained, or are retained without controls, there is no answer.

A basic audit trail requires very little:

• record all data changes with the user identifier and timestamp;
• store logs in a location where a regular user has no write access;
• set a retention period based on business or regulatory requirements;
• ensure that timestamps across different systems are synchronised.

This is not a SIEM. It is discipline.

Logs as analytical material

Beyond security and audit, logs are a source of operational data. A web server knows which pages are opened most often, which requests end in errors, where users are coming from. A database knows which queries consume the most resources.

This data is often more valuable than what the company collects deliberately - because it does not depend on JavaScript trackers, browser settings, or a user's willingness to accept cookies.

Where to start

If logs are currently just files that nobody reads, the reasonable first step is not buying a platform:

1. Identify which logs exist and where they are stored.
2. Verify that they contain enough information - especially user identifiers.
3. Set a retention policy - how long and where.
4. Assign an owner - who reads them and when.
5. Agree on one basic anomaly dashboard that someone looks at once a day.

The tool will come later. The habit and the process come first.