Session security runbook
Use this runbook for lost devices, suspicious interactive sessions, or reports that an account may be compromised.
1. Identify the account
Confirm the exact Starfire account and the time window of concern.
2. Review active sessions/devices
Inspect available session metadata such as creation, last activity, client/device context, and current status.
Treat device/location metadata as operational evidence—not proof of which human performed an action.
3. Revoke the narrowest risky session
If one session is clearly associated with a lost/untrusted device, revoke it first.
If the risk cannot be isolated, broader session revocation can be appropriate when authorized.
4. Apply security hold when needed
For unresolved high-risk situations, use the security-specific account state/restriction model rather than a generic billing or organization action.
5. Review authentication events
Correlate suspicious activity with verification, password-reset, sign-in, OAuth, or other security events where available.
6. Review developer credentials separately
Interactive session revocation does not automatically revoke:
- API keys
- service-account credentials
- webhook secrets
- external integration tokens
Review/revoke programmatic access when the compromise may affect those credentials.
7. Review organization impact
If the account is an organization owner/admin, inspect high-impact changes during the incident window: membership, developer resources, billing, project access, or policy.
8. Recover
After the user secures authentication and risky credentials are revoked, remove temporary security holds/restrictions only after verifying the intended account state.
9. Preserve audit evidence
Record administrative revocations and state changes through supported audit mechanisms. Do not copy active secrets into incident or audit notes.
Use concrete events and resource IDs. An unfamiliar session is a reason to investigate; it is not automatically proof of malicious behavior.
