289 lines
7.1 KiB
Markdown
289 lines
7.1 KiB
Markdown
# Incident Response Plan
|
|
|
|
**Version:** 1.0
|
|
**Effective:** February 2026
|
|
**Owner:** Johan Jongsma
|
|
**Review:** Annually
|
|
|
|
---
|
|
|
|
## 1. Purpose
|
|
|
|
Define procedures for detecting, responding to, and recovering from security incidents affecting Dealspace systems or deal data.
|
|
|
|
---
|
|
|
|
## 2. Scope
|
|
|
|
All Dealspace systems:
|
|
- Production (muskepo.com / 82.24.174.112)
|
|
- Deal data (financial documents, transaction details, participant information)
|
|
|
|
---
|
|
|
|
## 3. Incident Classification
|
|
|
|
| Severity | Definition | Response Time | Examples |
|
|
|----------|------------|---------------|----------|
|
|
| **Critical** | Active breach, data exfiltration, system compromise | Immediate (< 1 hour) | Unauthorized deal 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 |
|
|
| **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@muskepo.com | Signal: +31 XXX |
|
|
|
|
### External Contacts
|
|
|
|
| Service | Contact |
|
|
|---------|---------|
|
|
| Legal Counsel | To be established |
|
|
| Cyber Insurance | To be established |
|
|
| Law Enforcement | Local police non-emergency |
|
|
|
|
### Notification Addresses
|
|
|
|
| Purpose | Address |
|
|
|---------|---------|
|
|
| Security incidents | security@muskepo.com |
|
|
| Client support | support@muskepo.com |
|
|
|
|
---
|
|
|
|
## 5. Detection
|
|
|
|
### Automated Detection
|
|
|
|
- **Rate limiting:** Flags excessive requests
|
|
- **Access logging:** All data access logged
|
|
- **Anomaly detection:** Unusual access patterns flagged
|
|
- **Authentication monitoring:** Failed login tracking
|
|
|
|
### Manual Detection
|
|
|
|
- Client reports of unauthorized access
|
|
- Unexpected system behavior
|
|
- External notification (security researcher, vendor)
|
|
|
|
### 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
|
|
|
|
---
|
|
|
|
## 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/deal data potentially affected
|
|
|
|
### Phase 2: Containment (30 min - 2 hours)
|
|
|
|
**Immediate containment:**
|
|
|
|
```bash
|
|
# Block suspicious IP
|
|
sudo ufw deny from <IP>
|
|
|
|
# If compromise confirmed, consider service isolation
|
|
ssh root@82.24.174.112 "systemctl stop dealspace"
|
|
|
|
# Preserve logs before any changes
|
|
ssh root@82.24.174.112 "cp -r /var/log /opt/dealspace/incident-$(date +%Y%m%d)/"
|
|
```
|
|
|
|
**Short-term containment:**
|
|
- Preserve evidence (copy logs before rotation)
|
|
- Identify scope (what deals/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 clients (if deal 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
|
|
- FADP: Swiss DPA notification as required
|
|
|
|
---
|
|
|
|
## 8. Evidence Preservation
|
|
|
|
**Preserve immediately:**
|
|
- System logs
|
|
- Database state (backup)
|
|
- 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 Deal Data Access
|
|
|
|
1. Identify which project(s) accessed
|
|
2. Check audit logs for access scope
|
|
3. Determine if data was exfiltrated
|
|
4. Notify affected clients 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
|
|
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 Hostkey 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: Client Notification Template
|
|
|
|
```
|
|
Subject: Security Notice from Dealspace
|
|
|
|
Dear [Client],
|
|
|
|
We are writing to inform you of a security incident that may have affected
|
|
data associated with your organization on the Dealspace platform.
|
|
|
|
WHAT HAPPENED
|
|
[Brief description of incident and date discovered]
|
|
|
|
WHAT INFORMATION WAS INVOLVED
|
|
[Types of data potentially affected - e.g., deal documents, participant info]
|
|
|
|
WHAT WE ARE DOING
|
|
[Steps taken to address the incident and prevent recurrence]
|
|
|
|
WHAT YOU CAN DO
|
|
[Recommended actions - e.g., notify deal participants, review access logs]
|
|
|
|
FOR MORE INFORMATION
|
|
Contact us at security@muskepo.com if you have questions.
|
|
|
|
We sincerely apologize for any concern this may cause.
|
|
|
|
Johan Jongsma
|
|
Founder, Dealspace
|
|
```
|
|
|
|
---
|
|
|
|
## 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, deals/clients if known]
|
|
|
|
ROOT CAUSE
|
|
[How it happened]
|
|
|
|
RESOLUTION
|
|
[How it was fixed]
|
|
|
|
LESSONS LEARNED
|
|
[Improvements identified]
|
|
|
|
REPORTED BY: [Name]
|
|
RESOLVED BY: [Name]
|
|
```
|
|
|
|
---
|
|
|
|
*Document end*
|