27Core

Incident Response

Incident Response — Instruction 27

Purpose

When a security incident is detected (or /security-incident is called), execute this playbook immediately and generate an incident report.

Trigger Conditions

Auto-trigger when ANY of these are detected:

  • Active secret/API key found in code or git history
  • Database rules set to allow all
  • Confirmed data breach indicators
  • Honeypot credentials accessed
  • User explicitly calls /security-incident

Immediate Response (First 15 Minutes)

Step 1 — Assess Severity

CRITICAL (act NOW):
- Secret confirmed exposed in public code/git history
- Database fully public (allow all)
- Production credentials in public repo

HIGH:
- Secret in private code (may be accessed by team)
- Vulnerability confirmed exploitable

MEDIUM:
- Potential exposure, not confirmed
- Vulnerability not yet exploitable

Step 2 — Contain

If API Key / Secret Exposed:

1. IMMEDIATELY go to provider dashboard and REVOKE the key
   - Stripe: dashboard.stripe.com → API Keys → Roll
   - OpenAI: platform.openai.com → API Keys → Delete
   - AWS: IAM → Access Keys → Deactivate/Delete
   - GitHub: Settings → Personal Access Tokens → Delete
   - Firebase: Console → Project Settings → Regenerate
   - Supabase: Settings → API → Regenerate anon/service role key
   - Twilio: Console → Account Info → Auth Token → Rotate
   - SendGrid: Settings → API Keys → Delete
   - Vercel: Project Settings → Environment Variables → Update
   - Cloudflare: Profile → API Tokens → Delete

2. Generate new credentials BEFORE removing old ones
3. Update all environments (production, staging, dev)
4. Update CI/CD secrets

TIMING: Revoke FIRST, fix code SECOND

If Database Publicly Accessible:

Firebase/Firestore:
1. Console → Firestore → Rules → Immediately change to:
   rules_version = '2';
   service cloud.firestore {
     match /databases/{database}/documents {
       match /{document=**} {
         allow read, write: if false;  // DENY ALL immediately
       }
     }
   }
2. Monitor access logs for evidence of data access
3. Implement proper rules (see instruction 07)

Supabase:
1. Enable RLS on all tables immediately via SQL Editor:
   ALTER TABLE [tablename] ENABLE ROW LEVEL SECURITY;
2. Check logs in Supabase Dashboard → Logs → API logs

Step 3 — Assess What Was Exposed

For git history exposure:
git log --all --full-diff -p | grep -E "sk_live|AKIA|eyJ|password" | head -50

Check:
- When was the secret first committed?
- Who has access to the repository?
- Is the repo public or private?
- Has anyone forked the repo?
- Check: https://github.com/search?q=[partial-key]

Step 4 — Clean git History (if public repo)

# WARNING: Requires user to run manually — disruptive operation
# Inform all collaborators BEFORE doing this

# Option 1: git-filter-repo (recommended)
pip install git-filter-repo
git filter-repo --invert-paths --path .env
git filter-repo --replace-text <(echo "OLD_SECRET==>REMOVED")
git push --force --all origin
git push --force --tags origin

# Option 2: BFG Repo Cleaner
java -jar bfg.jar --delete-files .env
git push --force --all

# After cleaning: all collaborators must re-clone the repository

Incident Report Generation

Generate incident-report.md with:

# 🚨 Security Incident Report

**Date:** [ISO timestamp]
**Severity:** [CRITICAL/HIGH/MEDIUM/LOW]
**Incident ID:** [generated UUID]
**Status:** [ACTIVE/CONTAINED/RESOLVED]

## What Happened
[Clear description of the incident]

## Immediate Actions Required
- [ ] [Action 1] — ETA: NOW
- [ ] [Action 2] — ETA: [timeframe]

## Affected Systems/Data
- [List of potentially affected systems]
- [Estimated data exposure]

## Timeline
| Time | Event |
|------|-------|
| [T+0] | Incident detected |
| [T+?] | [Action taken] |

## Credentials to Rotate Immediately
| Service | Action | Done? |
|---------|--------|-------|
| [Service] | Rotate key | ☐ |

## Evidence
[Technical evidence found]

## Prevention
[How to prevent this in the future]

## Communication
If breach involves user data → GDPR requires notification within 72 hours to:
- Data Protection Authority (in EU)
- Affected users (if high risk)

## Next Steps
1. [ ] Rotate all affected credentials
2. [ ] Fix root cause in code
3. [ ] Run full security audit after fix
4. [ ] Update security processes
5. [ ] Consider external pen test

---
*Generated by security-skill v1.0.0*
*This report is confidential*

Post-Incident Actions

After containment:

  1. Run /security-audit on full codebase
  2. Update memory-security.md with incident record
  3. Implement monitoring to detect similar issues
  4. Review how the secret ended up in code (process failure)
  5. Update .gitignore if needed
  6. Add pre-commit hook to prevent recurrence
  7. Consider using a secret manager (AWS Secrets Manager, HashiCorp Vault)

Monitoring After Incident

Track for evidence of exploitation:

- Check Stripe dashboard for unauthorized API calls (time window)
- Check AWS CloudTrail for unauthorized actions
- Check Firebase/Supabase access logs
- Check email service for unauthorized sends
- Check for unauthorized Vercel deployments
- Monitor bank/payment accounts for unauthorized transactions