Identity Security
What this domain tests
Identity Security tests how identity becomes a security control. Expect authentication and authorization, directory integration, User-ID, MFA and conditional access, privileged accounts, and identity threat detection and response.
Core rules
- Authentication proves who a subject is; authorization decides what it can do. Federation with SAML or OIDC and provisioning with SCIM let the identity provider supply groups and lifecycle changes.
- User-ID maps IP addresses to users for firewall policy. It is useful context, but it is not a substitute for per-request authentication. Mappings can be stale after IP reuse.
- Least privilege means narrow roles, just-in-time elevation, and separation of duties. Service accounts need owners, rotation, and monitoring, not permanent exemptions.
- ITDR correlates identity telemetry with endpoint and network evidence. Look for password spray, impossible travel, MFA fatigue, Kerberoasting, token theft, and suspicious role changes.
Worked example
A helpdesk account signs in at 02:00 from a new country, creates a new global administrator, and disables audit logging. The identity provider reports the sign-in, XDR shows the helpdesk workstation running a credential-stealing tool, and the SIEM links the new admin account to the same source. Response: revoke sessions and refresh tokens, reset credentials, remove the rogue admin, re-enable logging, and review what the new admin accessed. The correlation matters because any single alert could look like a legitimate admin action.
Traps that cost marks
Do not treat a successful VPN or SSO login as blanket trust. Do not add users to broad groups to simplify policy. Do not leave stale User-ID mappings that misattribute traffic. Do not exempt service accounts from monitoring. Do not approve an MFA prompt just because the password was correct.