AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
AI investigations and 24x7 MDR on the Microsoft Sentinel you already own
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Monitoring, evidence and a 24x7 SOC in one platform
Compliance monitoring, evidence and board reporting
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
Free ebook: modern security operations with Microsoft Sentinel
How the framework is structured and what changes from the Essential Eight
November 13, 2026
November 10, 2026
November 6, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
For SIEM, ASD Essentials looks at results: whether security events are collected and detected, whether rules are tested and tuned and whether detection coverage is reviewed for gaps.
It prescribes no product. A security information and event management platform does that work by collecting, protecting, correlating and searching security logs. Detection rules catch suspicious activity through automated analytics, and threat hunting uses hypothesis-led searches to find attacker behaviour the existing detections may have missed.
ASD Essentials does not prescribe a separate threat hunting program for enterprise IT or cloud either. Control validation and purple team exercises can provide evidence that logging and detection work in practice.
ASD Essentials splits the SIEM requirements between the systems that generate security events and the central capability that analyses them. Logging actions apply in every technical domain, and central monitoring is set up through Visibility and response. A SIEM supports both sides with central event logging, detection and investigation across the technical domains.
Protect event logs in transit and at rest, forward high-value security events and configuration changes to central storage, and normalise, time-synchronise and enrich records for correlation.
Maintain a central event log store protected against unauthorised access and modification, and implement detections for unauthorised changes, anomalous authentication and suspicious software execution.
A central SIEM can process every event it receives correctly while a domain still lacks the logging categories its detections need. Collection effectiveness is assessed within each applicable domain, so the evidence has to show both that central monitoring operates and that the required records arrive from in-scope systems. A typical case is a server that forwards its logon events while an audit category for configuration changes is switched off: the central platform looks healthy and the domain’s records are incomplete. The ASD Essentials Visibility and response guide covers the wider detection, incident identification and response requirements.
A connector only opens a collection path. Logging for ASD Essentials is judged on what comes through it: complete, protected and usable security events, delivered to central monitoring.
List the in-scope systems, the event categories and configuration changes each has to supply and its collection status, then compare the list with the records actually received. A connected identity provider can supply sign-in events and still omit the audit events needed to detect authentication configuration changes.
Forward events often enough for the detections that depend on them, monitor ingestion delays and synchronise timestamps with an authoritative time source so events from different systems fall into the right order.
Map account, device, address, action and timestamp information to consistent fields, keeping the original details. Add context such as asset classification and account type so rules can separate ordinary user activity from actions on privileged or critical systems.
Encrypt records in transit and at rest. Protect the central store against alteration or deletion, including by source system administrators. Restrict access to security operations and roles with a documented need, and log and monitor that access.
Set a reporting window per source, alert when records stop arriving and review source coverage and value on a defined schedule. ASD distinguishes scheduled reviews from ad hoc reviews when assessing effectiveness.
A silent source opens a detection gap while every rule stays enabled. A parser update, a disabled audit category or a forwarding change can do the same more quietly, removing a field a detection uses without any obvious connector failure. Review each collection change against the rules that depend on it.
The assets and security behaviours each technical domain covers decide which ASD Essentials log sources to centralise. The number of integrations a SIEM offers is no guide. Start with the priority phase 1 domains, Boundary services and Identity services, while setting up central Visibility and response, and add sources as later domains enter scope. The enterprise IT chapter includes non-production environments, so relevant development and test systems belong in the inventory.
SigninLogs
AuditLogs
OfficeActivity
DeviceProcessEvents
For each source, the inventory records whether it is connected, whether the required event categories arrive and whether those events carry the fields the relevant detections need. Successful and failed Entra ID sign-ins, for example, give no coverage for federation changes or MFA method registration, which depend on different audit records. Reconcile the inventory with each domain’s assets and with the rules that consume the data, so gaps surface before an investigation needs the missing evidence.
ASD Essentials log retention follows each organisation’s documented investigative, regulatory and contractual requirements. No one period applies to every organisation.
The fully effective indicator for the central log store expects retention requirements to be defined, aligned with investigative, regulatory and contractual obligations, and consistently applied across log types. A central store without defined retention requirements is rated not effective.
Those obligations may come from the ISM’s event logging controls, records management requirements, sector regulators and contracts. The SIEM log retention guide examines them in more detail.
An intrusion may be discovered weeks or months after the initial activity, when the investigation needs logs that are no longer in day-to-day use. Document how long logs stay searchable and how long they are kept at all.
The period available for routine detection, investigation and threat hunting without restoration.
How long records remain available across storage tiers, including archives for investigations, legal holds and assessments.
For each log type, confirm which period applies and whether older records need restoring before they can be queried. Then test retrieval with an actual historical record: locate, restore and search it. A retention setting shows intended behaviour. A successful retrieval test shows the evidence is still usable.
DET-02 Cyber security event detection calls for automated detection logic for suspicious activity. The central action belongs to the Visibility and response domain and states: Ensure detection logic identifies unauthorised changes, anomalous authentication activity and suspicious software execution. The cloud chapter extends the action to anomalous control-plane activity, including consent grants, federation changes and privilege elevations.
Ensure detection logic identifies unauthorised changes, anomalous authentication activity and suspicious software execution.
anomalous control-plane activity, including consent grants, federation changes and privilege elevations.
ASD’s Indicators of Good Practice examine the categories covered and whether the organisation tests and tunes its rules on a defined cycle. A SIEM can implement these detections using rules, correlation and analytics.
Build detections in step with logging, starting with the priority phase 1 domains. The list below names behaviours to monitor in each domain. ASD sets no separate requirement for an individual SIEM rule per behaviour.
Detect password spraying, sign-ins from unfamiliar infrastructure, MFA method changes and authentication involving credentials found in exposure data.
Monitor exploitation of internet-facing services, newly exposed administrative interfaces and remote access from unexpected locations.
Identify new privileged role assignments, administrator sign-ins from ordinary user devices and privileged activity outside the baseline.
Monitor new mailbox forwarding and inbox rules, including New-InboxRule activity in OfficeActivity, unusual bulk downloads and backup deletion.
New-InboxRule
Identify Office applications launching script interpreters, abuse of signed system binaries and application control blocks.
Credential exposure is an area ASD Essentials introduces with no direct equivalent in the Essential Eight. An exposure finding becomes more useful when correlated with later authentication: an exposed credential that keeps authenticating warrants investigation under the applicable identity controls.
A detection mapping ties each suspicious behaviour to the ASD Essentials principle and action it supports, the assets it concerns and the data needed to detect it. Laid out as a table, the mapping shows which actions have coverage and which ASD Essentials detection rules cannot operate because their telemetry is unavailable.
SecurityEvent
IdentityLogonEvents
SecurityAlert
IT.DET-04.1 applies in Critical processes and services, Boundary services, Identity services and Privileged environments. The other actions in the table sit in Visibility and response, except IT.DET-01.1, which applies in every technical domain. Record each rule’s actual scope. A rule deployed in the central SIEM covers only the systems whose events reach it, so deployment there says nothing about coverage everywhere.
A detection requirement names the control failure or attacker behaviour, the evidence needed to recognise it and the expected investigation. Take the phishing-resistant MFA action under Identity, credential and access management in Identity services.
A sign-in succeeds without the expected authentication strength, or an attacker registers a new MFA method.
Identity provider sign-in and audit logs with authentication and account change details.
Identify sign-ins that bypass the required method and MFA method changes followed by unusual account access.
Revoke sessions, remove the unauthorised method and confirm the activity with the account owner.
Run a controlled sign-in and method change on a test account and verify the security decision, alert and supporting records.
The same method works for boundary, privileged access and endpoint activity. A mapping is specific enough when an engineer can test it and an analyst can explain it.
Every detection rule needs a maintained record of its purpose, ASD Essentials mapping, data dependencies and validation history. Store queries and records in version control and review them before deployment, so every change to a condition, parser or exclusion traces to who made it and why.
A useful rule record includes:
The principle, action ID and technical domains of the monitored assets.
The relevant ATT&CK technique, separating ASD’s published mapping from the detection team’s own.
The tables, fields and connected sources the query needs, detailed enough to spot a broken rule after an integration or schema change.
The alert conditions and how they relate to incident thresholds under DET-03.
The rule’s maintainer, last review and next scheduled review.
What a true positive looks like and which legitimate activity looks similar.
A positive sample that should alert and a negative sample that should stay quiet.
ATT&CK mapping helps with analysis and coverage review. ASD’s implementation planning guide says mature organisations can use it to inform detection engineering, then states: This does not require a separate detection rule for every preventive action or mapped technique.
This does not require a separate detection rule for every preventive action or mapped technique.
The KQL below shows how ASD Essentials detection rules can be built in Microsoft Sentinel from the organisation’s connected tables and analytics. Each example is a starting point that needs work before deployment, and the set covers selected behaviours only, a subset of the categories ASD Essentials expects.
Before enabling a rule, confirm its tables and fields exist, align run frequency with lookback, tune thresholds, windows and exclusions, and test against suspicious and legitimate activity. In Defender advanced hunting, use Timestamp instead of TimeGenerated for Defender tables. The ASD Essentials in Microsoft 365 guide covers the wider platform implementation.
Timestamp
TimeGenerated
Password spraying shows up as one source address failing authentication against many accounts. Detecting it supports Identity services monitoring.
SigninLogs | where TimeGenerated > ago(1d) | where ResultType in ("50126", "50053") | summarize FailedUsers = dcount(UserPrincipalName), Attempts = count() by IPAddress, bin(TimeGenerated, 1h) | where FailedUsers >= 10 | sort by FailedUsers desc
The query groups failures by source address and hour and returns addresses with at least 10 distinct failed users. Check whether the same address later authenticated successfully. Shared egress addresses such as corporate proxies can produce legitimate matches, so keep exclusions narrow.
A privileged role assignment with no approval behind it needs explaining. The query lists directory role changes to check against approved administrative activity.
AuditLogs | where TimeGenerated > ago(7d) | where OperationName == "Add member to role" | extend Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend Target = tostring(TargetResources[0].userPrincipalName) | mv-apply Prop = TargetResources[0].modifiedProperties on ( where tostring(Prop.displayName) == "Role.DisplayName" | extend Role = trim(@'"', tostring(Prop.newValue))) | project TimeGenerated, OperationName, Actor, Target, Role, Result
Check who assigned the role, to whom and whether the change followed the approved process. Privileged Identity Management eligible assignments have their own operation names, and activations may appear with MS-PIM as the actor, so cover those separately.
This query finds Office applications launching command shells or script interpreters on user devices, one form of suspicious software execution.
DeviceProcessEvents | where TimeGenerated > ago(7d) | where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe") | where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe") | project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
Business add-ins may legitimately launch these processes, so review command lines, initiating accounts and related activity. Keep exclusions narrow and documented: excluding an entire application can conceal malicious execution from the same parent process.
Federation and domain authentication changes belong to the unauthorised changes category of IT.DET-02.2. Monitoring them supports Identity services and covers the federation changes named in the cloud chapter. ASD provides no ATT&CK technique for this action, so the mapping to Domain or Tenant Policy Modification (T1484) is this guide’s own interpretation.
// Starting point: changes to domain federation or authentication settings AuditLogs | where TimeGenerated > ago(1h) | where OperationName in ("Set domain authentication", "Set federation settings on domain") | extend Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend Domain = tostring(TargetResources[0].displayName) | project TimeGenerated, OperationName, Actor, Domain, Result, CorrelationId
Federation changes are rare and high-impact. Most organisations should alert on every match and check the actor, domain and activity against an approved change record.
An alert on Windows Security log clearing supports IT.DET-01.1, which addresses protecting logs from unauthorised access, modification or deletion. ASD maps the action to Indicator Removal and Disable or Modify Tools.
unauthorised access, modification or deletion.
// Starting point: Windows Security event log cleared SecurityEvent | where TimeGenerated > ago(1h) | where EventID == 1102 | project TimeGenerated, Computer, Account, Activity, EventData
Investigate the affected system, the recorded account and related administrative activity to decide whether the event was authorised maintenance or an attempt to remove evidence.
A change to Microsoft 365 audit logging can indicate interference with monitoring under IT.DET-01.1. An administrator can disable audit ingestion without deleting any existing record, so the configuration change itself is the event to catch.
// Starting point: unified audit log ingestion disabled in Microsoft 365 OfficeActivity | where TimeGenerated > ago(1h) | where Operation == "Set-AdminAuditLogConfig" | mv-expand Param = parse_json(Parameters) | where tostring(Param.Name) == "UnifiedAuditLogIngestionEnabled" and tostring(Param.Value) =~ "False" | project TimeGenerated, UserId, Operation, Parameters, ClientIP
Both log-tampering examples depend on the triggering events reaching the platform, which interference with collection may prevent. Pair them with silent-source monitoring so lost telemetry also triggers investigation.
DET-03 Cyber security incident identification calls for indicators from across identities, applications, data and infrastructure activity rather than isolated signals. ASD’s indicators rate manual cross-source investigation below automated correlation of multi-stage activity, as the Visibility and response guide explains. A practical place to start is an account that appears in alerts from several products.
indicators from across identities, applications, data and infrastructure activity rather than isolated signals.
// Starting point: one account named in alerts from two or more products within a day SecurityAlert | where TimeGenerated > ago(1d) | mv-expand Entity = parse_json(Entities) | where tostring(Entity.Type) == "account" and isnotempty(tostring(Entity.UPNSuffix)) | extend Account = tolower(strcat(tostring(Entity.Name), "@", tostring(Entity.UPNSuffix))) | summarize Products = dcount(ProductName), ProductList = make_set(ProductName), Alerts = make_set(AlertName, 10), FirstAlert = min(TimeGenerated), LastAlert = max(TimeGenerated) by Account | where Products >= 2 | sort by Products desc
Investigators still decide whether the alerts are related and whether the combined evidence meets an incident threshold. The same approach extends to host entities. Microsoft Sentinel incident grouping and Defender XDR correlation already provide some of this, so review them before deploying overlapping rules.
Set detection severity from the organisation’s documented incident thresholds and the urgency of the investigation. A vendor’s default rating reflects neither.
DET-03 includes the action: Triage alerts and events in a timely manner to determine whether cyber security incident thresholds have been met. ASD’s indicators expect a documented triage process, defined severity thresholds and response timeframes. Fully effective performance also expects alerts triaged within those timeframes, escalated when incident thresholds are met and tracked through reporting.
Triage alerts and events in a timely manner to determine whether cyber security incident thresholds have been met.
A rule’s severity then follows from how much the detected behaviour proves by itself and how much more evidence is needed.
The detected behaviour can meet an incident threshold on its own, such as a federation change without an approved change record.
The behaviour needs more context or supporting indicators, such as unusual tool execution on a privileged system.
The behaviour adds context for correlation and rarely needs independent triage.
Severity is not an incident classification. A high-priority alert may turn out to be authorised activity. Document the severity reasoning with the rule, and keep triage records of what was reviewed, whether a threshold was met, the decision, its evidence and any escalation.
A detection rule test has to show that the intended behaviour raises an alert, that expected legitimate activity stays quiet and that the required telemetry is still arriving. Checking that the query runs is the smallest part of it. A complete test follows the event from its source through collection, parsing, rule execution and the investigation workflow.
Start with the rule’s documented positive and negative test cases. Where suitable, simulate the behaviour and confirm each step: the source generates the event, the event reaches the SIEM, the query matches and the alert lands in the intended process. Run the conditions against retained data to find rules that are too noisy or too restrictive. Record the test date, expected and observed results and any changes. For a rule developed from a hunt, keep the original hypothesis and findings.
When a rule keeps raising benign alerts, review its conditions before disabling it. Find out why it matched: an approved administrative tool, a shared network address, a scheduled task or an expected business process. Where the cause is understood, apply a narrow, documented exclusion and test it against retained events.
Check every exclusion against the malicious behaviour it could conceal. Excluding a known corporate VPN range may be reasonable with evidence. Excluding an entire cloud provider’s address space can remove coverage an attacker might use. Review exclusions on the same cycle as the rules, keep their approval and test history, compare precision before and after changes and retire rules that no longer apply.
DET-05 Detection capability efficacy addresses ongoing coverage through IT.DET-05.1: Review detection coverage periodically to identify gaps arising from new assets, services or architectural changes. The cloud chapter applies the same approach to new cloud services, integrations or architectural changes.
Review detection coverage periodically to identify gaps arising from new assets, services or architectural changes.
new cloud services, integrations or architectural changes.
ASD’s fully effective indicators expect reviews within the organisation’s defined cycle, assessment of new assets and services for log coverage and rule applicability, and remediation of identified gaps within risk-based timeframes. A new application, connector or parser change can open a gap without disabling a single rule. The review compares the environment as it now stands with each detection’s recorded dependencies and asset scope.
Under RES-04, IT.RES-04.2 asks organisations to evaluate monitoring coverage following incidents, and its indicators consider whether resulting detection changes are documented and tested.
Threat hunting is explicitly named once across the ASD Essentials chapters and ASD’s assessment, planning and transition guides, in an OT action under GOV-07 covering isolation exercises. Elsewhere, ASD Essentials threat hunting supports detection efficacy: a hunt investigates attacker behaviour that the existing rules may miss.
The strongest enterprise IT connection is DET-05 Detection capability efficacy, whose principle states that detection capabilities are regularly evaluated for effectiveness and continuously refined, including through current threat intelligence. Hypothesis-led hunts contribute by testing coverage against relevant attacker behaviour and documenting the gaps. Other principles support the same approach:
regularly evaluated for effectiveness and continuously refined,
Risk assessments consider malicious actor techniques and cyber threat behaviours, reviewed on a continuous basis. Hunts check whether that activity is present.
on a continuous basis.
Baselined identity, privileged and remote access patterns give hunts a reference for investigating abnormal behaviour.
ASD’s assessment process guide cautions that relying only on previously observed activity may understate emerging or unobserved threats. A hunt can examine a plausible scenario that no rule has alerted on. It may end in an incident, a detection improvement or evidence that the available data cannot test the hypothesis.
may understate emerging or unobserved threats.
Under GOV-07, ASD describes regular OT isolation exercises that include threat hunting before systems are reconnected. Investigators may review host-based logging from operator systems, engineering workstations and servers, and compare remote access records with validated access patterns. They may also inspect network captures on both sides of OT-connected demilitarised zone boundaries and at interfaces between operational segments. All of this happens within the OT environment’s operational constraints and procedures. See ASD Essentials for OT for the related monitoring and operational considerations.
ASD Essentials actions make practical hunting hypotheses because they describe verifiable behaviours, restrictions and records. A useful hypothesis asks what evidence would exist if a preventive control failed or an attacker acted without triggering an existing detection.
Write into each hypothesis the legitimate explanations to rule out: an unusual administrative process may be approved maintenance, and a successful legacy sign-in may be a documented exception. Domain applicability sets the initial scope. A hunt supporting IT.DET-04.1 starts in the domains where that action applies, which is a narrower set of systems than every endpoint.
Hunting priorities follow the implementation phases. Threat intelligence and operational risk then select the hypotheses within each phase. ASD’s implementation planning guide specifies that ATT&CK mapping informs prioritisation within a priority phase, not across phases. That suits organisations able to obtain, interpret and apply threat intelligence. Others may select hunts by operating context, risks and resources.
informs prioritisation within a priority phase, not across phases.
Intelligence is useful when it matches the organisation’s technologies, sector and exposure. A relevant technique may still be unobservable through the connected sources. Record that limit before treating a query as a meaningful test, because a query that cannot see the technique returns nothing either way.
ASD Essentials does not prescribe a hunting frequency. Relevant actions refer to coverage being reviewed “periodically,” while threat inputs are reviewed on a continuous basis. A program may combine:
Recurring investigations across priority phase 1 and phase 2 domains, weekly or monthly depending on risk and resources.
Started within days of advisories or campaigns affecting the organisation’s technologies or sector.
Following incidents or significant environmental changes, consistent with IT.RES-04.2 on evaluating monitoring coverage after incidents.
Define the cadence for each hypothesis and keep its execution history. Overdue, blocked and incomplete hunts stay visible with an owner and next action. A focused, repeatable hunt with defined evidence gives more assurance than a broad search with no clear conclusion.
A hunt can only test its hypothesis when the required logs, fields, systems and history cover the investigation period. An empty result does not show that suspicious activity was absent: a disconnected source, unavailable events or expired retention produce the same result.
Before running it, confirm the telemetry is connected, expected systems are represented, fields are populated and enough history exists, then record a readiness state:
The sources, fields and history needed for the defined scope are available.
Missing systems, fields or retention limit the conclusions.
Essential evidence is unavailable, so the hypothesis cannot be tested adequately.
A partial or blocked hunt produces a visibility finding. It cannot support a conclusion that activity is absent. Feed the finding into DET-05 coverage evaluation and track the collection or configuration changes needed to finish the investigation.
Keep a domain coverage register alongside hunt readiness. For each behaviour it records the source, the detection, the last validation date and a coverage status: validated, partial, unverified or out of scope with the reason documented. These statuses describe detection coverage and are separate from ASD’s formal action effectiveness ratings. Update the register when a new SaaS application arrives, an acquisition changes the environment or a connector or parser changes. Include AI agent identities, permissions and audit records.
A cloud threat hunt has to account for the control-plane activity described under DET-02 and for the evidence each service model exposes. For SaaS, ASD assigns the relevant detection action to the Provider, so customer-side hunting depends on the audit records and investigation tools the provider exposes. Record those dependencies in the readiness review, and never treat an enterprise IT query as a complete cloud investigation when service telemetry is unavailable. See ASD Essentials for cloud for the chapter-specific considerations.
A hunting query goes looking for suspicious behaviour in Microsoft Sentinel and the connected Microsoft security tools without waiting for a detection to fire. The ASD Essentials KQL hunting queries below are exploratory and have not been validated as detections. Confirm tables and fields, restrict scope to applicable systems, compare results with baselines and keep the query version and period so the hunt can be repeated.
Where legacy authentication is meant to be disabled or restricted, any legacy sign-in that still succeeds needs an explanation. This hunt supports IT.PRO-13.5 and the anomalous authentication category of IT.DET-02.2. The query finds successful sign-ins using client protocols outside the listed modern categories.
// Starting point: legacy authentication that still succeeds SigninLogs | where TimeGenerated > ago(30d) | where ResultType == "0" | where isnotempty(ClientAppUsed) | where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients") | summarize SignIns = count(), Users = dcount(UserPrincipalName), LastSeen = max(TimeGenerated) by ClientAppUsed, AppDisplayName | sort by SignIns desc
Review results against the legacy protocol inventory, approved exceptions and risk register. A success may be an approved exception, a configuration problem or an undocumented pathway, so work out which before calling it a control failure.
Process execution hunting supports IT.DET-04.1. The query surfaces parent and child process combinations involving administrative and scripting utilities that appear on very few devices.
// Starting point: rare parent and child pairs for admin and scripting tools DeviceProcessEvents | where TimeGenerated > ago(30d) | where FileName in~ ("powershell.exe", "pwsh.exe", "wmic.exe", "schtasks.exe", "sc.exe", "nltest.exe", "wevtutil.exe", "ntdsutil.exe") | summarize Devices = dcount(DeviceName), Runs = count(), FirstSeen = min(TimeGenerated), SampleCommand = take_any(ProcessCommandLine) by InitiatingProcessFileName, FileName | where Devices <= 2 | sort by Devices asc, Runs asc
An uncommon pairing is a lead to follow up and proves nothing by itself. Review the command, host purpose, initiating account and approved work, since a tool that is routine on an administration server may be unexpected elsewhere. The utility list is an example: ASD’s indicators for IT.DET-04.1 expect organisations to identify their own high-risk tools, so adapt it to the assessed environment.
An account that reaches several hosts it has not used before is worth investigating. The query compares recent successful logons with earlier account-to-host pairs and returns those accounts. It supports DET-04 access baselining and the anomalous authentication category of IT.DET-02.2.
// Starting point: accounts signing in to hosts they have not used in 30 days let baseline = IdentityLogonEvents | where TimeGenerated between (ago(30d) .. ago(1d)) | where ActionType == "LogonSuccess" | distinct AccountUpn, DestinationDeviceName; IdentityLogonEvents | where TimeGenerated > ago(1d) | where ActionType == "LogonSuccess" and isnotempty(AccountUpn) and isnotempty(DestinationDeviceName) | join kind=leftanti baseline on AccountUpn, DestinationDeviceName | summarize NewHosts = dcount(DestinationDeviceName), Hosts = make_set(DestinationDeviceName, 20) by AccountUpn | where NewHosts >= 3 | sort by NewHosts desc
Start with privileged accounts and systems in Privileged environments. New employees, service accounts and approved administrative changes can match legitimately. Record those explanations against the account’s expected purpose so the baseline keeps its known exceptions.
Control validation shows whether a security measure works in practice. A deployment record cannot answer that, and ASD’s implementation planning guidance distinguishes evidence of deployment from evidence of effectiveness. Depending on the action, validation may involve control testing, penetration testing, red team exercises, purple team activities or breach and attack simulation. ASD notes that advanced testing methods may not be required for every action.
ASD’s trustworthy software example involves attempting to execute unsigned binaries or unapproved interpreters and observing whether the intended restriction operates. The same approach works in other domains:
Attempt legacy or single-factor authentication against an account requiring a stronger method, and verify the decision and supporting evidence.
Attempt administrator activity from an ordinary user device and confirm whether the expected block or alert occurs.
Compare external scanning results with the asset inventory to find unrecorded internet-facing services.
Where prevention and detection both matter, validate and record them separately, because one can pass while the other fails. An alert may fire when the restriction fails, and a control may block the behaviour without producing the evidence detection needs.
Purple team exercises use authorised attack simulations to test whether suspicious activity is logged, detections operate, analysts recognise the event and response procedures can be completed. Organise scenarios by priority phase under approved rules of engagement.
Simulate password spraying, MFA method registration on a test account, sign-ins from unexpected infrastructure and exploitation of a test instance of an internet-facing service.
Test privilege escalation, administrator activity from a user device and unauthorised changes to systems supporting critical services, including approval requirements for privileged containment.
Test macro-enabled document execution, Office applications launching script interpreters, signed-binary abuse, mailbox forwarding rules and attempts to delete backups.
For each scenario, define the expected control behaviour, events, detection or investigation outcome and blue team response. Record what happened, the evidence available, the analyst’s decision and the gaps to remediate. Retest failed scenarios after the fixes. ASD Essentials and the SOC covers the response procedures supporting these exercises.
Detection engineering is where threat hunting findings and coverage gaps become tested rules, improved telemetry or repeatable investigation procedures. Under ASD Essentials, a hunt can produce:
Relevant attacker behaviour that existing monitoring does not recognise.
An existing rule needs better conditions, context or coverage.
Missing sources, unavailable fields or collection failures that block detection or investigation.
Behaviour unsuited to continuous alerting stays in an approved, recurring hunting hypothesis.
Successful legacy authentication from an unrecognised application, for example, may turn out to be authorised, a configuration issue or worth a standing alert. Where a new rule is justified, record its ASD mapping, data requirements, expected behaviour and test cases, then run it through the documentation, testing and tuning lifecycle above.
For IT.DET-05.1, one fully effective indicator states that identified detection gaps are remediated within risk-based timeframes defined by the organisation. A ticket only shows that a gap was assigned. Completed remediation needs the change itself and a later validation that it works. The threat hunting methodology guide covers designing hypotheses and repeatable investigations.
are remediated within risk-based timeframes defined by the organisation.
For an ASD Essentials assessment, SIEM evidence has to show that logging, detection and coverage reviews operated across the applicable systems for the whole assessment period. Configuration records and rule exports show what was intended. Source history, detection tests and hunting records show what actually operated. The collection methods are common practice rather than ASD requirements.
Usage
DataType
ingestion_time()
The following query finds Windows and Linux reporting systems whose last event falls outside the example reporting window.
// Starting point: last event per reporting system for Windows and Linux sources union withsource=SourceTable isfuzzy=true SecurityEvent, Syslog | where TimeGenerated > ago(7d) | summarize LastEvent = max(TimeGenerated), Events = count() by SourceTable, Computer | extend HoursSilent = datetime_diff('hour', now(), LastEvent) | where HoursSilent >= 24 | sort by HoursSilent desc
A system that never reported in the period will not appear, so compare the output with the expected source list. Add the other in-scope tables and set the silent threshold to each source’s expected reporting behaviour. For firewall data in CommonSecurityLog, summarise by DeviceVendor, DeviceProduct and DeviceName, because its Computer column identifies the log forwarder rather than the firewall.
CommonSecurityLog
DeviceVendor
DeviceProduct
DeviceName
Computer
A dated export covering the assessment period is stronger evidence than a current screenshot, since a healthy connector today says nothing about an earlier period. Screenshots support the record when they show the date, scope and tenant or system. Where logging was unavailable, event categories were missing or detections could not operate, document the limitation, its effect on coverage and the resolution.
ASD’s transition guidance identifies monitoring records, validation results and detection engineering artefacts as useful evidence. Each hunt record includes:
The suspected attacker behaviour and its ASD principle, action and domain.
The systems, accounts, data sources, investigation period and exclusions.
Ready, partial or blocked, with limitations recorded.
The queries and investigation steps, versioned so the hunt can be repeated.
The activity observed, legitimate explanations, unresolved questions and incidents identified.
Proposed detections, collection gaps, remediation decisions, owners and evidence of later validation.
A hypothesis library with dated executions lets reviewers see which behaviours were examined, whether the data supported the conclusions and whether earlier gaps were resolved. Useful hunting measures include hypotheses tested with sufficient evidence and the time from identifying a detection gap to validating its remediation. Present them by domain, because an overall detection coverage percentage can conceal unmonitored behaviour in a critical domain. Coverage scores and hunt completion measures describe operational capability. Neither is an ASD action effectiveness rating.
SIEM logging costs come down when security data is selected, filtered and stored according to its detection and investigative value. The evidence ASD Essentials actions need has to survive every saving. Practical measures include:
After checking rule dependencies, drop fields or event categories that support no required detection, hunt or investigation.
Summarise high-volume, low-value records such as allowed firewall flows, keeping detailed records for a shorter period.
Keep active detection data searchable and move suitable history to lower-cost storage with tested retrieval.
Examine ingestion volumes, unused tables and duplicate collection paths each quarter.
Treat every optimisation as a detection coverage decision. Record what is filtered, aggregated or moved, the reason and the rules or investigations it could affect. Aggregating permitted firewall connections may cut ingestion volume, but once the address, destination or timing detail is gone, an investigator may be unable to reconstruct a particular connection. After any change, verify that dependent detections still receive their events and retained records stay accessible. Microsoft Sentinel cost optimisation explains these approaches for organisations using Microsoft’s SIEM.
ThreatDefence runs a 24x7 SOC with its team based in Australia and a 3 min average response under guaranteed SLAs. Threat hunting and an incident response retainer are included in the standard service.
Response actions stay within the authority each customer approves, and case records can be exported for an assessor or at the end of a contract. Australian customers’ data and AI processing stay in Australia.
ThreatDefence does not certify organisations. The assessor determines ASD Essentials ratings.
ThreatDefence delivers SIEM as part of its AI SOC platform and maintains detection content across its SIEM, NDR, identity threat detection and endpoint modules under one licence.
Organisations already using Microsoft Sentinel can retain it as their detection rule platform through Microsoft Sentinel MDR.
The ThreatDefence threat hunting service explains how hunts are scoped and conducted, with a monthly hunting report.
The free ASD Essentials Navigator maps every principle and action by chapter and priority phase, and turns ratings into a board summary. Readers new to the framework can start with the five-minute ASD Essentials explainer, which walks through principles, actions, domains, priority phases and ratings.
Open the ASD Essentials Navigator Start the 5-Minute Explainer Explore ASD Essentials Compliance
See how ThreatDefence automates security monitoring, compliance and cyber risk management in one platform.
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
No, not unchanged. The queries rely on KQL and the platform-specific tables, fields and event structures of Microsoft Sentinel and Defender. The detection behaviours, ASD action mappings and validation scenarios behind them can be implemented in other SIEM platforms.
Translate each query into the destination platform’s data model and query language, confirm equivalent telemetry is available and repeat the positive and negative tests before treating the result as equivalent.
Yes. IT.DET-01.1, assessed in every technical domain, asks organisations to protect event logs including by encrypting them during transit and at rest.
including by encrypting them during transit and at rest.
ASD’s indicators rate encryption in transit without encryption at rest, or the reverse, as partially effective. Logs encrypted in neither location are rated not effective.
The same action restricts access to authorised roles with a business need, so the evidence covers encryption, access permissions and protection against unauthorised modification or deletion.
Detections that depend on the source can stop working while their rules remain enabled. The missing records also weaken the evidence for logging effectiveness in that domain. ASD’s indicators for IT.DET-01.2 rate forwarding as partially effective when coverage gaps exist or completeness has not been validated.
Define a reporting window for every source, monitor last-event times, record each outage’s duration, cause and resolution, and compare reporting with the source inventory to catch systems that never reported.
ASD does not set a fixed log-forwarding latency. The fully effective indicator for IT.DET-01.2 expects records forwarded at a frequency that enables timely detection, while partially effective performance includes latency that is excessive for effective detection.
at a frequency that enables timely detection,
excessive for effective detection.
Set forwarding targets from the detection rules and investigation requirements for each source. Monitor the difference between event time and ingestion time, and synchronise source timestamps with an authoritative time source under IT.DET-02.1.
Yes, when their configuration, coverage and effectiveness can be shown. ASD’s transition guide states that deployment alone does not demonstrate effectiveness. A rule export shows the configured detection. It does not show that the required events were collected or that the alert operated correctly.
deployment alone does not demonstrate effectiveness
Keep action mappings, data dependencies, dated positive and negative test results, tuning records and relevant triage outcomes to show how the detection operated over the assessment period.
No. The enterprise IT and cloud chapters contain no action specifically requiring a threat hunting program, although documented hunts can support DET-05 detection efficacy and IDE-04 security risk identification.
The OT chapter includes an explicit exception. Its GOV-07 action describes threat hunting before reconnection during regular isolation exercises, potentially using host logs, remote access records and network captures.
threat hunting before reconnection
The OT network detection and response guide covers the related network monitoring evidence and operational considerations.
Yes, when its hypothesis, scope, execution and data quality are documented. Record the systems examined, investigation period, queries, available telemetry and whether readiness was complete, partial or blocked. A clean result backed by adequate evidence can contribute to DET-05 detection efficacy.
Where records were missing or coverage was insufficient, record a visibility limitation. Such a hunt is no proof that attacker activity was absent. Hunt results support assessor judgement but do not determine the action rating on their own.
No. ASD’s implementation planning guide identifies control validation testing, purple team activities and breach and attack simulation as possible methods, while noting that advanced testing may not be required for every action.
may not be required for every action.
Choose methods proportionate to the action’s priority, criticality and available capability. Every detection rule still needs a positive sample, a negative sample, a check against retained data for noise and dated results. Purple teaming extends that testing to the complete monitoring and response process.
ASD Essentials SOC, MDR and Incident Response
ASD Essentials Visibility and Response
ASD Essentials Assessment and Checklist