ASD Essentials IT.DET-02.2 Deploy Detection Rules for Unauthorised Changes, Anomalous Authentication and Suspicious Software Execution
What it says
Ensure detection logic identifies unauthorised changes, anomalous authentication activity and suspicious software execution.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSets rules to alert on unapproved changes, odd sign-ins and suspicious programs, and keeps them tested and tuned.
Break-ins often leave warning signs, such as a setting changed without approval, an unusual sign-in or a strange program running. The organisation writes automatic rules that watch its security logs for these signs and alert the security team. Nobody has to read logs by hand to find them. To meet this, rules cover all three signs and are tested and adjusted on a set schedule. Coverage is also reviewed after incidents or major changes.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?Visibility and response: a capability domain, which ASD applies across all phases from the start.
Why it matters
Without detection rules, an intruder using stolen logins, changing settings or running harmful programs can work unseen. A missing type of rule, or untested rules, leave blind spots and floods of false alarms, so real break-ins are missed or dismissed.
How to implement
Detection engineers should build rules that compare setting changes with approved change records and authorised accounts.
Alert on anything unapproved, starting with security settings and admin groups.
The security operations team should learn the normal sign-in patterns of staff, admins and accounts that apps use.
Alert on odd activity, such as bursts of failed sign-ins, repeated multi-factor prompts or new locations.
Device and server admins should send the detection system events for programs started, scripts run and unapproved programs blocked.
Add rules for suspicious activity, such as programs run from temp folders or office apps opening command shells.
The security operations manager should set every rule to run by itself against central logs and send alerts to the analysts' queue.
Keep a rule list with each rule's type, data sources and owner.
The detection lead should test each rule on an agreed schedule by safely copying the activity it should catch.
Tune it with alert results and threat intelligence, and review coverage after each incident or major change.
Keep it running
Security operations, whether in-house or a managed provider, uses false alarms, missed attacks and new threat intelligence to tune the rules each round. Add a detection coverage check to every post-incident review. Add one to change management for major changes too, such as a new sign-in system or device security software. This action applies organisation-wide, in every priority phase, so set it up early and assess it once, not per group of systems.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the detection rule list or an export of active rules with their types.
Look at
Whether any of the three types is missing, or listed rules are switched off or still in draft.
Good evidence
Active, owned rules cover unapproved changes, unusual sign-ins and suspicious programs, and all raise alerts.
- Check 2 of 5What an auditor asks for
Ask for
Request recent alerts of each type, and the rule and event behind a sample.
Look at
Whether a type relies on manual log searches, or sampled alerts came from analysts, not rules.
Good evidence
Rules raise alerts automatically for all three types, each traced to its triggering event.
- Check 3 of 5What an auditor asks for
Ask for
Ask the team to run one approved test event of each type and show the alerts.
Look at
Whether any test event raises no alert or can be found only by searching logs by hand.
Good evidence
Every test event is captured and produces an alert.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the set testing and tuning schedule and records from recent rounds.
Look at
Whether a schedule is set, and whether failing or noisy rules are left unchanged.
Good evidence
Each rule's last test falls within the set schedule, and a tuning log records each change.
- Check 5 of 5What an auditor asks for
Ask for
Request recent incident reports and major change records, with any coverage reviews that followed.
Look at
Whether incidents, or changes such as a new sign-in system, had no coverage review, or gaps stay open.
Good evidence
Post-incident and major change reviews include a coverage check, and gaps lead to rule changes.
ASD indicators of good practice (7)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(2)
- NE-1No detection logic is deployed to identify unauthorised changes, anomalous authentication activity or suspicious software execution events originating from assets.
- NE-2Detection relies entirely on manual log review with no automated rules or alerting.
Partially effective(2)
- PE-1Detection logic exists but does not cover all three categories (unauthorised changes, anomalous authentication, suspicious execution).
- PE-2Rules are deployed but are not tested or tuned on a regular cycle defined by the organisation.
Fully effective(3)
- FE-1Detection logic is deployed, and unauthorised configuration changes, anomalous authentication patterns and suspicious process execution events are captured and produce alerts.
- FE-2Detection logic is tested and tuned on a regular cycle defined by the organisation to maintain effectiveness.
- FE-3Detection coverage is reviewed following cyber security incidents or significant environmental changes.
Mappings
Closest match in ISO/IEC 27001: A.8.16, Monitoring Networks and Systems for Anomalous Behaviour, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.16.
IT.DET-02.2 requires detection logic that identifies unauthorised changes, anomalous authentication activity and suspicious software execution. This is a specific implementation of the monitoring for anomalous behaviour that Annex A 8.16 requires across networks, systems and applications. Annex A 8.16 is broader, as it is not limited to these activities and also requires appropriate action to evaluate potential information security incidents.
ASD Essential Eight: 6 mappings
This control partially overlaps E8-AC-ML2.5.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; E8-AC-ML2.5 requires allowed and blocked application control events to be centrally logged, which supports detecting suspicious software execution.
This control partially overlaps E8-AC-ML3.5.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; E8-AC-ML3.5 requires workstation event logs to be analysed in a timely manner to detect cyber security events, applying detection to workstations.
This control partially overlaps E8-AH-ML3.5.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; E8-AH-ML3.5 requires timely analysis of event logs from workstations to detect cyber security events, so the two overlap on detection at workstations.
This control partially overlaps E8-MF-ML2.6.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; E8-MF-ML2.6 requires central logging of successful and unsuccessful multi-factor authentication events, which helps detect anomalous authentication.
This control partially overlaps E8-MF-ML3.5.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; E8-MF-ML3.5 requires timely analysis of workstation event logs to detect cyber security events, analysis that such detection logic supports.
This control partially overlaps E8-RA-ML3.9.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; E8-RA-ML3.9 requires event logs from workstations to be analysed in a timely manner to detect cyber security events, one place where that logic can be applied.
ASD Information Security Manual: 2 mappings
This control partially overlaps ISM-1986.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; ISM-1986 requires timely analysis of critical server event logs to detect cyber security events, applying detection to those servers.
This control partially overlaps ISM-2116.
IT.DET-02.2 requires detection logic for unauthorised changes, anomalous authentication activity and suspicious software execution; ISM-2116 requires cyber threat intelligence services to be used to support the detection of cyber security events, which can help inform that logic.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.