A SIEM (security information and event management) collects logs from firewalls, servers, Microsoft 365, endpoints, and similar systems, then correlates them so a person can see an attack that no single log would show. A firewall entry, a server sign-in, and a new mailbox rule can each look ordinary on their own. Together they can describe someone getting in, moving, and leaving a way back. This guide covers what a SIEM is, why a pile of logs is not the same as watching them, what monitoring looks like day to day, and five questions to ask before you hire it out.
Examples of what to collect, not a complete inventory. CISA’s small-business logging page names servers, firewalls, endpoint devices, and cloud services as places to turn logging on.
What is a SIEM?
NIST’s computer-security glossary, citing Special Publication 800-92, defines security information and event management as “a program that provides centralized logging capabilities for a variety of log types.” A second entry, from SP 800-128, describes a SIEM tool as an application that can “gather security data from information system components and present that data as actionable information via a single interface.”
In plain terms, the logs are the records. A SIEM is where selected records are brought together, compared, and turned into something a person can act on. “Actionable” is the point of the NIST wording. A folder of files is not.
CISA and partner agencies describe the setup in Best Practices for Event Logging and Threat Detection (August 2024). The full text, hosted by New Zealand’s NCSC, a co-author, recommends a protected central store for logs, then forwarding selected, processed logs to analytic tools such as a SIEM. Many network devices have little local disk. When that disk fills, older records disappear. The guide also notes that some attackers change or delete logs on the machine they are using. A copy held somewhere else is harder to erase.
A pile of logs is not a SIEM
CISA’s small-business page separates the two jobs. Logging is “the process of recording this activity on your business systems, including who accessed what, when, and from where.” Monitoring “adds a layer of oversight by reviewing those logs in real time to identify anomalies or unauthorized behavior.” Recording is not the same as looking. CISA also describes a red-team exercise in which the intrusion was found by analyzing network and log data that flagged unusual activity. The logs mattered because someone used them.
Microsoft’s guidance on centralizing security logs says the same thing from the investigation side. Logs “reveal who accessed what, when, and how.” Without centralization and consistent formats, though, “logs can create more problems than they solve.” Different formats, scattered storage, and uneven retention “make it difficult to quickly piece together a complete picture of an attack.” Bringing logs together, Microsoft writes, simplifies correlation: matching an event in one system to an event in another, instead of searching each system by hand.
| Logs left where they land | A SIEM | |
|---|---|---|
| Where the record lives | On each firewall, server, PC, or cloud service, until that device’s own storage fills or someone clears it | Selected logs are copied to a central store, then the ones that matter are available in one place |
| What you can see | One line, in one system’s format. A failed login or a new inbox rule can look routine. | Related lines from more than one system, compared with what normal looks like for that account or device |
| Who is looking | Often nobody. The record exists in case someone asks later. | Alerts are meant for a person who can tell noise from something that needs a decision |
| After an incident | Local logs may already be gone, overwritten, or deleted | A retained copy is what lets someone reconstruct what happened |
In short: Logs are the notes each system keeps. A SIEM is how those notes get read side by side. Monitoring is a person acting on what that reading shows.
How SIEM monitoring works, day to day
Buying the software is not the same as running it. Day to day, the work is a short path: collect, correlate, alert, a person reviews, and you get a clear next step.
Collect
Turn logging on for the systems that matter, and send those records to a central store. CISA’s starting list is user activity, admin actions, network traffic, application logins, and system events, from servers, firewalls, endpoints, and cloud services such as Microsoft 365. The joint logging guide says to forward selected logs to a SIEM, not every line a device can produce. Filtering is how you keep storage and noise under control.
Correlate
This is the step no single log can do. The joint guide says SIEMs “can detect anomalous activity by comparing event logs to a baseline of business-as-usual traffic and activity,” including what is “always abnormal” for a privileged account. Microsoft describes the same job as correlating events across services instead of opening each log by hand. For example, a failed remote login at an odd hour, a new inbox rule, and a large download are a story only when they are read together. Any one of those lines can look routine. That example is an illustration, not a reported incident.
Alert
The joint guide says an effective logging setup should “send alerts to the network defenders responsible for monitoring” when something notable happens, and should “reduce alert noise.” CISA tells smaller businesses to set alerts for high-risk events, such as failed logins and privilege changes, and to review logs rather than only store them. An alert nobody receives is another file.
A person reviews
The same guide lists patterns worth a look: a sign-in at an odd hour, an account touching systems it never uses, one address trying many usernames, a large download, or logs being cleared. It then says those patterns “could be legitimate behaviour and not malicious activity,” and that “further investigation by a network defender is required.” Good logs help that person tell a false positive from a real event. The software does not close the question.
A clear next step
An alert that nobody turns into a decision is still just a log. The next step might be to disable an account, call the person, check a firewall change, or mark the alert as noise and tune the rule so it does not fire on ordinary work. That judgment is ordinary practice. It is not a timer, and it is not a promise about how fast anyone will answer.
Retention, and who can delete the record
The joint guide says to keep logs long enough to support an investigation, and that default retention is often too short. How long depends on the risk to the system and on rules that already apply to you. There is no single number that fits every company. CISA says to retain logs according to your own policies and compliance needs, and to protect them from unauthorized access or deletion. A SIEM that an attacker can wipe is not a record of what they did.
5 questions to ask about a SIEM
These are practical questions about running a SIEM, not a scored checklist from NIST or CISA. Each one follows from the points above.
- Which systems actually send logs? Firewalls, servers, Microsoft 365, and endpoints are a sensible start. Ask what is left out, including cloud admin activity, not only the machines in the closet.
- Who looks, and what do they do next? A console with nobody responsible is logging, not monitoring. Ask who reviews an alert and what decision they are expected to make.
- How is noise tuned? The joint guide talks about cutting alert noise and telling false positives from true positives. Ask how rules are adjusted for your environment, rather than left at a default that flags ordinary work.
- How long are logs kept, and who can delete them? Ask for a retention period that matches your risk and any rules you already follow. Ask how the copy is protected if someone clears logs on a PC or a firewall.
- What do you receive after a review? A raw export is hard to use. A short note is not: what happened, what was done, and what is still open.
A password found for sale is a lead, not proof anyone used it. Sign-in and admin logs are how you check. Our dark web monitoring post covers the lead. A SIEM is one place those sign-in logs can be watched alongside everything else.
How LTS can help
LTS Technology, in Bakersfield, monitors and manages SIEM for companies. We deploy and tune it, in the cloud or on premises. We bring in the logs that matter for your environment, alert on them, and write up what an auditor or a manager can actually use: what happened, what we did, and what is still open. We tune noisy sources so the alerts are worth reading, and we agree up front who is notified when one needs a person.
That ongoing watching and alert triage is part of our cybersecurity services. Microsoft 365 log coverage fits with our Microsoft 365 services. The day-to-day work can also sit with managed IT support. We do this with your internal IT, not instead of it.
Not sure whether your logs are being watched or only stored? Talk with us about SIEM monitoring.
Related: Cybersecurity services · Managed IT support · Microsoft 365 services · Dark web monitoring · Contact