Testing That the Controls Hold

Most PAM gaps are not discovered by monitoring. They are discovered by someone deliberately looking, or by an incident.

The coverage test

Pick a system. Enumerate every path to administrative access on it.

Through the broker, which you expect.

Through a named account with standing rights.

Through a service account.

Through group membership granting it indirectly.

Through backup, restore, or the hypervisor beneath it.

Through the cloud console if it is hosted there.

Count how many are controlled. Run this on ten systems across tiers. The result is your real coverage, as opposed to the onboarding percentage.

The bypass test

Attempt to reach a management interface without going through the broker, from a normal workstation.

Attempt to authenticate to a target with a vaulted credential directly.

Attempt to use a standing account that should have been removed.

Do this openly, with the platform team, as a design verification rather than as a red team exercise.

Every success is a finding and usually a network or logon restriction that was never applied.

The recording verification

Establish a known session, do known things, and retrieve the recording.

Check it captured what you expect, at the fidelity you believe is configured.

Check the retention by retrieving something near the end of the window.

Check that recording failure alerts by inducing one in a test environment.

Silent recording failure is common and is only found by looking.

The rotation drill

Rotate a tier one service account under time pressure.

Measure how long it took, what broke, and what was missed.

Annually, and after any significant change to the estate.

This is the drill that predicts incident recovery time, which is the number that matters most and is almost never known.

The break-glass drill

Retrieve a break-glass credential through the documented procedure.

Out of hours, with the usual approver unavailable, which is the realistic case.

Use it, confirm it works, rotate it afterwards.

Check the alert fired, to the right people.

Time each step.

The availability test

Fail over the broker and confirm administrators can still work.

Operate with the broker deliberately unavailable for a defined window, following the degraded-mode procedure.

Confirm the circular dependencies do not bite, which is the specific failure to look for.

Recording the results

What was tested, when, by whom, what was found, and what was done.

Findings tracked to closure, or the test was an observation.

Report the trend: gaps found per test cycle should fall, and a sudden rise usually means the estate changed rather than that the controls degraded.

An organisation that tests annually and closes what it finds is in a materially different position from one with the same products and no testing, and the difference is invisible from the deployment documentation.

Who runs the tests

Independence matters more than sophistication for this kind of testing.

Not the team that built the deployment, which knows where not to look.

Not necessarily a red team, since most of these are verification exercises rather than adversarial ones.

With the platform team present, so findings are understood rather than disputed.

With authorisation in writing, particularly for the bypass tests.

Findings tracked in the same system as other risks, not in a separate document that closes with the test report.

Turning findings into work

A test that produces observations rather than changes has cost time and achieved nothing.

Each finding gets an owner and a date.

Ranked by tier and by how many paths it opens, not by how easy it is to fix.

Retested at closure, rather than accepted on assertion.

Findings not closed within the period reported upward, which is what produces the resourcing.

The trend reported annually: findings per test cycle, and time to closure. Both should improve, and a sudden rise usually means the estate changed rather than that the controls degraded.