inou/docs/soc2/incident-response-plan.md

# Incident Response Plan

**Version:** 1.0
**Effective:** January 2026
**Owner:** Johan Jongsma
**Review:** Annually

---

## 1. Purpose

Define procedures for detecting, responding to, and recovering from security incidents affecting inou systems or user data.

---

## 2. Scope

All inou systems:
- Production (inou.com / 192.168.100.2)
- Staging (dev.inou.com / 192.168.1.253)
- User data (medical imaging, labs, genome, documents)

---

## 3. Incident Classification

| Severity | Definition | Response Time | Examples |
|----------|------------|---------------|----------|
| **Critical** | Active breach, data exfiltration, system compromise | Immediate (< 1 hour) | Unauthorized data access, ransomware, credential theft |
| **High** | Potential breach, service outage, vulnerability exploited | < 4 hours | Failed intrusion attempt, DDoS, authentication bypass |
| **Medium** | Suspicious activity, policy violation | < 24 hours | Unusual access patterns, failed login spikes, tarpit triggers |
| **Low** | Minor issue, no data at risk | < 72 hours | Reconnaissance scans, policy clarification needed |

---

## 4. Contact Information

### Primary Contact

| Role | Name | Email | Phone |
|------|------|-------|-------|
| Incident Commander | Johan Jongsma | security@inou.com | Signal: +1 727-225-2475 |
| AI Operations | James ⚡ | Via OpenClaw | 24/7 automated |

### External Contacts

| Service | Contact |
|---------|---------|
| Legal Counsel | To be established |
| Cyber Insurance | Not currently in place |
| Law Enforcement | Local police non-emergency |

### Notification Addresses

| Purpose | Address |
|---------|---------|
| Security incidents | security@inou.com |
| User support | support@inou.com |

### Alert Flow

```
Uptime Kuma (Zurich) → Webhook → OpenClaw Gateway → James AI → Signal (Johan)
Nuclei scan → James AI reviews → Signal alert (if critical/high)
```

---

## 5. Detection

### Automated Detection

- **Uptime Kuma (Zurich):** 24/7 availability monitoring, 60-second intervals
- **Nuclei scans:** Weekly + monthly vulnerability scanning from Zurich
- **404 monitoring:** Alerts on suspicious path probes
- **Tarpit triggers:** Logs known attack patterns (PHP probes, config access attempts)
- **Rate limiting:** Flags excessive requests per IP
- **Log analysis:** HTTP access logs reviewed for anomalies
- **James AI:** Receives alerts, triages, escalates critical issues

### Manual Detection

- User reports of unauthorized access
- Unexpected system behavior
- External notification (security researcher, vendor)
- James AI analysis of scan results

### Indicators of Compromise

- Unexpected admin access or privilege escalation
- Unusual database queries or data exports
- New or modified files outside deployment
- Outbound connections to unknown hosts
- Authentication anomalies (successful logins from impossible locations)

---

## 6. Response Procedures

### Phase 1: Identification (0-30 minutes)

1. **Acknowledge alert** - Confirm incident is real, not false positive
2. **Classify severity** - Use classification table above
3. **Document** - Start incident log with timestamp, initial observations
4. **Assess scope** - What systems/data potentially affected

### Phase 2: Containment (30 min - 2 hours)

**Immediate containment:**

```bash
# Block suspicious IP
sudo ufw deny from <IP>

# If compromise confirmed, isolate server
# Production: Consider taking offline

# Preserve logs before any changes
cp /tank/inou/*.log /tank/inou/incident-$(date +%Y%m%d)/
```

**Short-term containment:**
- Preserve evidence (copy logs before rotation)
- Identify scope (what systems/data affected)
- Prevent lateral movement

### Phase 3: Eradication (2-24 hours)

1. **Identify root cause** - How did attacker get in?
2. **Remove threat** - Malware, backdoors, unauthorized accounts
3. **Patch vulnerability** - Fix the entry point
4. **Verify clean** - Confirm no persistence mechanisms

### Phase 4: Recovery (24-72 hours)

1. **Restore from backup** if needed (see [Disaster Recovery Plan](disaster-recovery-plan.md))
2. **Verify integrity** - Check data hasn't been modified
3. **Monitor closely** - Watch for re-compromise
4. **Gradual restoration** - Bring services back incrementally

### Phase 5: Lessons Learned (1-2 weeks post-incident)

1. **Post-mortem** - What happened, timeline, decisions made
2. **Update documentation** - Improve detection/response
3. **Implement improvements** - Technical and procedural changes
4. **Final report** - Document for compliance records

---

## 7. Communication

### Internal Communication

- Document all decisions with timestamps
- Keep incident log updated
- Use secure communication channels

### External Communication

**To affected users (if data breach confirmed):**
- Notify within 72 hours (GDPR requirement)
- Include: What happened, what data affected, what we're doing, what they should do
- Template in Appendix A

**To regulators (if required):**
- GDPR: Supervisory authority within 72 hours
- HIPAA: HHS within 60 days (if >500 individuals affected)

---

## 8. Evidence Preservation

**Preserve immediately:**
- System logs (`/var/log/`, application logs)
- Database state (ZFS snapshot)
- Network traffic captures (if available)
- Screenshots of anomalies

**Chain of custody:**
- Document who accessed evidence and when
- Store copies in secure, separate location
- Hash files to prove integrity: `sha256sum <file>`

---

## 9. Specific Scenarios

### Scenario: Unauthorized Data Access

1. Identify which dossier(s) accessed
2. Check audit logs for access scope
3. Determine if data was exfiltrated
4. Notify affected users within 72 hours
5. Document for compliance

### Scenario: Ransomware

1. **Immediately isolate** affected systems (network disconnect)
2. Do NOT pay ransom
3. Assess backup integrity (ZFS snapshots + off-site)
4. Restore from clean backup
5. Report to law enforcement

### Scenario: DDoS Attack

1. Enable additional rate limiting
2. Block attacking IP ranges via UFW
3. Contact ISP if upstream filtering needed
4. Document attack characteristics

### Scenario: Vulnerability Disclosure

1. Acknowledge receipt to researcher within 24 hours
2. Validate the vulnerability
3. Develop and test fix
4. Deploy fix
5. Thank researcher, coordinate disclosure timing

---

## 10. Recovery Time Objectives

| Scenario | RTO | RPO |
|----------|-----|-----|
| Hardware failure | 4 hours | 24 hours |
| Data corruption | 2 hours | 24 hours |
| Security breach | 24 hours | 0 (no data loss acceptable) |
| Complete site loss | 48 hours | 24 hours |

---

## Appendix A: User Notification Template

```
Subject: Security Notice from inou

Dear [Name],

We are writing to inform you of a security incident that may have affected
your data stored with inou.

WHAT HAPPENED
[Brief description of incident and date discovered]

WHAT INFORMATION WAS INVOLVED
[Types of data potentially affected]

WHAT WE ARE DOING
[Steps taken to address the incident and prevent recurrence]

WHAT YOU CAN DO
[Recommended actions for the user]

FOR MORE INFORMATION
Contact us at security@inou.com if you have questions.

We sincerely apologize for any concern this may cause.

Johan Jongsma
Founder, inou
```

---

## Appendix B: Incident Log Template

```
INCIDENT ID: INC-YYYY-MM-DD-001
SEVERITY: [Critical/High/Medium/Low]
STATUS: [Active/Contained/Resolved]

TIMELINE
- YYYY-MM-DD HH:MM - Initial detection
- YYYY-MM-DD HH:MM - [Action taken]
- YYYY-MM-DD HH:MM - [Action taken]

DESCRIPTION
[What happened]

AFFECTED SYSTEMS
[List systems]

AFFECTED DATA
[Description of data, number of users if known]

ROOT CAUSE
[How it happened]

RESOLUTION
[How it was fixed]

LESSONS LEARNED
[Improvements identified]

REPORTED BY: [Name]
RESOLVED BY: [Name]
```

---

*Document end*