Cyber security
SIEM and security monitoring
Collecting the logs is the easy part. The value is in someone competent looking at what comes out of them, and being able to prove it happened.
What a SIEM is actually for
A SIEM gathers logs from across your environment — identity, endpoints, servers, network, cloud services — puts them in one place, and correlates them so that events which mean nothing individually can be recognised together.
A failed login is noise. Forty failed logins across a dozen accounts from one address, followed by one success and a mailbox rule being created, is an incident. No single system sees that pattern; the SIEM is what does.
The part most of this industry skips
A SIEM nobody reads is shelfware. The licence is the cheap component. The expensive, useful component is someone who knows your environment triaging what it produces, tuning out the noise, and escalating the handful of things that matter.
Buy a SIEM without that and you have bought an alert queue, a monthly bill, and a false sense of coverage. It is worth asking any provider quoting you monitoring exactly who looks at the alerts, when, and what happens at 2am on a Sunday.
What the service involves
- Deciding what to collect. Everything is neither affordable nor useful.
- Connecting the sources that matter — identity first, since that is where most intrusions become visible.
- Tuning detection rules to your environment, which is the difference between alerts and noise.
- Setting retention deliberately, because compliance obligations and storage cost pull in opposite directions.
- Triage and escalation, with an agreed definition of what constitutes an incident and who declares one.
- Reporting you can hand to an assessor rather than reconstruct afterwards.
What you cannot answer without it
The clearest argument for monitoring is not a hypothetical attack. It is the set of questions you get asked after something has already happened, all of which are decided in advance:
- What did they actually reach? Not what they could have reached — what they did.
- When did it start? Almost always earlier than anyone assumes.
- Is it over? The hardest one, and unanswerable from an environment that was not recording.
- Do we have to tell anyone? Notification obligations to customers, insurers, and — under DFARS 252.204-7012 — the Department of Defense turn on facts you either have or do not.
An environment with no logging does not produce a smaller incident. It produces the same incident with guesswork instead of answers, and guesswork is what turns a contained problem into a disclosure you cannot bound.
This is the same point the security and recovery pages arrive at from different directions: the useful decisions are all made before the bad day, not during it.
Alerts are not the product
A SIEM will happily generate more alerts than anyone can read, and a queue nobody works through is indistinguishable from no monitoring at all — with the added disadvantage that everyone believes they are covered.
Tuning is therefore continuous rather than a setup task. Environments change, staff start doing new things, and a rule that was precise in March is noise by September. The measure worth applying is not how many alerts a system produces but how many turned out to matter, and whether anybody could still tell you that six months in.
It is also why the questions to ask a provider are operational rather than technical: who reads these, on what schedule, what are they authorised to do without asking, and what does the handover look like at 2am on a Sunday. The tool is largely interchangeable. That answer is not.
Why this matters for compliance
For defense contractors, monitoring is not only a security control — it is an audited one. NIST SP 800-171's audit and accountability family (3.3, 9 controls) covers generating audit records, protecting them, retaining them, and reviewing them.
Reviewing them is the requirement people fail. Logs that exist but were never examined satisfy the letter of "generate" and nothing else, and an assessor asking for evidence of review is asking for something a SIEM produces and an untouched log archive does not.
Retention is where this becomes a decision rather than a setting. Compliance obligations and storage cost pull in opposite directions, and the default in most tools is shorter than people assume — frequently shorter than the interval between an intrusion starting and anyone noticing. Logs that expired before the investigation began are the most avoidable failure in this whole subject.
Our shared responsibility matrix marks this family as typically the provider's — one of the ones you can genuinely hand over. It sits alongside the wider NIST SP 800-171 work and the CMMC Level 2 engagement it supports.
Find out what you would actually see
Twenty minutes on what you have connected today, what you would want to catch, and whether you need this or something simpler.
Schedule a call