Security logging is the operating system for detection and investigation. A useful program decides which events matter, collects them reliably, preserves identity and time context, protects the evidence, builds detections around plausible attack paths, and measures whether analysts can turn signals into action.
NIST CSF 2.0 includes continuous monitoring and adverse-event analysis in the Detect function. CISA's current business guidance recommends logging and monitoring policies, protecting logs from unauthorized access or deletion, retaining logs according to policy and compliance needs, and maintaining clear incident-response roles. This guide translates those outcomes into a vendor-neutral operating model.
A logging program should make it possible to reconstruct meaningful events: which identity authenticated, from what device or network location, what resource was accessed, what privilege was used, what changed, what data moved, which control made the decision, and what happened next. Collecting events that cannot be tied to an owner, timestamp, asset, or action creates storage cost without equivalent investigative value.
Define logging requirements by service and attack path. Identity systems need authentication, enrollment, recovery, role, token, and privileged events. Network infrastructure needs configuration, authentication, routing, policy, VPN, DNS, DHCP, and boundary telemetry where supported. Endpoints need process, security-control, identity, and relevant operating-system events. Cloud and SaaS services need administrative, authentication, API, data-access, sharing, and configuration events appropriate to the service.
NIST CSF 2.0's Detect outcomes emphasize monitoring assets for potentially adverse events and analyzing those events to characterize possible incidents. The practical implication is that collection and analysis belong in the same operating model. A source that is never reviewed or correlated is not providing the same risk reduction as a source tied to a detection or investigation use case.
Collect sign-in success and failure, MFA and authenticator enrollment, password or recovery events, new devices, role assignments, privileged elevation, federation changes, application consent, session or token revocation where available, and emergency-access use. These events are critical because compromised identities often cross many services without generating malware alerts.
Use endpoint and operating-system telemetry appropriate to risk: process execution, security-control changes, service or persistence changes, privileged activity, suspicious child processes, relevant file events, remote administration, and endpoint-detection findings. Avoid enabling every verbose source by default if the organization cannot retain or use it.
Collect firewall decisions, VPN sessions, DNS and address-assignment context, administrative access, device configuration changes, important routing or interface events, and telemetry at trust boundaries. For cloud networks, include flow or equivalent connection metadata where it supports defined investigation and detection needs.
Administrative audit trails, permission changes, API access, data exports, sharing changes, application deployments, secret or key changes, authentication events, and high-risk business actions often matter more than generic web-request volume. Work with application owners to identify the events that represent authority or material state change.
The best detection rule cannot repair an event stream that silently drops fields, changes timestamps, or loses the identity behind an action.
Map common fields such as timestamp, source, destination, user, device, action, outcome, severity, application, and event type so analysts can correlate across products. Preserve raw or reconstructable source data when required so an investigation can verify what the original system actually emitted.
Alert when a critical source stops reporting, volume falls unexpectedly, parsing fails, timestamps drift, storage queues back up, or a collector is disabled. A silent logging outage is itself a security-relevant event because detections may continue appearing healthy while important evidence is missing.
Correlating authentication, endpoint, network, and application events requires trustworthy time. Monitor clock synchronization on critical infrastructure and record timezone or normalized timestamps consistently. A few minutes of drift can make a multi-system incident timeline unnecessarily difficult to reconstruct.
Asset owner, criticality, user department, network zone, vulnerability state, and threat intelligence can add useful context. Decide which enrichment must be historically preserved and which can be looked up later. Current metadata can mislead a retrospective investigation if the asset owner or role changed after the incident.
CISA recommends retaining logs in accordance with organizational policy and compliance needs and protecting them from unauthorized access or deletion. There is no single universal retention period that fits every organization. Retention should reflect detection delay, incident-investigation needs, contractual and regulatory obligations, storage economics, privacy considerations, and the value of the source.
Tier storage where appropriate. High-value recent telemetry may remain fast and searchable while older evidence moves to lower-cost storage with a documented retrieval path. Test retrieval before relying on archive retention in policy. A twelve-month retention claim is not operationally useful if restoring the archive takes weeks or the organization no longer has the parser needed to read it.
Separate duties around deletion and administration. Limit who can disable collection, alter retention, or erase high-value evidence. Monitor those actions. For especially consequential systems, consider immutable or otherwise protected storage patterns that prevent a compromised production administrator from deleting the only record of their actions.
Privacy still applies to logs. Collect fields for defined operational and security purposes, limit access, document retention, and avoid treating “security” as justification for indefinite collection of unrelated personal data.
A detection should state what behavior it is looking for, why that behavior matters, what data it requires, expected false-positive causes, severity, owner, response action, and test method. “Alert on all failed logins” is weaker than a rule designed around password spraying, impossible travel, new privileged authentication, or recovery abuse with enough context to distinguish normal behavior.
One event may be ambiguous. A new authenticator followed by a privileged role assignment and a large data export is more meaningful. Correlate identity, endpoint, network, cloud, and asset context where doing so materially improves confidence or investigation speed.
Use controlled simulations, known test events, purple-team exercises, or safe administrative actions to prove that the source arrives, parsing works, the logic matches, the alert reaches the expected queue, and the analyst has enough context to decide. Re-test after schema, product, or architecture changes.
Version rule logic, document changes, use peer review for consequential detections, record dependencies, and maintain rollback. Retire rules whose underlying technology no longer exists. A detection library should be an operated product, not an accumulation of searches nobody owns.
An analyst should be able to see the triggering evidence, affected identities and assets, relevant enrichment, recent related activity, prior occurrences, and the action expected at that severity. Link the alert to a runbook or investigation pattern rather than relying on tribal knowledge.
Prioritize alerts by plausible consequence and confidence, not only by vendor severity. A low-volume alert involving a domain administrator, identity provider, backup platform, or internet-facing critical service may deserve faster attention than hundreds of noisy endpoint findings.
Preserve investigation notes and disposition. False positives should feed tuning. Benign-but-unusual behavior may justify a baseline change. Confirmed incidents should identify which evidence helped, which evidence was missing, and whether the detection fired early enough to matter.
Escalation criteria should be explicit. Analysts need to know when an event becomes an incident, who can isolate systems, who can disable accounts, when legal or communications teams join, and how evidence is preserved. Logging becomes valuable when it shortens these decisions.
Inventory critical log sources, current collection paths, retention, ownership, time synchronization, parser health, alert dependencies, and known blind spots. Prioritize identity, privileged access, internet boundaries, critical services, endpoints, and cloud control planes.
Monitor source health, remove obvious duplicate/no-value ingestion, document retention, create or tune detections around high-consequence attack paths, and ensure priority alerts include ownership and investigation context.
Run controlled detection tests, tabletop a logging outage, retrieve archived evidence, measure triage time, document missing data from investigations, and turn recurring analyst pain into a prioritized telemetry backlog.
Retention, monitoring, and incident-response obligations vary by organization, jurisdiction, contract, and sector. This guide provides an operating model; confirm any mandatory retention or reporting requirement that applies to your environment.
Follow the next implementation topic without returning to search.
Build repeatable security operations and evidence practices
Continue readingGovern identity lifecycle, authentication, federation, privileged access, service identities, access review, and identity evidence
Continue readingPrioritize and remediate vulnerabilities using asset, exploitation, exposure, ownership, exception, and verification evidence
Continue readingUse the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.