Incident Response Plan — Keystone Dataworks BizHub
Severity levels
| Level | Example | Response time |
|---|---|---|
| S1 Critical | Confirmed data breach, ransomware, public exposure of contracts | Immediate |
| S2 High | Suspected unauthorized login, IDOR exploit attempt | < 4 hours |
| S3 Medium | Failed login spike, dependency CVE | < 24 hours |
| S4 Low | Misconfiguration without exposure | Next business day |
Response phases
1. Detect
- Monitor nginx access logs,
audit_logtable, failed/loginand/mfaattempts. - Alerts: unusual download volume from
/uploadsor file routes.
2. Contain
- Stop service:
sudo systemctl stop keystonedataworks - Block public IP at firewall or nginx if attacker known.
- Rotate:
BIZHUB_SESSION_SECRET, DB password, demo password, MFA reset for affected users.
3. Eradicate
- Patch vulnerable code; review git diff for unauthorized changes.
- Restore from last known-good backup if integrity unknown.
4. Recover
- Restore Postgres +
uploads/from encrypted backup. - Re-run
01_tenancy.sqlif needed; verify RLS policies. - Smoke test owner MFA + demo isolation before re-opening nginx.
5. Notify
- Document timeline, data categories affected, users impacted.
- Notify affected clients and regulators per applicable law (consult counsel).
6. Post-incident review
- Root cause, corrective actions, update this document and runbook.
See INCIDENT_RESPONSE_RUNBOOK.md for VPS commands.
Template — review with legal counsel.