CyberOrigen Incident Response Runbook
Version: 1.0 Last Updated: December 22, 2025 Owner: Security Team
1. Overview
This runbook provides step-by-step procedures for responding to security incidents affecting CyberOrigen infrastructure and services.
Severity Levels
| Level | Description | Response Time | Escalation |
|---|---|---|---|
| P0 - Critical | Active breach, data exfiltration, system compromise | Immediate (< 15 min) | CEO, CTO, Legal |
| P1 - High | Attempted breach, brute force, service degradation | < 1 hour | CTO, Security Lead |
| P2 - Medium | Suspicious activity, policy violations | < 4 hours | Security Lead |
| P3 - Low | Minor anomalies, potential false positives | < 24 hours | On-call engineer |
2. Incident Response Team
Primary Contacts
| Role | Name | Contact |
|---|---|---|
| Security Lead | TBD | [email protected] |
| On-Call Engineer | Rotation | pages via PagerDuty |
| CTO | TBD | Direct |
| CEO | TBD | Direct (P0 only) |
Communication Channels
- Slack: #security-incidents (private channel)
- Email: [email protected]
- Phone: Emergency contact list (secured)
- War Room: Video call link (secured)
3. Incident Types & Response Procedures
3.1 Brute Force / Credential Stuffing Attack
Indicators:
- Security alert:
FAILED_LOGIN_SPIKEorBRUTE_FORCE_ATTEMPT - 10+ failed logins in 15 minutes
- 5+ failed logins from single IP in 10 minutes
Immediate Actions (< 15 min):
bash
# 1. Check current attack status
curl -X GET "https://backend.cyberorigen.com/admin/metrics/security?hours=1" \
-H "Authorization: Bearer $ADMIN_TOKEN"
# 2. Identify attacking IPs
# Check audit logs for failed login IPs
SELECT ip_address, COUNT(*) as count
FROM audit_logs
WHERE event_type = 'AUTH_LOGIN_FAILED'
AND timestamp > NOW() - INTERVAL '1 hour'
GROUP BY ip_address
ORDER BY count DESC;
# 3. Block attacking IPs at CDN level (Cloudflare)
# Via Cloudflare Dashboard > Security > WAF > Custom Rules
# Or via API:
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/firewall/rules" \
-H "Authorization: Bearer $CF_TOKEN" \
-d '{"filter": {"expression": "ip.src eq 1.2.3.4"}, "action": "block"}'Resolution Steps:
- Block attacking IPs at Cloudflare WAF
- Review targeted accounts for compromise
- Force password reset for targeted accounts if suspicious
- Enable enhanced rate limiting temporarily
- Document IPs and patterns for future blocking
- Create post-incident report
3.2 Suspected Account Compromise
Indicators:
- User reports unauthorized access
- Activity from unusual location/IP
- Unusual scan patterns or data access
Immediate Actions:
bash
# 1. Force logout user (invalidate sessions)
# Via database:
UPDATE users SET session_invalidated_at = NOW()
WHERE id = {user_id};
# 2. Disable account temporarily
UPDATE users SET is_active = false
WHERE id = {user_id};
# 3. Check recent activity
SELECT * FROM audit_logs
WHERE user_id = {user_id}
AND timestamp > NOW() - INTERVAL '24 hours'
ORDER BY timestamp DESC;Resolution Steps:
- Disable the compromised account
- Notify the user via verified alternate contact
- Investigate scope of unauthorized access
- Check for data exfiltration (report downloads, API calls)
- Reset credentials and re-enable with MFA required
- Review and revoke any API keys
- Document incident timeline
3.3 API Abuse / Rate Limit Spike
Indicators:
- Security alert:
RATE_LIMIT_SPIKE - 20+ rate limit violations in 5 minutes
- Unusual API traffic patterns
Immediate Actions:
bash
# 1. Check rate limit violations
curl -X GET "https://backend.cyberorigen.com/admin/metrics/security" \
-H "Authorization: Bearer $ADMIN_TOKEN"
# 2. Identify source IPs/accounts
SELECT ip_address, user_id, request_path, COUNT(*) as count
FROM audit_logs
WHERE event_type = 'RATE_LIMIT_EXCEEDED'
AND timestamp > NOW() - INTERVAL '1 hour'
GROUP BY ip_address, user_id, request_path
ORDER BY count DESC;
# 3. Block at WAF if abuse continues
# (Same as brute force IP blocking)Resolution Steps:
- Identify if legitimate traffic or abuse
- If abuse: block source IPs
- If legitimate: contact customer, adjust limits if appropriate
- Review for data scraping or DoS intent
- Consider implementing additional anti-bot measures
3.4 Suspected Data Breach
Indicators:
- Unauthorized data access in audit logs
- Customer reports data exposure
- External report of data leak
CRITICAL: Escalate immediately to P0
Immediate Actions:
- STOP - Do not delete logs or evidence
- ISOLATE - If ongoing, isolate affected systems
- PRESERVE - Take forensic snapshots
- NOTIFY - Security Lead, CTO, CEO, Legal
bash
# 1. Preserve current state (take DB snapshot)
# Railway: Use dashboard to create backup
# 2. Review data access logs
SELECT * FROM audit_logs
WHERE event_type IN ('DATA_EXPORT', 'REPORT_GENERATED', 'REPORT_DOWNLOADED')
AND timestamp > NOW() - INTERVAL '7 days'
ORDER BY timestamp DESC;
# 3. Check for unauthorized API access
SELECT * FROM audit_logs
WHERE event_category = 'security'
AND success = false
AND timestamp > NOW() - INTERVAL '7 days';Legal/Compliance Obligations:
- GDPR: 72-hour notification requirement for EU data
- SOC2: Document incident and remediation
- Customer notification: Per contractual obligations
3.5 Service Unavailability / DoS
Indicators:
- Monitoring alerts (Uptime Robot, etc.)
- Unable to access services
- High error rates in logs
Immediate Actions:
bash
# 1. Check Railway service status
# Via Railway dashboard or CLI
# 2. Check Cloudflare status
# Via Cloudflare dashboard
# 3. Enable "Under Attack" mode in Cloudflare
# Dashboard > Overview > Quick Actions > Under Attack Mode
# 4. Check application logs
railway logs -s backendResolution Steps:
- Enable Cloudflare "Under Attack" mode if DDoS
- Scale up Railway instances if capacity issue
- Identify root cause from logs
- Block attacking sources if applicable
- Document impact and resolution
4. Evidence Collection & Preservation
Required Evidence for All P0/P1 Incidents
- Audit logs - Export relevant timeframe
- Application logs - Railway log export
- Network logs - Cloudflare logs
- Database state - Snapshot at incident time
- Screenshots - Of dashboards, alerts
Evidence Collection Commands
bash
# Export audit logs for timeframe
curl -X GET "https://backend.cyberorigen.com/api/v1/audit/export?\
start=2025-01-01T00:00:00Z&end=2025-01-02T00:00:00Z" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-o audit_export.json
# Get Cloudflare security events
curl -X GET "https://api.cloudflare.com/client/v4/zones/{zone_id}/security/events?\
since=2025-01-01T00:00:00Z" \
-H "Authorization: Bearer $CF_TOKEN" \
-o cloudflare_events.json5. Post-Incident Procedures
Required for All Incidents
- Incident Report - Complete within 48 hours
- Root Cause Analysis - Within 1 week for P0/P1
- Remediation Actions - Document and track
- Team Debrief - Schedule for P0/P1
Incident Report Template
markdown
# Incident Report: [INCIDENT-YYYY-MM-DD-NNN]
## Summary
- **Date/Time:** YYYY-MM-DD HH:MM UTC
- **Duration:** X hours/minutes
- **Severity:** P0/P1/P2/P3
- **Type:** [Brute Force/Breach/DoS/etc.]
- **Impact:** [Customer impact description]
## Timeline
| Time (UTC) | Event |
|------------|-------|
| HH:MM | [Event description] |
## Root Cause
[Description of root cause]
## Resolution
[Steps taken to resolve]
## Remediation
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [Action item] | [Name] | [Date] | [Status] |
## Lessons Learned
- [Lesson 1]
- [Lesson 2]6. Key System Access
Railway (Backend)
- Dashboard: https://railway.app/project/xxx
- CLI:
railway logs -s backend - Deploy:
railway up
Cloudflare (CDN/WAF)
- Dashboard: https://dash.cloudflare.com
- Zone ID: [Stored in 1Password]
- API Token: [Stored in 1Password]
Database
- Provider: Railway PostgreSQL
- Connection: Via Railway CLI or dashboard
- Backups: Automatic daily, manual on-demand
Monitoring
- Security Metrics:
/admin/metrics/security - Security Alerts:
/admin/metrics/security/alerts - Audit Logs:
/api/v1/audit
7. Emergency Contacts
External Partners
| Service | Contact | Purpose |
|---|---|---|
| Railway Support | [email protected] | Infrastructure |
| Cloudflare Enterprise | Enterprise support portal | WAF/DDoS |
| Legal Counsel | TBD | Breach notification |
Regulatory Contacts
- ICO (UK): For GDPR breaches affecting UK residents
- DPA (EU): For GDPR breaches affecting EU residents
8. Runbook Maintenance
- Review Frequency: Quarterly
- Test Frequency: Annually (tabletop exercise)
- Owner: Security Lead
- Last Review: December 2025
- Next Review: March 2026
Appendix A: Quick Reference Commands
bash
# Check security status
curl -X GET "https://backend.cyberorigen.com/admin/metrics/security" \
-H "Authorization: Bearer $ADMIN_TOKEN"
# Trigger manual security check
curl -X POST "https://backend.cyberorigen.com/admin/metrics/security/check" \
-H "Authorization: Bearer $ADMIN_TOKEN"
# Get recent security alerts
curl -X GET "https://backend.cyberorigen.com/admin/metrics/security/alerts?hours=24" \
-H "Authorization: Bearer $ADMIN_TOKEN"
# View audit logs for user
curl -X GET "https://backend.cyberorigen.com/api/v1/audit?user_id=123&limit=100" \
-H "Authorization: Bearer $ADMIN_TOKEN"This document is confidential and for internal use only.