ASD's ACSC Best Practices for Event Logging and Threat Detection: What the 9-Country Advisory Means for Your SOC

In August 2024, Australia's ASD's ACSC (Australian Signals Directorate's Australian Cyber Security Centre) published "Best Practices for Event Logging and Threat Detection", co-authored with 14 partner agencies from eight other countries - the US (CISA, FBI, NSA), UK (NCSC-UK), Canada (CCCS), New Zealand (NCSC-NZ, CERT NZ), Japan (NISC, JPCERT/CC), South Korea (NIS, NCSC-Korea), Singapore (CSA), and the Netherlands (AIVD, MIVD). The baseline: log the right data, in a consistent format, with reliable timestamps, retained long enough to catch threats that dwell for months, and centralized so a SIEM or XDR can actually detect them.

Fifteen national cyber agencies agreeing on the same logging baseline is not a small signal. Here is what it actually asks for, and where the work lands.

What does an "enterprise-approved" logging policy need to include?

The advisory's first pillar isn't about logging more - it's about logging deliberately. Three requirements do the heavy lifting:

• Structured, consistent format. Logs should use a structured format like JSON, with the same schema, field order, and content every time a given log type is generated. Key-value pairs are recommended specifically because they're easier to extract and correlate at scale.
• Consistent, trustworthy timestamps. UTC across every system, ISO 8601 formatting (2024-07-25T20:54:59.649Z), synchronized time servers, and one-directional time sync from OT to IT - never the reverse.
• A real field baseline. Citing the US OMB's M-21-3 memo, the advisory lists what a useful event log should capture where applicable: a millisecond-precision timestamp, event type, device identifier, session/transaction ID, source and destination IP, status code, response time, user ID, the command executed, and a unique event identifier for correlation.

Retention gets its own hard number, and it's the one line every reader should sit with: it can take up to 18 months to discover a cyber security incident, and some malware dwells on the network 70 to 200 days before causing overt harm (CISA, "First 48": What to Expect When a Cyber Incident Occurs). Whatever retention period your organization budgets for, that's the bar it's being measured against.

Which log sources should you prioritize first?

The advisory prioritizes differently by environment, and the differences matter:

• Enterprise networks: critical systems and data holdings first, then internet-facing services, identity/domain servers, edge devices, and privileged systems - 16 source types in total, down to legacy IT assets.
• Operational technology: OT devices critical to safety and service delivery (except air-gapped systems), internet-facing OT, and devices reachable via network boundaries.
• Enterprise mobility: web proxies, organization-run DNS, device posture and behavior, sign-ins, VPNs, and MDM/MAM events.
• Cloud computing: control-plane operations first - API calls, admin configuration changes, permission changes, and authentication events - since IaaS puts most logging responsibility on the tenant while SaaS shifts it to the provider.

How do you keep event logs secure and tamper-proof?

The advisory recommends a centralized, segmented logging facility - a secured data lake - that forwards selected, processed logs to a SIEM or XDR, with TLS 1.3 in transit and cryptographic integrity verification at rest. The reasoning is direct: malicious actors modify or delete local logs specifically to blind incident response, so access to delete or modify centralized logs should be restricted to a justified few, and the storage itself backed up and segmented from general IT.

Why does the advisory focus so heavily on "living off the land" techniques?

Because LOTL is the hardest category to catch with signatures alone. The advisory's case study is Volt Typhoon - active since mid-2021, using PowerShell, wmic.exe, ntsdutil.exe, and vssadmin (all legitimate Windows tools) to extract Active Directory credentials and move laterally, without deploying any malware a signature-based tool would flag. The advisory's answer is behavioral baselining: know what normal looks like for your accounts and tools, and treat deviations - off-hours logins, impossible travel, unusual script execution, unexpected log clearing - as things worth investigating, even though most of them turn out to be benign.

How Axoflow maps to the advisory's four pillars

Axoflow is the autonomous security data layer - collecting, processing, routing, storing, and managing data, with in-stream detection in early access. AI-based autonomy, not just a chatbot, drives 10X faster investigations, 50% lower SIEM spend, and near-zero pipeline maintenance.

The advisory doesn't ask you to detect more. It asks you to see clearly enough that detection is possible.

Detection is in early access, running Sigma rules in-stream and forwarding findings to SIEMs - it doesn't replace the behavioral baselining the advisory describes, it makes sure the SIEM or XDR running that baselining is fed the fields it actually needs, unbroken by schema drift or missing sources.

What else does the advisory ask for, and how does Axoflow deliver it?

The four pillars are the summary. Some of the advisory's own language is specific enough to answer directly, line by line.

Fifteen agencies agreeing on a logging baseline is a rare kind of consensus. Meeting it is a data engineering problem before it's a detection problem. If you want to see where your current logging setup stands against this baseline, Book a conversation.