johan
/
inou
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
inou/docs/soc2/incident-response-plan.md

7.6 KiB
Raw Blame History

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:

# 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)
  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