Logging is a Discipline, Not a Switch

A successful logging program requires a phased, disciplined approach to build effective visibility rather than treating logging as a simple switch. The initial phase focuses on ensuring the log infrastructure can handle the data volume by configuring retention and maximum file sizes, setting minimum recommendations based on industry standards for various log types. The second phase involves implementing advanced auditing by shifting from legacy audit categories to Advanced Audit Policy, requiring careful configuration of numerous subcategories. This setup necessitates balancing desired security coverage with managing potential log volume to prevent events from being overwritten before collection.
The subsequent steps focus on defining specific detection goals, targeting common adversary behaviors such as authentication patterns, privileged account usage, process execution (Living off the Land), and DNS queries. The final phase involves mapping existing capabilities against these goals to identify gaps and then testing those detections through tabletop exercises to validate operational awareness. The overall message emphasizes that effective logging is a continuous discipline requiring careful tuning of collection mechanisms before focusing on detection logic.

* Configure log behavior so logs can hold collected volume, setting Control Event Log behavior when the log file reaches its maximum size to Disabled for Application, Security, Setup, and System logs on all domain controllers.
* Raise maximum log file sizes from 20MB default based on minimum recommendations: 32MB for Application, Setup, and System logs; 192MB for Security logs.
* Configure domain controllers to use Advanced Audit Policy instead of the nine legacy audit categories by enabling the setting to override category settings.
* Audit configuration details include tracking events such as Account Logon, Kerberos Authentication Service, Kerberos Service Ticket Operations, and various Object Access events.
* Specific audit categories reviewed include Auditing Account Lockout, Logon, IPsec Main Mode, Group Membership, File Share, and Policy Change events.
* The article lists ten detection goals: Authentication patterns, privileged account use and membership changes, process execution, PowerShell logging, DNS query logging, Firewall egress logging, Domain controller and identity telemetry, Email gateway telemetry, Web proxy and browsing logs, and Security tool evasion signals.
* Further steps involve implementing Sysmon after native auditing is stable to track process hashes, network connections by process, image loads, and named pipes.

The narrative structures a compelling argument against treating logging as an afterthought, framing it instead as a foundational discipline requiring precise engineering before detection logic can be meaningfully applied. The progression from physical log capacity (Step One) to granular configuration (Step Two), and finally to strategic goal setting (Step Three), mirrors the necessary cognitive shift for security operations: you must master the collection mechanism before attempting to derive meaning. This sequence implicitly attacks the common operational failure where volume management is ignored, leading to stale or insufficient data.
The pattern suggests a systemic push against an assumption—that collecting *more* data automatically improves security. The underlying principle is that poor data integrity and retention undermine any downstream detection effort. The introduction of specific telemetry goals (Step Three) acts as the payoff, demonstrating what this disciplined collection is intended to unlock, specifically targeting high-value adversary techniques like Living off the Land and Kerberoasting. The framework effectively leverages practical steps (tuning settings) to enforce theoretical security principles (detection strategy).
The implication for human agency is that complexity in security systems often stems from a lack of discipline in setup rather than a deficiency in tools. The challenge shifts from "What alerts do I need?" to "Can my system even record the necessary evidence for those alerts?". This demands an analytical posture that prioritizes the operational reality—the constraints of log size and retention—as foundational inputs, preventing analysts from focusing solely on theoretical threat patterns without acknowledging the physical limitations of the data source.
Bridge Questions: If infrastructure constraints make comprehensive logging cost-prohibitive, what is the minimum viable set of logs that must be prioritized for immediate detection? How can organizations operationalize the risk associated with log retention windows to inform security investment decisions? What mechanisms exist to enforce adherence to established logging baselines across disparate environments?