Most SOCs cannot answer a simple question about identity: which identity attacks would we actually see today, from which logs, and who fixes the rule when it breaks? Identity detections are scattered across the SIEM, the identity provider's own risk engine, endpoint tools and cloud threat detection services, and nobody holds the list. This template gives [Organisation] a single catalogue of identity detection use cases: one row per behaviour, with the data source it depends on, the rule that implements it, the people who own it and its current status. It comes pre-seeded with 24 use cases across workforce sign-in, Active Directory, cloud and non-human identities (NHIs). It is for detection engineers, SOC managers and identity teams. Per-rule documentation belongs in the Detection Rule Documentation Template; this catalogue is the portfolio view above it.
How to use this template
- Keep one catalogue, in version control or a shared register, not a slide. Each row links to its rule file and its rule record.
- Seed it from section 5, delete rows that do not apply, then add your own. Every row must have a named owner before it counts.
- Mark status honestly. A rule that exists but has never fired a validated true positive is "Built", not "Live".
- Use it to drive work. Gaps in the data source column become log onboarding tasks; gaps in the rule column become detection engineering backlog. See the Detection Engineering Guide.
- Feed it from exercises. Every "no alert" finding from a tabletop or purple team becomes a new row. See the Identity Attack Tabletop Exercise Scenarios.
1. Purpose
1.1 This catalogue records every identity threat detection use case [Organisation] operates or plans, so that coverage, ownership and data dependencies are visible in one place.
1.2 It is the authoritative list for identity detection coverage reporting to [CISO / security committee].
2. Scope
2.1 In scope: detections whose subject is an identity, credential, session or trust, for workforce users, administrators, service accounts, service principals, cloud roles, API keys, OAuth applications, CI/CD identities and AI agents.
2.2 Sources in scope: [workforce identity provider], [Active Directory domain controllers], [AWS / Azure / Google Cloud audit logs], [SaaS audit logs], [CI/CD and source control audit logs], [secrets manager audit logs], [EDR].
2.3 Native detections from vendor risk engines are recorded too, with the vendor detection name in the rule column, so the catalogue shows where [Organisation] relies on them.
3. Roles
| Role | Named person | Responsibility |
|---|---|---|
| Catalogue owner | [Detection engineering lead] | Maintains the catalogue, runs the review, reports coverage |
| Use case owner | [Per row] | Accountable that the detection works and is tuned |
| Data source owner | [Per source] | Keeps the log flowing, alerts on outages |
| Response owner | [SOC lead or identity team] | Owns the triage and containment steps when it fires |
| Identity platform owner | [Name] | Advises on platform events and confirms what is normal |
4. Catalogue fields
| Field | What to record | Example |
|---|---|---|
| ID | Stable identifier, never reused | IDT-012 |
| Use case | One behaviour, in plain words | Credential added to a service principal outside the pipeline |
| Identity type | Human, privileged human, NHI, AI agent, third party | NHI |
| ATT&CK | Technique ID and name | T1098.001 Additional Cloud Credentials |
| Data source | Log, table and the specific event or operation | Entra audit log: "Add service principal credentials" |
| Data source status | Collected, partial, not collected, needs enabling | Collected |
| Detection type | Single event, threshold, baseline deviation, correlation, native vendor detection | Single event with allowlist |
| Rule reference | Rule file path or vendor detection name | rules/entra/sp_credential_added.yml |
| Context lookups | Inventory or lists the rule depends on | NHI inventory: owner, pipeline identity |
| Severity | Your scale, with reasoning in the rule record | High |
| Status | Proposed, Built, Live, Tuning, Retired | Live |
| Use case owner | Named person | [Name] |
| Response playbook | Link to playbook or runbook | Cloud credential compromise |
| Last validated | Date of last true positive test | [YYYY-MM-DD] |
| Alert volume and precision | Last 90 days | [n alerts, n% true or benign positive] |
| Known blind spots | What it will miss | Credentials added by the pipeline identity itself |
5. Seed use cases
5.1 The rows below are a starting set. Data source names are from vendor documentation; confirm each against your platform, and that the event is actually collected, before marking a row Built.
5.2 Workforce sign-in and MFA
| ID | Use case | ATT&CK | Data source | Detection type |
|---|---|---|---|---|
| IDT-001 | Password spraying: many accounts, few attempts each, from one source | T1110.003 | IdP sign-in logs; DC 4625 / 4771 | Threshold |
| IDT-002 | Credential stuffing against external apps | T1110.004 | IdP or application sign-in logs | Threshold |
| IDT-003 | Repeated MFA prompts then approval | T1621 | IdP sign-in and MFA logs | Correlation |
| IDT-004 | New MFA method registered, especially on privileged accounts | T1556.006 | Entra audit "User registered security info" or IdP equivalent | Single event (privileged), baseline (others) |
| IDT-005 | Help desk reset followed by new MFA and sign-in from a new location | T1078 | ITSM tickets, IdP audit and sign-in logs | Correlation |
| IDT-006 | Session used from a new network or device after sign-in elsewhere | T1539 | IdP sign-in logs, native risk detections | Native or correlation |
| IDT-007 | New device registered to an account | T1098.005 | IdP device and audit logs | Baseline |
5.3 Active Directory
| ID | Use case | ATT&CK | Data source | Detection type |
|---|---|---|---|---|
| IDT-008 | Service account used for interactive or remote interactive logon | T1078.002 | 4624 logon types 2 and 10, joined to service account list | Single event |
| IDT-009 | Kerberoasting: RC4 service tickets or one account requesting many SPNs | T1558.003 | 4769 with encryption type | Threshold |
| IDT-010 | Replication requested from a non-domain controller | T1003.006 | 4662 with replication rights, or network detection | Single event |
| IDT-011 | Member added to a privileged group without a change record | T1078.002 | 4728, 4732, 4756 | Correlation with change system |
| IDT-012 | SID History added, audit policy changed or DSRM password set | T1134.005 (SID History rows) | 4765, 4719, 4794 (Microsoft rates these High: investigate on a single occurrence) | Single event |
5.4 Cloud and identity provider control plane
| ID | Use case | ATT&CK | Data source | Detection type |
|---|---|---|---|---|
| IDT-013 | Credential added to a service principal or application outside the pipeline | T1098.001 | Entra audit "Add service principal credentials", "Update application - Certificates and secrets management" | Single event with allowlist |
| IDT-014 | New AWS access key created by an unexpected principal | T1098.001 | CloudTrail IAM events (CloudTrail logs all IAM and STS actions) | Single event with allowlist |
| IDT-015 | Google Cloud service account key created | T1098.001 | Admin Activity log: google.iam.admin.v1.CreateServiceAccountKey | Single event |
| IDT-016 | Service account impersonation by a new principal | T1078.004 | Data Access log: GenerateAccessToken on iamcredentials.googleapis.com (Data Access audit logs must be enabled) | Baseline |
| IDT-017 | Privileged role granted to an identity | T1098.003 | CloudTrail, Azure activity log, Google Cloud Admin Activity log | Single event (privileged roles) |
| IDT-018 | Federation or domain authentication settings changed | T1484.002 | Entra audit "Set federation settings on domain", "Set domain authentication" | Single event |
| IDT-019 | Cloud account or identity created by a machine identity outside provisioning | T1136.003 | Cloud audit logs | Single event with allowlist |
| IDT-020 | Instance credentials used from outside the cloud | T1552.005 | CloudTrail source IP versus role session origin, native threat detection | Native or correlation |
5.4.1 AWS note: STS calls made to the global endpoint are logged in US East (N. Virginia), so collect that Region even if you do not deploy there.
5.5 SaaS, OAuth, CI/CD and AI agents
| ID | Use case | ATT&CK | Data source | Detection type |
|---|---|---|---|---|
| IDT-021 | Consent granted to an application with high-privilege scopes | T1528 | Entra audit "Consent to application", "Add delegated permission grant"; SaaS equivalents | Single event (high scopes) |
| IDT-022 | Application or API token used from a new network | T1550.001 | SaaS and source control audit logs with token identifier | Baseline |
| IDT-023 | Secrets manager read by an unexpected principal or in bulk | T1555.006 | Secrets manager audit log | Baseline and threshold |
| IDT-024 | Honeytoken credential used anywhere | T1078 | Platform audit logs where the decoy lives | Single event |
5.6 For the logic behind these rows see the Detection Engineering for Non-Human Identities Guide, the Active Directory Security Monitoring and Event IDs Guide, the Cloud Detection Engineering Guide and the Honeytokens and Canary Credentials Guide.
6. Lifecycle and review
6.1 A use case moves Proposed, Built, Live, Tuning or Retired. It becomes Live only when it has a named owner, a rule record, a linked response playbook and a validated true positive. ADS, the format the rule record is based on, expects every section completed before production.
6.2 The catalogue owner reviews the catalogue every [quarter]: stale validation dates, rows with no owner, data sources that stopped, and rows with no alerts and no validation in 90 days.
6.3 Retire a use case with a recorded reason, never by silently disabling the rule.
7. Coverage reporting
| Metric | How to calculate | Target (our recommendation) |
|---|---|---|
| Live coverage | Live use cases / in-scope use cases | [Rising each quarter] |
| NHI coverage | Live NHI use cases / NHI use cases in the catalogue | Parity with human use cases |
| Data source readiness | Rows whose data source is collected / all rows | [95%] |
| Validation freshness | Live rows validated in the last 180 days / Live rows | [90%] |
| Ownership | Rows with a current named owner / all rows | 100% |
| Precision | True and benign true positives / alerts, per row | Track per rule; retune the worst five each quarter |
Implementation guidance
- Week 1: load existing identity rules and native vendor detections into the catalogue as they are, with whatever owner is known.
- Weeks 2 to 4: fill the data source column by checking that each event really arrives in the SIEM. Route every missing source to the SIEM Log Source Onboarding Checklist.
- Month 2: add the seed rows you lack, starting with single-event rules (IDT-004, IDT-012, IDT-013, IDT-018), which are cheap and rarely noisy.
- Month 3: validate each Live row with a safe test in a lab or test tenant (our recommendation; the ADS framework includes a Validation section) and record the date.
- Ongoing: add rows from incidents, exercises and threat intelligence; report the coverage metrics each quarter.
Common failure patterns: counting rules that have never fired; listing native vendor detections without checking licensing or that they are enabled; a catalogue that covers only humans; Data Access logs assumed but not enabled; owners who left the organisation.
| Catalogue activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Logging the required events | DE.CM-03 | AU-2, AU-12 |
| Running the detections | DE.AE-02 | SI-4, AU-6 |
| Review and improvement | ID.IM-02 | CA-7 |
References: Palantir: Alerting and Detection Strategy Framework · Microsoft Learn: Microsoft Entra audit log activity reference · Microsoft Learn: Appendix L Events to Monitor · AWS: Logging IAM and AWS STS API calls with AWS CloudTrail · Google Cloud: Examples of audit logs for service accounts · MITRE ATT&CK: T1098.001 Additional Cloud Credentials
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: ITDR Guide · Identity Threat Hunting Guide · Detection as Code Guide · UEBA Guide