Log management: start with the questions you need to answer
Collect the right events, protect the evidence and decide who takes action. The volume of log data does not measure how useful the monitoring is.
Start with how it will be used
Which events do you need to detect or investigate? These might include logins, changes to permissions, administrator actions or anomalies in an important service. Define the questions before deciding which logs to collect.
Distinguish between records needed for operations, incident investigation and audit. They may overlap, but do not always require the same detail, availability or retention periods.
Build a clear sequence of events
Choose relevant sources and check that their information can be interpreted together. Time, system, event type and relevant identity need to be consistent enough to trace a sequence of events.
Test with real events. Also check what happens when collection is interrupted or a source stops sending data. A silent log source does not necessarily mean that everything is working.
Protect the logs too
Logs may contain personal data and sensitive technical information. Restrict access, protect against unauthorised changes and decide which data actually needs to be retained. Retention periods should be based on needs and applicable requirements, not simply on the availability of storage.
Decide who follows up
- Which events should trigger an alert or a regular check?
- Who receives alerts, during which hours and with what authority?
- How is a suspected incident investigated and documented?
- How are rules adjusted when the environment or risk landscape changes?
The tool needs a working process
A SIEM can support collection, analysis and alerting, but its value depends on the sources, rules and staffing. Request a clearly scoped service description: what does monitoring cover, which actions can the provider take and what does your organisation need to do? Review the solution through exercises and real incidents.
Sources and further reading
Sources reviewed .
