The Identity Security Guide

MITRE ATT&CK TA0001 (Initial Access) and TA0006 (Credential Access) together account for the first steps in the majority of documented cloud breaches. T1078 (Valid Accounts) — using legitimate credentials — is the single most common initial access technique because it bypasses most perimeter controls entirely. The credential is the perimeter.

Modern identity attacks are multi-stage: phishing or credential stuffing for initial access, MFA bypass (T1111) or MFA fatigue for authentication, then privilege escalation via role assumption or permission grant, followed by lateral movement across SaaS and cloud resources. Detecting this chain requires per-entity context across all three stages.

The shift to cloud-first has made identity attacks faster. A human attacker with a valid Okta credential can reach Salesforce, AWS, and GitHub within minutes. An automated attack can enumerate resources, exfiltrate data, and establish persistence in under ten minutes. Detection at each stage must be fast enough to interrupt the chain.

Every identity in the enterprise should have a canonical node in the entity graph: a stable identifier (typically the IdP-assigned unique ID, not the email address which can change), linked to all authentication principals across cloud providers, SaaS applications, and on-premises systems.

Each identity node carries a rolling 90-day behavioural baseline: typical authentication hours, typical source ASN and geolocation, typical device fingerprints, typical application access patterns, typical API call patterns for cloud identities. The baseline is the reference frame for anomaly scoring.

Identity graph construction starts with the IdP (Okta, Entra ID, Google Workspace) as the source of truth. Cloud IAM roles, SaaS application accounts, and service accounts are linked to their canonical identity node via provisioning records or email matching. This linkage is what enables cross-surface detection.

Authentication anomalies: impossible travel (T1078), concurrent sessions from geographically separated locations, first authentication from a new country (for identities with stable geography), authentication outside normal hours for a privileged account, and MFA challenge failure spike (T1110 — Brute Force).

Credential manipulation: MFA factor deactivated (T1556.006), password reset initiated by admin without prior support ticket, new authenticator app enrolled without user-initiated session, and OAuth token scope expansion. Each of these is a persistence or credential-access technique.

Privilege escalation: first assignment to a privileged group, new admin role granted within 24 hours of account creation, role assignment that was not preceded by an approved access request in the ticketing system. The last pattern requires the entity graph to join with the ITSM connector.

MFA is necessary but not sufficient. SMS-based MFA is vulnerable to SIM swapping (T1111); push-notification MFA is vulnerable to MFA fatigue attacks; time-based OTP is vulnerable to real-time phishing proxies like EvilGinx2. The detection programme must account for all three bypass patterns.

MFA fatigue detection: a burst of MFA push challenges to the same identity in a short window (more than 3 in 5 minutes) followed by a successful authentication is a high-confidence fatigue attack. The user_confirm resolver in the triage question set closes the loop — if the user denies, autonomous session revocation fires within 60 seconds.

For confirmed credential compromise: (1) revoke all active sessions via IdP API, (2) disable the account pending investigation, (3) rotate all cloud access keys associated with the identity, (4) audit all actions taken by the identity in the preceding 24 hours via the entity graph, (5) determine lateral movement scope via related entity graph traversal.

The respond agent can execute steps 1–3 autonomously at approve-gated or higher autonomy, depending on your configured ladder. Steps 4 and 5 are outputs of the investigate agent — the analyst receives them as a structured case update, not as a raw log search task.

Integrate your PAM solution (CyberArk, BeyondTrust, Delinea) as an identity graph source. Privileged session recordings and checkout events provide the context for anomalous privileged access: was this privileged session preceded by a PAM checkout? Did the checkout happen outside normal business hours? Was the target system one this user has accessed before?

PAM integration also provides the authorisation baseline: approved access requests that justify certain actions. An IAM permission change preceded by an approved change ticket is low-risk; the same change without an antecedent ticket is high-risk. The entity graph models this relationship.