Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If a session token was exposed, is a password reset enough?

3 decision pointsThe pack behind this answer: Security Incident Management

Add to board memo

The short answer

Recommendation
No. Revoke every session on the account first, so every device is signed out, including the attacker's. Then check the logs: if anyone else used the session, or you cannot tell, treat it as a compromised account and reset the password and the second factor.
Reasoning
A session token keeps a device signed in without asking for the password again, so whoever holds it can act as the user until the session ends. A password reset does not always end sessions that already exist; revoking them does. The logs then decide the rest. Where they show use by someone else, or do not cover the whole period, the response follows the pack's steps for a taken-over account.
Considerations
  • The pack's steps are written for a mailbox, and the pack offers them as a guide for other accounts. Tokens for applications and programming interfaces are outside the pack.
  • Isolating an account is the incident manager's decision and needs no approval. The executive incident lead is told at the next update.
  • One ordinary account stopped before harm is Severity 3 in the pack's matrix; an account with elevated rights is at least Severity 2. When in doubt, choose the higher level.
  • If personal data may have been read, sent or downloaded, treat it as yes until the audit log is checked, and bring in the Data Protection Officer.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
StartA session token has been exposedStepRevoke every session on the account nowStepExport the sign-in and audit logs for the exposureDecisionDid anyone else use the session, or can you not tell?StepTreat it as a compromised account and set severityStepReset password and second factor; remove what was addedStepLook for other accounts hit the same wayDecisionDoes the account have elevated rights?StepReset every credential the account could reachDecisionWas personal data read, sent or downloaded, or is it unknown?StepRun the personal data breach steps alongsideOutcomeReturn the account once the recovery criteria are metOutcomeRecord the check, and close the source of the exposure

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 13 steps.

  1. Start

    A session token has been exposed

    A session is the signed-in state a device keeps after a sign-in, so the user is not asked again. Whoever holds the token can act as that user until the session ends. It may have been exposed in a log, a support file, a browser capture or a phishing page. The pack does not list the ways tokens leak; the response below does not depend on how.

    In the pack

  2. Step

    Revoke every session on the account now

    Sign out every device signed in to the account, including the attacker's. This is the step that ends a stolen session; a password reset alone may not. Record which sessions and devices were signed in, and from where, before revoking them. Isolating an account is the incident manager's decision and needs no approval; the executive incident lead is told at the next update.

    In the pack

  3. Step

    Export the sign-in and audit logs for the exposure

    Export them for the whole period since the token could first have been used, before retention runs out. They show whether the session was used from an unfamiliar place or device, and what was read, sent, downloaded or changed while it was.

    In the pack

  4. Decision

    Did anyone else use the session, or can you not tell?

    Signs include a sign-in from another country or an unfamiliar device, a rule or forwarding nobody set up, a new second-factor method, or a connected application the user does not recognise. If the logs do not cover the whole period, you cannot tell, and the answer is yes.

    In the pack

  5. Step

    Treat it as a compromised account and set severity

    Account compromise is its own incident category, run under the incident plan's general response. The pack's mailbox steps are written for a mailbox, and the pack offers them as a guide for any other account. In the pack's severity matrix, one user account compromised and stopped before harm is Severity 3; one account with elevated rights, contained, is Severity 2. When in doubt, choose the higher level.

    In the pack

    See also

  6. Step

    Reset password and second factor; remove what was added

    Reset the password, remove every registered second-factor method and register a new one with the user in person or by video, not by email. Remove rules, forwarding, delegates and applications the user did not set up, exporting or photographing them first. For a mailbox, the pack's default is within 30 minutes of declaration, together with the revocation; for other accounts the mailbox steps are a guide.

    In the pack

  7. Step

    Look for other accounts hit the same way

    Search for sign-ins from the same places or devices, the same rule names, and the same phishing email in other inboxes. Repeat the revocation, reset and log checks for each account found. Several accounts at once can raise the severity.

    In the pack

  8. Decision

    Does the account have elevated rights?

    The pack's examples, written for mailboxes, are an administrator, a payment approver, an executive or a shared finance mailbox. The plan assumes the attacker had more than you have found, so the reach of the account matters as much as what the logs show.

    In the pack

  9. Step

    Reset every credential the account could reach

    Check the audit log for administrator actions, payment approvals and changes to other accounts, and reset every credential the account could reach. Look for new accounts, scheduled tasks and remote access tools as well. The incident is at least Severity 2.

    In the pack

  10. Decision

    Was personal data read, sent or downloaded, or is it unknown?

    For any compromised account, the pack's matrix asks whether the audit log shows personal data read or sent. Treat it as yes until the audit log has been checked for the whole period the session could have been used. The Data Protection Officer decides with the incident manager.

    In the pack

  11. Step

    Run the personal data breach steps alongside

    Bring in the Data Protection Officer and run the personal data breach playbook alongside this response. The GDPR clock runs from awareness, and every personal data breach is recorded, notified or not.

    In the pack

  12. Outcome

    Return the account once the recovery criteria are met

    Before the account goes back into use: the way the token was taken is known and closed, sessions revoked, password reset, second factor registered again with a phishing-resistant method where possible, and nothing unexpected remains. The user confirms it works. Sign-in alerts then run for the monitoring period.

    In the pack

  13. Outcome

    Record the check, and close the source of the exposure

    With the session revoked and the logs showing no use by anyone else, the incident manager decides whether this is a near miss to log or a low-severity incident with response work left. Keep the log check as evidence of the decision. Then fix whatever exposed the token, such as a log or file that captured it; the pack does not cover that fix.

    In the pack

    See also

    • How do we stop support files becoming an access risk before we share them with a vendor?

Practical checklist

  1. Record which sessions and devices are signed in, and from where, then revoke every session on the account.
  2. Export the sign-in and audit logs for the whole period since the token could first have been used.
  3. Decide whether anyone else used the session. If the logs do not cover the whole period, treat it as yes.
  4. Reset the password and every second-factor method, registering the new one with the user in person or by video.
  5. Remove rules, forwarding, delegates and applications the user did not set up, exporting or photographing them first.
  6. Search for other accounts hit the same way, and repeat the steps for each.
  7. Reset every credential the account could reach if it has elevated rights.
  8. Close whatever exposed the token before the account goes back into use.

Evidence to have ready

  • The sessions and devices signed in before revocation, and the exported sign-in and audit logs.
  • The decision to close, log a near miss or declare an incident, with the log check that supports it.
  • Exports or photographs of every rule, forwarding, delegate and application removed, with who collected them and when.
  • The audit-log evidence on personal data, so a decision that there was no breach can be shown later.
  • Confirmation of each recovery criterion before the account went back into use.

Assumptions

  • The token belongs to a user's sign-in to email, office software or a similar service with a sign-in log.
  • The steps are the mailbox steps and defaults of the CISO Times incident management pack, which it also offers as a guide for other accounts. Tokens for applications and programming interfaces are not covered by the pack and are treated generally here.

Not covered here