Security monitoring is the practice of collecting enough evidence about what is happening in an environment to notice when something is wrong, and having somebody act on it. Both halves are load bearing. Organizations that buy the first half and skip the second have a logging platform, not a detection capability.
This article covers what to collect, how detection is actually built, what triage requires, and the escalation path that makes the whole thing worth paying for.
Start from the log, not the platform
NIST puts the foundation in one sentence: a log is a record of the events occurring within an organization and its systems and networks. Everything a monitoring program does rests on those records existing, being complete enough to reconstruct a sequence, and being retained long enough to be useful when somebody finally looks.
The common failure is not absence but incompleteness. Logging is enabled at defaults, which are chosen by vendors for storage economy rather than for investigation. The events that matter during an intrusion, authentication detail, process creation, privilege changes, administrative actions in a cloud tenancy, are frequently the ones not captured by default.
So the first question is not which platform to buy. It is which events you would need to answer the question after an incident, and whether they are being recorded today.
What to collect
A workable baseline for most organizations covers identity, endpoints, network boundary, cloud control plane, and the critical applications.
- Identity. Authentication successes and failures, multifactor challenges and their outcomes, privilege elevation, account creation and role changes. This is the richest source in most environments because most intrusions involve credentials.
- Endpoints and servers. Process execution, persistence mechanisms, security tooling status and, critically, tamper or disable events.
- Network boundary. Connection records, denied traffic, remote access sessions and their sources.
- Cloud control plane. Administrative actions in the tenancy: who changed a permission, opened a storage container, altered a network rule. This is the audit trail that does not exist on premises and is routinely left unenabled.
- Applications. Authentication, authorization failures, and administrative actions in the systems that hold regulated data.
Retention is a design decision rather than a default. Intrusions are frequently discovered long after they began, and a thirty day window will not answer the question. Longer retention on a smaller set of high value events usually beats short retention on everything.
Detection is engineering, not a subscription
Vendor supplied detections are a starting point. They are written for a general population and know nothing about which of your servers should never initiate an outbound connection, which service account should never log in interactively, or which administrative action is normal at 3am in your organization and alarming in another.
Detection engineering is the work of encoding that local knowledge. In practice it means a small number of high confidence rules tied to behavior you have decided is abnormal, rather than a large number of generic rules producing volume.
The zero trust literature is useful here because it argues for exactly this posture. NIST describes an architecture in which there is no implicit trust granted to assets or user accounts based solely on their physical or network location. If location grants no trust, then monitoring has to observe behavior rather than assume that internal traffic is safe. That reframing is what makes lateral movement detectable at all.
Triage: the part that is actually a service
An alert is a question, not a conclusion. Triage is the process of answering it quickly enough to matter and consistently enough to trust.
Three things make triage work. A defined severity model, so the same alert gets the same treatment on a Tuesday afternoon and a Sunday night. A documented first response for the recurring cases, so the analyst is not improvising. And an honest feedback loop, so that a rule producing repeated false positives is tuned or retired rather than ignored.
That last point deserves emphasis because it is where monitoring programs quietly die. An alert queue that is skimmed is worse than no queue, because it produces the appearance of coverage. When a team says the console is noisy, they are reporting a detection engineering problem and an implicit decision to stop looking.
Escalation, and deciding in advance
Escalation is where monitoring meets the rest of the organization, and it has to be settled before it is needed. Who is called, at what hour, on what evidence. Who may disconnect a system, disable an account or block a supplier connection, and whether they need permission first.
Those authorities are difficult to agree during an incident and straightforward to agree beforehand. An organization that has not agreed them will spend the first hour of its next incident finding someone to authorize the action rather than taking it. The handover into response is covered in incident response and cybersecurity recovery.
Investigation and the evidence that supports it
Investigation asks what actually happened, and it depends entirely on decisions taken months earlier. Whether the relevant logs exist. Whether they are correlated well enough to follow an identity across systems. Whether clocks agreed. Whether the endpoint retained enough history.
The practical implication is that investigation capability is built at collection time, not at incident time. An organization that discovers during an intrusion that it cannot tell which account was used has made a configuration decision, usually without knowing it.
Where SIEM, EDR and the rest fit
Tooling categories matter less than the questions they answer, and a monitoring program should be describable without naming a product.
Centralized log management answers where the records live and how long they survive. Detection answers what is considered abnormal here. Endpoint telemetry answers what a specific machine did. Network telemetry answers what talked to what. Correlation answers whether a series of unremarkable events is one story. Case management answers who is handling this and what was decided.
A single platform may provide several of these. What matters is that each question has an owner and an answer, not which vendor's logo is on the console. Choosing tooling before answering them produces a deployment that generates signal nobody has decided how to use.
Coverage, and the honest gap statement
Every monitoring program has blind spots. The mature ones can name theirs.
Typical gaps include encrypted traffic that is not inspected, personal devices reaching corporate services, software as a service applications whose audit logs sit behind a higher licence tier, operational technology segments deliberately isolated from the collection network, and third party connections whose activity is visible only as an authenticated session.
None of these is necessarily wrong. Inspecting all encrypted traffic is expensive and carries its own privacy questions. Buying the higher licence tier for every application may not be justified. The failure is not having the gap; it is not knowing about it, because an organization that believes it has full coverage will misread a quiet console as good news.
A useful artifact is a one page coverage statement: for each significant system and data flow, whether it is monitored, partially monitored or not monitored, and the reason. It takes an afternoon to produce, it is immediately useful to an auditor, and it converts an unknown into a decision. It also tells you where an investigation will run out of evidence, which is worth knowing before the investigation rather than during it.
Monitoring the controls, not only the threats
A subtle and valuable use of the same telemetry is watching whether your own controls are still working. Endpoint agents that stopped reporting. Log sources that went quiet. Multifactor enforcement that a policy change quietly exempted. Backups that have not completed.
These produce no alerts in a threat oriented detection set, because nothing attacked anything. They are nonetheless the leading indicator of the drift described in the managed cybersecurity lifecycle, and treating a silent log source as an incident in its own right is one of the higher value habits a program can adopt. The wider discipline is covered in continuous security and compliance monitoring.
Running it as a service
Monitoring is the capability organizations most often buy and least often staff, because its value is invisible on the days nothing happens and its cost is a person who has to be awake.
LABUSA operates collection, detection, triage and escalation within managed cybersecurity operations at LABUSA, with the escalation route and its authorities written into the service agreement rather than assumed. The findings that monitoring surfaces feed the remediation cycle described in vulnerability management and the baseline work in endpoint and server security.
Sources
- NIST, Guide to Computer Security Log Management, SP 800-92.
- NIST, Zero Trust Architecture, SP 800-207, August 2020.
- NIST, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, SP 800-61 Rev. 3.