# Security Policy

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

---

## 1. Purpose

Establish security requirements for Dealspace systems, data, and operations.

---

## 2. Scope

- All Dealspace systems (production)
- All M&A deal data processed by Dealspace
- All administrative access

---

## 3. Roles and Responsibilities

| Role | Responsibilities |
|------|------------------|
| Owner (Johan Jongsma) | Security policy, incident response, system administration, compliance |

---

## 4. Access Control

### 4.1 Administrative Access

| System | Method | Requirements |
|--------|--------|--------------|
| Production server | SSH | Ed25519 key only |
| Database | Local only | No remote connections |
| Master key | Secure storage | Separate from data |

### 4.2 User Authentication

| Method | Specification |
|--------|---------------|
| Login | Email + verification or SSO |
| Session duration | 7 days (refresh token) |
| Access tokens | 1 hour expiry |
| MFA | Required for IB admin/member roles |

### 4.3 Principle of Least Privilege

- Users access only their assigned projects by default
- Explicit invitations required for project access
- RBAC enforced at data layer
- Role hierarchy: IB Admin > IB Member > Seller Admin > Seller Member > Buyer Admin > Buyer Member > Observer

---

## 5. Data Protection

### 5.1 Classification

| Level | Examples | Protection |
|-------|----------|------------|
| Tier 1 - Critical | Deal terms, valuations, financials | Encrypted, per-project keys |
| Tier 2 - Confidential | Participant identities, timelines | Encrypted at rest and transit |
| Tier 3 - Internal | Metadata, session logs | Access restricted |

### 5.2 Encryption Standards

| Layer | Standard |
|-------|----------|
| Key Derivation | HKDF-SHA256 |
| Database fields | AES-256-GCM |
| Search indexes | Blind indexes (HMAC-SHA256) |
| Transit | TLS 1.3 |
| Compliance | FIPS 140-3 (BoringCrypto) |

### 5.3 Key Management

| Key | Storage | Backup |
|-----|---------|--------|
| Master key | Secure file (chmod 600) | Separate secure storage |
| TLS certificates | Caddy auto-managed | Let's Encrypt renewal |
| SSH keys | ~/.ssh/ | Local backup |
| Per-project keys | Derived via HKDF | Not stored (derivable) |

---

## 6. Infrastructure Security

### 6.1 Architecture

| Component | Location | Purpose |
|-----------|----------|---------|
| Production | 82.24.174.112 | Hostkey VPS, Zürich |
| Application | Go binary | Single binary deployment |
| Database | SQLite | Local encrypted storage |
| Proxy | Caddy | TLS termination |

### 6.2 Firewall Policy

**Default:** Deny all incoming

| Port | Source | Purpose |
|------|--------|---------|
| 22/tcp | Any (key-only) | SSH |
| 443/tcp | Any | HTTPS |
| 80/tcp | Any | Redirect to HTTPS |

### 6.3 OS Hardening

| Control | Implementation |
|---------|----------------|
| Operating system | Ubuntu 24.04 LTS |
| Updates | Automatic (unattended-upgrades) |
| Firewall | UFW, default deny |
| SSH | Key-only, password disabled |
| MAC | AppArmor enforcing |
| Kernel | SYN cookies, RP filter, ASLR |

---

## 7. Application Security

### 7.1 Secure Development

| Practice | Implementation |
|----------|----------------|
| SQL injection prevention | Parameterized queries only |
| Input validation | All external input validated |
| Output encoding | Context-appropriate encoding |
| Cryptography | Go standard library + BoringCrypto |
| Dependencies | Minimal, reviewed |
| Concurrency | Optimistic locking with ETags |

### 7.2 Prohibited Practices

- Hardcoded credentials or keys
- Logging of sensitive deal data
- Custom cryptography implementations
- Disabled security controls
- Deterministic encryption for searchable fields

### 7.3 Deployment Security

| Control | Implementation |
|---------|----------------|
| Build validation | go build with boringcrypto |
| Testing | Integration tests |
| Rollback | Previous binary available |

---

## 8. Physical Security

### 8.1 Data Center (Hostkey Zürich)

| Control | Implementation |
|---------|----------------|
| Location | Zürich, Switzerland |
| Compliance | FADP, GDPR compliant |
| Physical access | Managed by Hostkey |
| Jurisdiction | Swiss data protection law |

### 8.2 Server Security

| Control | Implementation |
|---------|----------------|
| Disk encryption | Full disk encryption |
| Physical access | Hostkey managed |
| Console | SSH only |

---

## 9. Incident Response

See: [Incident Response Plan](incident-response-plan.md)

**Contact:** security@muskepo.com

### Severity Classification

| Severity | Response Time |
|----------|---------------|
| Critical | < 1 hour |
| High | < 4 hours |
| Medium | < 24 hours |
| Low | < 72 hours |

---

## 10. Business Continuity

See: [Disaster Recovery Plan](disaster-recovery-plan.md)

| Metric | Target |
|--------|--------|
| RTO | 4 hours |
| RPO | 24 hours |
| SLA | 99.9% (excluding maintenance) |

---

## 11. Compliance

### Regulatory Framework

| Regulation | Applicability |
|------------|---------------|
| GDPR | EU residents |
| FADP | Swiss residents |
| CCPA | California residents |

### Audit Requirements

- Maintain audit logs for 7 years
- Annual security review
- Document all security incidents

---

## 12. Third-Party Services

| Vendor | Service | Data Exposure | Controls |
|--------|---------|---------------|----------|
| Hostkey | VPS hosting | Encrypted data | FADP compliant |
| Let's Encrypt | TLS certs | None | N/A |

---

## 13. Monitoring and Logging

### Logged Events

| Event | Retention |
|-------|-----------|
| HTTP requests | 90 days |
| Authentication | 90 days |
| Data access | 7 years |
| Security events | 7 years |

### Alerting

| Event | Alert Method |
|-------|--------------|
| Failed logins | Rate limiting |
| Anomalous access | Anomaly detection |
| Service outage | Monitoring alert |

---

## 14. Vulnerability Management

### Remediation SLAs

| Severity | Response | Resolution |
|----------|----------|------------|
| Critical | 4 hours | 24 hours |
| High | 24 hours | 7 days |
| Medium | 7 days | 30 days |
| Low | 30 days | 90 days |

---

## 15. Policy Maintenance

### Review Schedule

| Review | Frequency |
|--------|-----------|
| Full policy review | Annually |
| Risk assessment | Annually |
| Incident review | After each incident |
| Control testing | Quarterly |

### Change Management

Policy changes require:
1. Risk assessment of change
2. Documentation update
3. Version increment
4. Effective date notation

---

*Document end*