Home / Knowledge hub / Logging and monitoring
Knowledge hub
Logging and monitoring
Recording what happens, and actually watching what gets recorded.
What it means
Logging records what the system did: who signed in, what changed, what failed, what the application refused. Monitoring is the second half, where a person or a rule reads those records and raises a hand when the pattern looks wrong.
Most organisations have the first without the second. Data piles up, nobody reads it, and the one field that mattered turns out to be missing when somebody finally goes looking.
Why it matters
Intrusions usually run for weeks before anyone notices, and the evidence usually sits in the logs the whole time. The gap is attention rather than collection, and every quiet week is another week of data leaving.
Logs also decide whether you can answer questions later. When a customer or a regulator asks which records somebody reached, you either answer precisely from your logs or you describe a worst case. The worst case is what you end up notifying people about.
How it shows up
OWASP gives a good starting list: authentication successes and failures, access control failures, permission changes, access to sensitive data, imports and exports, file uploads and administrative actions. Its other list matters more. Never log passwords, session values, access tokens, keys or card data, because a log file is a copy of your data with weaker controls around it. Keep the audit log apart from debug output, since the two have different readers.
Then check the details that get skipped. Retention long enough to investigate something discovered in three months. Clocks synchronised, so you can line two systems up. Alerts on a handful of meaningful events, because an alert nobody can act on teaches people to ignore the next one.
Questions people ask
Logging and monitoring, answered
What should we log?
Security-relevant events, not everything. Sign-ins and failures, password and email changes, permission changes, access to sensitive records, bulk exports, administrative actions, and anything the application refused.
Include enough context to identify the account and the record. A line that says an error occurred helps nobody three months later.
What should we never log?
Passwords, session identifiers, access tokens, connection strings, encryption keys and payment card data. Personal data needs a deliberate decision rather than a default.
Logs travel further than databases do, into backups, dashboards and third party tools, usually with weaker access control at every stop.
How long should we keep logs?
Long enough to investigate something you discover late. Seven days will not cover an intrusion found in month three.
Many teams keep detailed logs hot for a few weeks and archive longer. Match the period to how long your incidents realistically take to surface, and to whatever your sector requires.
We have logs but nobody reads them. What now?
Alert on a short list rather than on everything. Pick events that mean action: a new admin, a bulk export, repeated authentication failures against many accounts.
Every alert that fires without requiring a decision trains the team to ignore the next one, so prune ruthlessly.
Do we need a SIEM for this?
Not at first. Centralised logs with synchronised clocks and a handful of alerts already put you ahead of most organisations.
A platform helps when the volume outgrows people, or when you need correlation across many systems. Buying one before you know which events matter tends to produce an expensive archive.
Related
Terms that sit next to this one
Audit log
A record of who did what and when, kept so you can answer later.
Incident response
The agreed plan for the hours after something has gone wrong.
Data breach
Information you hold ends up somewhere it should not be.
Brute force
Trying passwords or codes over and over until one of them works.
Enumeration
Working out what exists by asking repeatedly and watching the answers.
Would you see us coming?
Run a Cyberlop scan, then read your own logs. If a week of testing traffic left nothing worth alerting on, better to learn that now than later. Pilots run 30 days on one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.