Identity-centric cybersecurity

Monday, 7:43 in the morning

David works in finance at a mid-sized fintech in Central America, 400 employees and 200,000 active customers. The company uses Microsoft Entra ID as its identity provider, employees approve sign-ins with a push notification on a phone app, and a regional security provider runs a shared SOC. At 7:43 on a Monday, an email that looks like it’s from HR lands in the inbox of thirty employees, with a PDF about a “benefits update”. Three of them click. David is one, and he types his credentials into a page that looks exactly like the Entra ID sign-in screen.

By 7:51 the attacker is signing in as David from an IP address in another country. Entra ID asks for MFA, so the attacker sends push notification after push notification to David’s phone. After the fifth in a row, half asleep and assuming the system is glitching, David taps “approve”. By 7:55 the attacker is reading David’s email, looking for anything useful, and finds a thread in which colleagues discuss the credentials of the treasury system. At 9:12 they sign in to that system with treasury_app, a service account whose password hasn’t changed in four years.

Nobody notices until Tuesday afternoon. Everything that happened is in the logs, but nobody was looking at them. Keep this story in mind; we’ll come back to it with names for each step.

The two previous articles laid the groundwork: what a digital identity is and the four modern kinds of identity, people, devices, workloads and AI agents, ending with the claim that identity is today’s “new perimeter”. That’s a bold claim, and this article backs it up through three lenses. The first is an organizational framework, the NIST Cybersecurity Framework, which shows where IAM fits in the wider discipline. The second is a catalog of attacker behavior, MITRE ATT&CK, which teaches you to think like the person on the other side and see why credentials are their favorite target. The third is two industry reports, the Verizon DBIR and Mandiant M-Trends, which bring hard numbers about what actually happens. Being able to move between those three is a large part of what separates someone who “knows IAM” from someone who can explain it to auditors, regulators and boards.

NIST CSF: the common language

The NIST Cybersecurity Framework, or CSF, is probably the most widely adopted framework for talking about cybersecurity in organizational terms. It was created in 2014 at the US government’s request for critical infrastructure, and it soon became the shared language of companies, auditors and regulators in much of the world. When a CISO asks “how are we covering Detect?”, they’re speaking CSF.

It became so popular for a practical reason: it doesn’t tell you which tool to buy or which process to follow. It gives you a map of the functions any security program has to cover and lets you decide how to cover them in your own context. It’ll tell you that you need to cover Identify, not whether you do it with SailPoint, a spreadsheet or a script you wrote, which is why it suits a five-person startup as well as a global bank.

Until 2023 the CSF had five functions: Identify, Protect, Detect, Respond and Recover. In February 2024, NIST published version 2.0 and added a sixth, Govern, which sits over the other five. The reason was that many organizations had the technical capabilities but not the governance to keep them going.

Fullscreen

The dashed arrow from Recover back to Identify matters: every incident feeds the next cycle, and if you don’t learn from what happened, you’ll live through it again. In identity terms each function has a concrete face. Govern is a policy such as “MFA is mandatory for all production access”, approved by the executive committee. Identify is knowing every identity, human and non-human, and what each one can reach. Protect is MFA, single sign-on, a password vault, least privilege and separation of duties. Detect is alerting on sign-ins from impossible places, MFA bombing and unexpected privilege escalation. Respond is revoking sessions, disabling compromised accounts and isolating an identity. Recover is issuing new credentials, restoring clean access and writing a post-mortem that leads to real improvements.

Where IAM fits in the CSF

Here’s the sentence worth remembering: IAM mainly covers the first three functions, Identify, Protect and Detect, and ITDR, Identity Threat Detection and Response, covers the last two, Respond and Recover, when the threat involves identity.

Fullscreen

In reality the lines blur. An identity governance tool can help with Detect through analytics, and an identity provider can help with Respond by revoking sessions. But as a mental map, this split is the one the industry uses most.

Identify answers “what do I have, and what could happen to it?” For IAM that means an inventory of identities, human and non-human, with their attributes, owners and lifecycle; an inventory of applications and of who reaches what; a map of privileged accounts and where they live; and a risk score per identity that shows who is most exposed. If your organization can’t say within 24 hours how many former employees still have access to some application, Identify has a gap.

Protect answers “what do I put in the way so the damage doesn’t happen?” Strong authentication, with MFA everywhere, passkeys and fewer and fewer passwords. Fine-grained authorization, with least privilege and separation of duties. Automatic provisioning, so people get the right access when they join and lose it when they leave. Privileged access management, with admin accounts in a vault, recorded sessions and access granted just in time. And training, including phishing simulations. Most IAM programs spend most of their money here, because it’s where the visible results are: “we rolled out MFA to fifty applications”.

Detect answers “how do I find out quickly when something’s wrong?” Logs of every authentication, every authorization decision and every configuration change. Alerts on unusual patterns: a sign-in from Madrid at 14:00 and from Tokyo at 14:05, ten push notifications in sixty seconds, accounts created out of nowhere, privilege escalation at three in the morning. And integration with the SIEM and SOAR, so identity events can be correlated with network, endpoint and data events. This is where classic IAM, an identity provider plus a governance tool, stops being enough on its own. The logs exist, but someone has to look at them.

That someone is ITDR. Gartner gave the category its name around 2022, and the idea is that identity infrastructure, Active Directory, Entra ID, Okta and the like, has become a prime target and needs its own detection and response layer, the way endpoints have EDR. An ITDR tool looks for exposure, such as forged Kerberos golden tickets in use, Kerberoasting paths, hidden admins and accounts with inflated permissions. It applies behavior analytics to the identity layer to catch what fixed rules miss. When it raises an alert it can act on its own, revoking sessions, disabling accounts, forcing a fresh sign-in and paging the SOC. And afterwards it lets you reconstruct which identity did what and when. Microsoft Defender for Identity, CrowdStrike Falcon Identity Protection, Silverfort, Semperis and Quest all work this way, instrumenting the identity infrastructure and spotting anomalies the identity provider doesn’t flag on its own (they’re named as examples, not recommendations).

A simple way to keep the two apart: IAM is the guards who let people in and out of the building, checking badges, noting arrival times and handing out the keys to each floor. ITDR is the cameras and motion sensors that notice something’s off: someone loitering at three in the morning where they shouldn’t be, someone trying twenty doors in a row, the same key used on two floors at once. The guards are essential, but they can’t be everywhere. The cameras are what let you see at scale, and a good security team needs both. Without ITDR, IAM is a building full of cameras nobody watches; the recordings exist, but a person would have to review millions of events a day to find the one that matters. That’s exactly what happened to David’s fintech.

MITRE ATT&CK: thinking like an attacker

If the CSF is the defender’s language, MITRE ATT&CK is the attacker’s. ATT&CK, Adversarial Tactics, Techniques and Common Knowledge, is a huge catalog maintained by the MITRE Corporation since 2013 that documents tactics, the goals an attacker pursues, and techniques, the specific methods they use to reach them.

It matters for IAM because it lets you look at your program from the other side of the table. Instead of asking “do we have MFA?”, you ask “how would a real attacker get around our MFA, based on documented cases?”. That moves your thinking from a static defense to one built on scenarios.

ATT&CK groups attacker behavior into 14 tactics. Seen through identity, the journey usually runs like this: get in, look around, get more keys, move around, stay hidden, and finally take or break something. Real incidents are never this tidy, but the stages make a useful map.

Fullscreen

Every technique has a standard identifier, a T-number, and you’ll see these codes constantly in threat intelligence reports. There’s no need to memorize them; treat the table as a glossary to come back to.

Read any incident report and you’ll find T1078, T1098 and T1110 in almost all of them. That’s no coincidence: they’re the foundation of modern attacks, and if your IAM program has no explicit defense against those three, that’s your first priority.

There’s a popular line in the industry: “attackers don’t hack anymore, they log in.” The reasoning is simple. Exploiting a technical flaw, a buffer overflow or an SQL injection, means finding the bug, writing the exploit and hoping the victim hasn’t patched. A valid credential opens the door without setting off any alarm, because to the system someone holding the right credential is legitimate by definition. That’s why the criminal economy turned towards credentials. There’s a mature black market where “initial access brokers” sell working credentials for specific companies, from ten dollars to several thousand depending on the target, and ransomware groups increasingly skip the vulnerability hunting and buy access ready-made.

Go back to David’s Monday with these names in hand. The fake HR email was T1566, Phishing. Signing in as David and pushing notifications until he gave in was T1078, Valid Accounts, helped along by MFA bombing, which is psychological pressure more than technology. Reading his email for useful threads was discovery, the “look around” stop. And getting into the treasury system with a service account nobody had touched in four years was T1078 again, this time through a badly managed non-human identity. With ITDR watching Entra ID, alerts would have fired at four points at least: the sign-in from another country, the burst of push notifications, David’s unusual behavior reading a whole mailbox in an hour, and a service account used outside its normal pattern. The difference between “we caught it in five minutes” and “we caught it after the data was gone” is whether anyone was looking through the right lens.

The reports behind the conversation

To keep conversations about IAM grounded in data rather than opinion, two annual reports are worth reading every year, at least their executive summaries.

The Verizon DBIR, the Data Breach Investigations Report, has come out every spring since 2008 and is the broadest study of data breaches there is. The 2024 edition analyzed more than 30,000 incidents and nearly 11,000 confirmed breaches contributed by 94 organizations around the world, including national CSIRTs and security vendors. Its recent findings are consistent. The human element is present in 68% of breaches, not always malicious; it can be a misconfiguration, a phishing email that worked or plain carelessness. Stolen credentials are the most common way into web applications, along a familiar chain: phishing, a stolen credential, access to a SaaS application, data taken out. Ransomware never goes away, but it’s increasingly paired with extortion, encrypting the data and threatening to publish it as well. And the time to detect an intrusion is still measured in weeks, not minutes, which gives an attacker plenty of room. If you only read one part each year, read the executive summary and the chapter on web application attacks, where most of the identity material sits. It’s free and doesn’t ask for much to download.

Mandiant’s M-Trends complements it. Where the DBIR is broad and statistical, M-Trends comes from forensics: Mandiant, part of Google Cloud since 2022, investigates incidents at large companies and each year publishes the trends it sees in its cases. Several are about identity. Dwell time, the number of days an attacker spends inside before being found, fell to around ten days in its best years and has since risen again, especially when the way in was a valid credential, because that’s harder to notice. Abuse of valid accounts, T1078, appears at some point in most of the cases it investigates. Attacks on identity infrastructure itself, identity providers, federated directories and single sign-on flows, are a category of their own, where SolarWinds’ Golden SAML and the Okta breach belong. And MFA bypass keeps growing, through push fatigue like David’s, adversary-in-the-middle phishing kits such as Evilginx, and stolen session tokens.

The DBIR gives you breadth, the whole picture; M-Trends gives you depth, what real investigations find. A good habit is to look up a big breach you read about in the news in the following year’s M-Trends, where you’ll see the pattern laid out. And when a CISO needs to justify spending on MFA, putting the DBIR’s “68% of breaches involve a human element” in front of the committee usually persuades better than any slide.

Okta, seen through all three lenses

In January 2022, the Lapsus$ group compromised a company that provided outsourced technical support to Okta. From a support engineer’s account, the attackers reached an internal admin console that could potentially see customer tenants. A fast response limited the final reach, but the incident shook the industry, because it showed that identity infrastructure can be the target itself.

Through ATT&CK, the attackers took five steps you’ll now recognize: they phished the engineer (T1566), took his credential (T1078), used it to reach the internal console (T1078.004, valid cloud accounts), changed the sign-in flow to reset a victim’s MFA (T1556) and manipulated accounts to extend their reach into customer tenants (T1098). An organization with explicit alerts for T1078.004 and T1556 would have had a chance to catch it sooner.

Through the CSF, every function had a weak point. Under Identify, the risk of outsourcing administrative access hadn’t been mapped; a threat model that included suppliers would have helped. Under Protect, administrative access wasn’t protected by phishing-resistant MFA, where passkeys or hardware keys for admins would have made a difference. Under Detect, abuse of the support account took too long to spot, which ITDR watching the console could have shortened. Under Respond, customers felt they were told too late, the kind of thing a rehearsed communication playbook prevents. And under Recover, every potentially affected tenant had to be reviewed, followed by a public post-mortem and structural changes.

Through the reports, the pattern of “get in through a supplier, abuse a valid account, widen access” appears in the 2022 and 2023 M-Trends as one of the most frequent in high-impact incidents, and the 2023 DBIR gave a section to supply-chain connections because of cases like this one. The lesson is structural: your identity security doesn’t stop at your own employees. It stops where the chain of organizations with administrative access to your infrastructure stops.

Recap

Three lenses are worth carrying into any conversation about identity-centric security. The NIST CSF gives you the organizational language: IAM mainly covers Identify, Protect and Detect, and ITDR covers Respond and Recover when the threat involves identity. MITRE ATT&CK gives you the attacker’s language, and T1078, T1110, T1098 and T1556 are the techniques most worth knowing because they turn up in almost every modern identity incident, David’s included. And the DBIR and M-Trends give you the data: a human element in 68% of breaches and credentials as the most exploited way in, not because the technology is weak but because the criminal economy reorganized itself around them. With those three, you can translate technical work, an MFA rollout or a governance project, into organizational impact for a CISO, an auditor or a customer, and that matters more than any certification.

Three questions to test yourself

1. You’re asked to redesign the security program of a regional fintech. In under a minute, how would you describe the role of IAM across the six CSF functions to an executive committee with no technical background?
2. If you could only deploy defenses against three MITRE ATT&CK techniques in the next 90 days, which would you choose and why? Back it up with DBIR data if you can.
3. Your identity provider starts seeing MFA bombing against several privileged users. Which CSF function is failing, which ATT&CK technique are the attackers using, and which ITDR capability would help most in responding?