Reviewing Sessions in Practice

Session recording is deployed on the premise that recordings will be reviewed. In practice almost nobody reviews them, and the control quietly becomes storage.

Why universal review fails

Volume. A mid-sized estate produces more session hours per day than any team can watch.

Video is not searchable without processing.

Most sessions are routine, so the reviewer learns nothing and stops.

No defined trigger, so review never becomes anyone's scheduled work.

No findings, which confirms that reviewing is pointless, which produces fewer reviews.

The model that works

Three layers, of which only the first is continuous.

Automated alerting on defined patterns, which handles volume.

Triggered review on specific events, which handles the cases that matter.

Sampling, small and regular, which validates the other two and catches what they miss.

Alerting on commands

Where command capture exists, this is the highest-value layer.

Commands that touch audit configuration or logging.

Commands that create or modify accounts and group membership.

Commands that disable security tooling.

Bulk data access or export.

Access to systems outside the person's normal pattern.

Sessions at unusual hours from unusual sources.

Start with a short list. A long one produces alert fatigue and the same silence as no alerting.

Triggered review

Any use of a break-glass account.

Any emergency or self-authorised elevation.

Any third-party session at high tier.

Any session flagged by alerting.

Any session by someone under investigation for other reasons, with the authorisation that requires.

After any incident, for the relevant window.

These are the reviews that find things, and the volume is manageable.

Sampling

A small number per period, chosen randomly and weighted toward higher tiers.

Reviewed against the stated reason for the session, which requires the reason to have been recorded.

By someone independent of the team being sampled.

Findings recorded, including none.

The deterrent value comes from the sampling being real and known to exist, which requires it to actually happen on schedule.

What a review looks for

Did the session match its stated purpose.

Was anything done outside the scope of the request.

Were credentials for other systems used or exposed.

Was security tooling or logging altered.

Was data accessed beyond what the task required.

Not: whether the administrator was efficient, which is the performance-management line and crossing it destroys cooperation.

Reporting it

Sessions reviewed, by trigger type.

Findings, by category.

Time from session to review for triggered cases.

Alert volume and false positive rate, which tells you whether the rules need tuning.

A review programme that reports zero findings over a year either has an unusually well-behaved estate or is not reviewing, and the second is more likely.

Tuning the alert list

A long rule set produces fatigue and the same silence as no alerting.

Start with six rules, not sixty.

Measure the fire rate for a month.

Anything firing daily is either a real problem or a bad rule, and it is almost always a bad rule.

Anything never firing is either well-controlled or misconfigured; test it deliberately.

Track the finding rate per rule, and remove rules that have never produced a finding after a year.

Add rules from incidents, which is where the useful ones come from.

Who reviews

The reviewer's independence determines whether the review means anything.

Not the team being reviewed, which is the arrangement most deployments default to.

Someone with enough context to judge, which excludes a purely administrative function.

A named person with allocated time, because a review that is everyone's job is nobody's.

Rotating, for sampling, which spreads the context and reduces the tedium.

With a route to escalate a finding without accusing anyone, since most findings turn out to be process problems rather than misconduct.