An identity threat detection and response (ITDR) tool only earns its place if it sees every identity system that matters, raises alerts the SOC trusts and can act fast without locking out the business, and most of that is decided during rollout rather than by the product. This playbook covers deploying an ITDR tool as a product class: scoping use cases, connecting directory, identity provider, cloud and non-human identity telemetry in waves, tuning detections in observe mode, introducing automated response in stages, and handing over to operations with metrics. It is vendor-neutral and draws on the joint agency guidance on Active Directory compromises, CISA advisory AA23-320A, NIST SP 800-61 Rev. 3, NIST SP 800-53 Rev. 5 and MITRE ATT&CK. It is written for SOC leads, identity security engineers and detection engineers. Product selection is covered in the ITDR Buyer's Guide, the discipline in the ITDR Guide, and protecting the tool itself in Securing the identity threat detection and response (ITDR) tool itself.
Key takeaways
- Start from the attacks you must catch. Write a short list of identity attack scenarios, mapped to ATT&CK, and judge every rollout phase by how many of them the tool now detects.
- Coverage beats features. An unmonitored domain controller, identity provider tenant or cloud account is a blind spot attackers will find; track sensor and connector coverage as the first metric.
- Observe before you act. Run detections in alert-only mode for at least one full business cycle and tune them before any automated response is switched on.
- Grow response in stages. Move from notify, to step-up and session revoke, to disable, only as precision is proven, and keep tier 0 and break-glass accounts under human approval.
- Include non-human identities. Service accounts, workload identities and API credentials are in the attack paths; if the tool cannot see them, plan how they will be covered.
Phase 0: use cases, scope and ownership
Define what the tool must detect before connecting anything. CISA advisory AA23-320A (revised 21 November 2023) is a useful anchor: it describes help desk impersonation, MFA fatigue (T1621), attackers adding a federated identity provider with automatic account linking (T1484.002) and registering their own MFA devices (T1556.006). The joint guidance from ASD, CISA, NSA and partners on Active Directory compromises adds 17 directory techniques with the events that reveal them.
| Priority scenario | ATT&CK | Telemetry needed |
|---|---|---|
| Password spraying against directory or identity provider | T1110.003 Password Spraying | Directory and IdP sign-in failures, source IPs |
| Kerberoasting and AS-REP roasting | T1558.003, T1558.004 | Domain controller events 4769 and 4768 with encryption type |
| DCSync and directory database theft | T1003.006, T1003.003 NTDS | Event 4662 replication rights from non-directory hosts |
| Forged tickets and certificates | T1558.001 Golden Ticket, T1649 | Kerberos events, certificate authority events 4886 and 4887 |
| MFA fatigue and attacker MFA registration | T1621, T1556.006 | IdP MFA prompts, denials and authenticator registrations |
| Federation and trust tampering | T1484.002 Trust Modification | IdP admin audit log, directory trust changes |
| Hybrid identity abuse | T1556.007 Hybrid Identity | Sync and pass-through authentication servers |
| Valid domain account misuse | T1078.002 Domain Accounts | Logon events, baselines of normal hosts and times |
Also agree in this phase:
- Ownership: who triages ITDR alerts (SOC or identity team), who owns tuning, and who can approve response actions on privileged accounts.
- Relationship to the SIEM and EDR: whether ITDR alerts flow into the SIEM as the case system, and which tool owns each detection to avoid duplicates. See ITDR vs SIEM and ITDR vs EDR.
- Posture versus detection: whether identity posture findings (stale accounts, risky delegation, excessive rights) are in scope now or later. See ISPM vs ITDR.
- Data handling: what identity data leaves your environment, where it is stored, for how long, and who at the provider can see it.
Phase 1: deploy the tool as a tier 0 system
An ITDR tool reads domain controllers, holds directory and cloud credentials and may be allowed to disable accounts, so it sits at the same tier as the systems it watches. The joint guidance recommends treating anything with that reach as tier 0. Before the first sensor goes live:
- Console access: named admin accounts only, phishing-resistant MFA, roles split between configuration, response approval and read-only analyst (NIST SP 800-53 AC-6 and IA-2).
- Connector credentials: each directory, IdP and cloud connector uses its own dedicated identity with read-only rights unless response is planned; record owner and rotation. Managed service accounts or federated workload credentials are preferable to static secrets. See the Secrets Management Guide.
- Sensors on domain controllers: sensor software on tier 0 hosts is tier 0 code; agree update channels, change control and how to remove it quickly.
- Tool audit log: stream the tool's own admin and response logs to the SIEM so changes to detections, exclusions and response rules are visible.
The deep controls for each of these are in Securing the identity threat detection and response (ITDR) tool itself; this playbook does not repeat them.
Phase 2: connect telemetry in waves
Connect sources in the order attackers use them. Do not move to the next wave until each source in the current one is confirmed complete, not just connected.
| Wave | Sources | Completeness check |
|---|---|---|
| 1 | All domain controllers in every domain and forest, certificate authorities | Every writable and read-only replica reports; Kerberos and replication events visible |
| 2 | Workforce identity provider tenants, MFA service, federation servers | Sign-in, MFA, authenticator registration and admin audit events present |
| 3 | Hybrid sync and pass-through authentication servers, PAM vault | Sync account activity and privileged session events visible |
| 4 | Cloud provider identity planes (roles, keys, service principals) | Every production account or subscription connected |
| 5 | SaaS admin logs, OAuth app grants, secrets managers | Highest-risk SaaS tenants and non-human identity sources covered |
- Directory audit policy: the tool can only detect what domain controllers log. Confirm the audit settings generate the events the joint guidance relies on, including 4662, 4768, 4769, 4741 and 1102 (NIST SP 800-53 AU-12). See the Active Directory Security Monitoring and Event IDs Guide.
- Time and identity resolution: synchronised clocks and a mapping of accounts across directory, IdP and cloud, so one person or service shows as one identity with linked accounts.
- Non-human identity context: import service account inventories with owner, purpose and expected hosts, so the tool can flag a service account logging on interactively or from a new host. See the NHI management platform rollout playbook.
- Tier tags: label tier 0 accounts, groups and hosts in the tool so alerts on them are prioritised.
Phase 3: tune detections in observe mode
Keep every detection in alert-only mode during this phase, for at least one month that includes a period end, password expiry cycle or other peak. Behavioural baselines need that history.
- Triage every alert: classify as true positive, benign true positive (real activity, approved) or false positive, and record the reason.
- Fix the cause, not the alert: a vulnerability scanner that triggers reconnaissance alerts needs a narrowly scoped exclusion with an owner and expiry; a service account using RC4 needs fixing in the directory.
- Exclusions are risk decisions: every exclusion records the account or host, the detection, the business owner and a review date. Broad exclusions for whole OUs or service account groups recreate the blind spots the tool was bought to remove.
- Validate with controlled tests: once noise is down, run authorised, scheduled tests of the priority scenarios in a test domain or with approved accounts and confirm each fires with the right severity. See ITDR validation.
- Plant canaries: decoy accounts and credentials that should never be used give near-zero false positive alerts; the joint guidance suggests a canary Group Policy Preferences password for exactly this reason. See the Honeytokens and Canary Credentials Guide.
Phase 4: introduce response in stages
Automated identity response is powerful and can cause outages. Introduce it as precision is proven, per detection, not as a global switch.
| Stage | Actions | Entry condition | Human approval |
|---|---|---|---|
| 1 Notify | Alert, open a case, notify the user or manager | From go-live | None |
| 2 Contain softly | Force step-up MFA, revoke sessions and refresh tokens, block a source IP | Detection precision agreed as acceptable over a full cycle | Not for standard users; yes for tier 0 |
| 3 Contain hard | Disable account, reset password, remove from group, isolate host via EDR | Stage 2 stable, rollback tested | Always for tier 0, service accounts and break-glass |
- Protect the protectors: never let automation disable break-glass accounts, the tool's own connectors or the last working tier 0 admin. See the Break-Glass Account Guide.
- Service accounts: disabling a production service account can stop a business process; route these to the owner with a short approval window and a pre-agreed fallback.
- Kerberos reality: disabling an account does not invalidate tickets already issued, and forged tickets need a double reset of the ticket-granting account, which the joint guidance describes with replication time between resets. Response runbooks must say so.
- Orchestration: if response runs through SOAR, the playbook credentials are as sensitive as the tool's. See the SOAR platform rollout playbook.
- Rollback: every automated action has a documented reversal (re-enable, restore group membership) and a log entry linking it to the alert.
The Uber Breach 2022 illustrates the stage 1 to 2 path: a contractor accepted a push prompt after repeated requests. A detection for bursts of denied MFA prompts, followed by session revocation and a forced phishing-resistant re-enrolment, is the kind of response an ITDR rollout should make routine.
Phase 5: operations handover
- Runbooks per detection: what the alert means, triage questions, evidence to collect, containment options and escalation, aligned to the incident response plan. NIST SP 800-61 Rev. 3 (April 2025) frames incident response as part of CSF 2.0 risk management, so link runbooks to the Respond and Recover functions rather than a standalone process.
- Escalation to full identity incident: agree the threshold at which an alert becomes an identity incident. See the Identity Incident Response Playbook and the Active Directory Domain Compromise Response Playbook.
- Change feed: new domains, IdP tenants, cloud accounts and SaaS tenants must trigger connector onboarding; tie this to the change process.
- Tuning cadence: monthly review of exclusions, false positive rates and new detections released by the provider.
- Retest: repeat the controlled scenario tests at least twice a year and after major changes.
Decision guidance
| Decision | Option A | Option B | Choose A when |
|---|---|---|---|
| Directory telemetry | Sensors on domain controllers | Log and network collection only | You need Kerberos and replication detail in near real time; B suits environments that cannot accept agents on tier 0 |
| Alert destination | SIEM as the single case queue | ITDR console worked directly | A SOC already runs the SIEM; B suits a small identity team without a SOC |
| Response | Automated for standard users | Analyst-approved for all | Precision is proven and the SOC is not staffed around the clock |
| Rollout order | Directory first | Cloud IdP first | On-premises directory is still the source of privilege; choose B for cloud-first estates with little on-premises identity |
Small versus large organisations: a small organisation can often run with a managed detection service working the ITDR console, a handful of high-confidence detections and stage 2 response for standard users. A large organisation needs a detection engineering owner, multi-forest and multi-tenant coverage tracking, regional response approval and integration with SIEM, SOAR and the change process. In both, tier 0 coverage and controlled testing come first.
Detection and measurement
Monitor the tool itself as well as what it detects: connector failures, sensor version drift, dropped events, new exclusions and changes to response rules should all alert. Rollout metrics:
| Metric | What it shows |
|---|---|
| Identity systems with healthy connectors / identity systems in the register | Coverage, by wave |
| Priority scenarios detected in controlled tests / scenarios defined | Real detection capability |
| Alert precision (true and benign true positives / all alerts) per detection | Whether alerts are trusted and ready for response |
| Median time from identity alert to containment action | Response speed |
| Open exclusions past review date | Whether blind spots are growing |
| Non-human identities with owner and expected behaviour recorded | Whether service account detections have context |
Once live, move to the quarterly Identity threat detection and response (ITDR) tool health check.
Framework mapping
| Rollout element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Identity telemetry collection | AU-12 Audit Record Generation | DE.CM-03 | 8.2 |
| Detection and analysis | SI-4 System Monitoring, AU-6 | DE.AE-02 | 8.11, 13.1 |
| Response actions and runbooks | IR-4 Incident Handling | RS.MA-01 | 17.4 |
| Tool admin and connector privileges | AC-6 Least Privilege | PR.AA-05 | 5.4 |
| Identity and credential context | AC-2 Account Management, IA-5 | PR.AA-01 | 5.1 |
Common failure patterns
- Partial domain controller coverage: sensors on the main site only, so an attacker working through a branch or read-only replica goes unseen.
- Cloud and SaaS left for later: the rollout stops after the directory, missing IdP and cloud attacks such as federation tampering.
- Exclusion creep: noisy service accounts are excluded wholesale, and those are exactly the accounts attackers target.
- Automation before tuning: hard containment switched on in week one disables a production service account and the business demands the tool is turned off.
- No owner for alerts: alerts land in a console the SOC does not watch and the identity team does not staff.
- Tool not treated as tier 0: broad console access and static connector secrets make the ITDR tool an attack path in its own right.
Practitioner checklist
- Write the priority identity attack scenarios with ATT&CK IDs and required telemetry.
- Agree alert ownership, SIEM integration and response approval authority before go-live.
- Deploy the tool as tier 0: named admins, phishing-resistant MFA, dedicated connector identities.
- Connect every domain controller and CA first, then IdP, hybrid, cloud and SaaS sources.
- Confirm directory audit policy produces the events the detections depend on.
- Run detections in alert-only mode for a full business cycle and triage every alert.
- Give every exclusion an owner and review date; avoid OU-wide or group-wide exclusions.
- Validate each priority scenario with authorised controlled tests and plant canary accounts.
- Introduce response in stages with human approval for tier 0, service and break-glass accounts.
- Hand over runbooks, the change feed and baseline metrics to the quarterly health check.
Standards and references
- ASD, CISA, NSA and partners: Detecting and Mitigating Active Directory Compromises
- CISA: Scattered Spider Advisory AA23-320A
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: SP 800-207 Zero Trust Architecture
- MITRE ATT&CK: Multi-Factor Authentication Request Generation
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Trust Modification
Related NHI Mgmt Group resources: ITDR Buyer's Guide, Identity threat detection and response (ITDR) tool health check, ITDR and ISPM Maturity Model, SIEM rollout playbook, Directory service (LDAP and Active Directory) rollout playbook.