Cybersecurity · Visibility

SIEM and Log Management

After an incident, every important question is a question about logs. Who signed in, from where, at what time, and what did they touch? If the answer is 'we only keep thirty days', the investigation ends early and so does the insurance conversation.

Log management is the unglamorous foundation of security work: collect the right events, keep them long enough, and alert on the handful of patterns that matter.

The problem

Logs exist, but usually not where or for as long as you need

By default, most environments keep a short window of activity, scattered across systems: the firewall keeps its own recent events, the server overwrites its logs when the file fills, and cloud audit data is retained for a period that varies by licence.

Worse, an attacker with administrative access can clear local logs. Evidence that lives only on the compromised machine is evidence you may not have.

Centralizing changes both problems. Events are copied off the source system as they occur, held for a defined period, and searchable in one place — which is the difference between reconstructing an incident and guessing at it.

What we do

Building useful visibility

  1. 01

    Enable the logging first

    Unified audit logging in Microsoft 365, mailbox auditing, directory events, PowerShell and process logging on servers, and appropriate firewall logging — a surprising number of environments have never turned these on.

  2. 02

    Collect centrally

    Events copied to a central platform outside the reach of a compromised local administrator, with integrity protection on the stored data.

  3. 03

    Keep what matters, for long enough

    Retention set with intent: long enough to investigate a slow-burning compromise and to satisfy contractual or regulatory obligations, without paying to store trivia forever.

  4. 04

    Correlate the signals

    Rules that combine sources — an impossible-travel sign-in followed by a new inbox rule and a file-share access spike — because the pattern is the detection, not the individual event.

  5. 05

    Alert on a short list

    A deliberately small set of high-value alerts: administrative role changes, MFA method changes, mass downloads, protection disabled, new remote-access tooling. Long alert lists get ignored.

  6. 06

    Keep it searchable and tuned

    Queries prepared for the questions asked during incidents, and regular tuning so noise falls rather than accumulating.

Security considerations

Retention and privacy both need decisions

Log data contains personal information — who accessed what, when and from where. Collection should be proportionate, access to the data should be limited, and retention should be a documented choice rather than an accident of a default setting.

We define what is collected, who can query it, how long it is held and how it is disposed of, and record that in the same governance documentation as the rest of the security programme.

  • Documented retention periods
  • Restricted query access
  • Personal data minimisation
  • Defined disposal process
  • Audit of log access
  • Alignment with privacy policy

Where this fits

Assurance work like this sits alongside the day-to-day controls described on our St. Catharines cybersecurity page.

Questions

Frequently asked questions

Do smaller organizations really need a SIEM?
They need centralized logs and a small set of alerts. Whether that is a full SIEM platform or a lighter managed solution depends on size, obligations and budget — the requirement is retention and searchability, not a particular product.
How long should logs be kept?
Six to twelve months of identity and endpoint activity is a sensible baseline for most businesses, because compromises are often discovered months later. Contractual or regulatory requirements can extend that.
Is this the same as monitoring?
Logging provides the data; monitoring is someone reviewing and acting on it. Managed detection and response is the service layer that turns collected logs into a response.

Next step

Talk to Griffin IT Group about your St. Catharines IT environment

Tell us how your technology is set up today and what is getting in the way. We will walk through your environment, outline the gaps we see and recommend a practical path forward.