Reviewing identity security posture

Configuration drifts

A few months after Cedar Inc. recovered from an account takeover, Quinn, who led the investigation for Cedar's security team, compares Cedar's identity settings with the decisions made at the time. Most still hold. Some do not. A finance contractor who could not use a passkey was given an exception "for two weeks", and it is still there. An administrator role granted to help with the cleanup was never removed. A scanner in the mail room needed an older mail protocol, so that protocol was switched back on for everyone. An app approved for a short trial still holds permission to read mail.

Nobody made a reckless decision. Each change solved a real problem on the day it was made. Together they moved Cedar away from the configuration it intended. That gradual divergence is configuration drift, and in a working organization it is normal: people join and leave, apps come and go, and every urgent request leaves a small change behind. An organization's security posture is the state of all those settings at a given moment, and a posture review compares that state with what was intended, looking for gaps an attacker could use.

A posture review is related to an access review, but it asks different questions. Whether each person still needs each of their permissions is the work of Access reviews in Identity governance. A posture review looks at the protections around that access: how people sign in, which fallbacks exist, how long sessions and tokens last, which apps hold grants, and whether anyone would notice an attack.

What to check

The checks follow the paths attackers use. Each one asks a question about the configuration that an attack would otherwise answer the hard way. Can this account be reached with evidence a relay can pass along? Does a fallback undo a strong method? Is there access that nobody uses, but that anyone who stole it could? The table lists checks that apply to most identity systems.

Read the answers from the systems themselves wherever possible: the directory, the authentication policy, the list of app grants, the sign-in records. A spreadsheet of what someone believes is configured is a statement of intent, which is exactly what the review is meant to compare against. The records also show what a policy cannot. A policy might require passkeys while the sign-in records show finance staff signing in with codes every day, because a fallback is still allowed. Checking every path to the account catches gaps that reading the settings misses.

Reading the results

The first review of a real system usually produces a long list, and treating every item as urgent means the important ones wait behind the easy ones. Three questions help sort it. What could an attacker do with this finding: reach one ordinary mailbox, or change settings for everyone? How reachable is it: open to the internet with only a password, or usable only from inside one building? And does another layer already cover it, such as an alert that would fire within minutes?

Totals can hide the finding that matters. "Ninety-two percent of staff use passkeys" sounds like good news, until the remaining eight percent turns out to include most of the finance team and two administrators. Look at who is in the gap, not only at its size. Signs of current interest raise a finding's priority too. An older protocol that logged thousands of failed sign-ins last week is not a theoretical risk; someone is trying it now.

Some findings are not what they seem. An account flagged as dormant may be a shared mailbox that nobody signs in to by design, or an integration that works through tokens and never signs in, as Orphaned, dormant, and shared accounts describes. An account flagged as having no MFA may be an automated service that signs its requests with a key instead of a password. Confirm before acting, and record the conclusion so the next review does not raise it again. When a real risk is accepted for now, write down who accepted it, why, and when it will be looked at again, as Threat modeling an identity system describes.

The findings below come from a fictional review at Cedar. Decide which one to fix first in each case.

Finding A  Administrator account it-admin-07 signs in with a password
           and a text-message code. No passkey is enrolled.
Finding B  Staff sessions last 12 hours. The written standard says 10.

Finding A  Client secret for the internal reporting app is 15 months old.
           Kept in the secrets store. Read-only access to a test dataset.
Finding B  App "Quick Notes" holds read and send mail access for 300 staff.
           Unverified publisher. Last used 5 months ago.

Finding A  The emergency access account has never been tested.
Finding B  An older mail protocol that accepts only a password is enabled
           for all staff. Last week it logged 2,300 failed sign-ins from
           addresses in 192.0.2.0/24.
Finding C  Sign-in records are kept for 60 days. The written standard says 90.

Finding A  200 warehouse staff sign in to the shift schedule with a
           password only. The schedule holds shift times and is
           reachable only from the warehouse network.
Finding B  Six finance staff are exempt from the passkey rule and use
           authenticator-app codes. Reason: "until new laptops arrive".
           Created 4 months ago. The laptops arrived 2 months ago.
           No end date.

Fixing what you find

Every finding that will be fixed needs an owner and a date. Without both, the next review finds the same list.

Fixes can break things, because many findings exist for a reason someone once had. Turning off the older mail protocol stops the scanner in the mail room. Requiring passkeys for the finance team blocks their work if they have nothing to enroll. Start by finding out who still uses what you are about to change, which the sign-in records usually show. Give those people a replacement, announce a date, and then make the change. Some policy systems can run a new rule in a report-only mode first, recording what it would have blocked without blocking anything, so the effect is visible before anyone is locked out. Authentication policy and SSO describes the same care for introducing a new rule.

Fix the cause as well as the instance. Removing forty dormant accounts helps once. If accounts keep going dormant because nobody tells the identity team when people leave, the leaver process needs repair, the work of Leaving an organization. If exceptions keep outliving their reasons, make an end date part of every exception, so that it lapses unless someone renews it.

Then check that the fix worked. Running the check again should show the finding gone. Better still, try the path the finding described and watch it fail: with a test account, try signing in over the older protocol and confirm that the attempt is refused. Testing identity defenses looks at that kind of testing in more detail.

Making review routine

A posture review done once is a snapshot that starts going out of date the next day. Some checks are worth running all the time, because the change they look for is a sign of attack as often as a sign of routine work: a new administrator, an app granted mail access, a new rule forwarding mail outside the organization, a newly trusted identity provider. These work best as alerts that reach someone the same day. After its incident, Cedar added alerts for several of them, because each matched a step the attacker had taken.

Other checks suit a schedule. Lifetimes and exceptions can be reviewed every quarter, secrets and keys flagged as they reach a set age, and emergency access tested on a fixed date. Some events call for a review out of turn: an incident, a merger, a new identity provider, or a large change to how people sign in.

Keep the intended configuration written down, ideally in a form that tools can compare against automatically, so that what was intended is not a matter of memory. Track findings over time as well as one by one, so the next review can tell a new gap from an old one that was never fixed.

The review deserves a review of its own. After any incident, ask whether the last posture review would have flagged the gap the attacker used, and add the check if it would not. A review reads settings and records, so it cannot show that a control actually refuses the request it is meant to refuse. That takes testing: sending the request the control should refuse, and watching it fail.