Notifications
Clear all
Topic starter
21/08/2026 4:44 pm
TL;DR: Fifteen national cyber agencies now agree that effective event logging depends on structured schemas, reliable UTC timestamps, prioritized source coverage, and retention long enough to outlast dwell time, according to Axoflow. The practical lesson is that detection quality is limited less by SIEM features than by whether the underlying log pipeline preserves the fields, timing, and history analysts need.
NHIMG editorial — based on content published by Axoflow: ASD's ACSC Best Practices for Event Logging and Threat Detection: What the 9-Country Advisory Means for Your SOC
By the numbers:
- The advisory says incident discovery can take up to 18 months, while some malware dwells on networks for 70 to 200 days before causing overt harm.
- The advisory lists 16 prioritized enterprise network source types, from critical systems to legacy IT assets.
Questions worth separating out
Q: How should security teams structure logs so a SIEM can actually use them?
A: Start with a fixed schema for each event type, then enforce consistent field names, timestamps, and identifiers across sources.
Q: Why do retention periods matter so much for detection and response?
A: Because many intrusions are discovered long after they start.
Q: What do teams get wrong about centralized logging storage tiers?
A: They often treat storage as a cost exercise instead of an investigative design decision.
Practitioner guidance
- Standardize your event schema Define a required logging schema for authentication, admin, and control-plane events, then map every major source to that structure before it enters the SIEM.
- Align time handling across environments Enforce UTC, ISO 8601 formatting, and synchronized time servers across cloud, endpoint, and OT systems so correlation does not depend on manual clock correction.
- Extend retention to match dwell time Set retention based on realistic incident discovery windows, then tier older logs into secure storage instead of deleting them when the SIEM quota fills.
What's in the full article
Axoflow's full article covers the operational detail this post intentionally leaves for the source:
- The source article breaks down the logging baseline for enterprise networks, OT, mobility, and cloud in more implementation detail.
- It maps the advisory's requirements to specific ingestion, normalization, and storage behaviours across the data pipeline.
- It explains how centralized storage, tiered retention, and in-stream detection are positioned against the advisory's recommendations.
- It includes the article's direct comparison between logging quality, SIEM cost, and retained investigative value.
👉 Read Axoflow's analysis of ASD ACSC event logging and threat detection guidance →
ASD ACSC logging guidance: what it means for SOC detection quality?
Explore further
21/08/2026 5:04 pm
Logging quality is now a governance issue, not a SIEM tuning issue. The advisory’s real message is that SOC visibility starts upstream, in the data pipeline that normalises, timestamps, retains, and centralises events. If those mechanics fail, no amount of correlation logic can reconstruct the attack path. For identity teams, that means authentication and privilege logs are only as valuable as the pipeline that preserves them, which makes logging policy part of security architecture, not an afterthought.
A question worth separating out:
Q: Which logging sources should organisations prioritise first?
A: Start with authentication events, privilege changes, admin commands, identity servers, and cloud control-plane actions. Those sources most often expose account abuse, unauthorized configuration changes, and lateral movement before the impact becomes visible elsewhere. Lower-value telemetry can follow once the high-signal sources are stable and searchable.
👉 Read our full editorial: ASD ACSC logging guidance shows the data layer is the SOC bottleneck
