Security Statement

1. Hosting and infrastructure

• Primary host: Hetzner Online GmbH, data centres in Germany (EU). ISO 27001 certified.
• Compute: Dedicated virtual machine. Operating system: Ubuntu 24.04 LTS, automatic security updates enabled.
• Network exposure: Only ports 22 (SSH, key-only), 80 (HTTP, redirects to 443), and 443 (HTTPS) reachable from the public internet. All other services bind to loopback only.
• Database: PostgreSQL 17, latest stable, dedicated cluster for Muster. The database role used by Muster has access only to the Muster database — it cannot read or modify any other application running on the same hardware. SCRAM-SHA-256 password authentication.

2. Encryption

• In transit: HTTPS only, TLS 1.2 minimum. Let's Encrypt certificates, auto-renewed. HTTP requests are 301-redirected to HTTPS.
• At rest (database): Hetzner-provided full-disk encryption (LUKS) on the host. Postgres data files encrypted at the storage layer.
• At rest (backups): Daily logical backups (pg_dump) compressed and encrypted with age before being shipped to off-site storage. The decryption key is stored only on the production host and in a sealed offline vault.
• Field-level encryption: The most sensitive fields (BVN, NIN, where collected) are encrypted at the application layer with a key derived from SECRET_KEY. Even a stolen database file does not yield BVN/NIN values without the application key.
• Secrets: All secrets (database password, payment gateway keys, SMTP credentials, Django secret) live in a .env file readable only by the deploy user. No secrets in source control.

3. Authentication and session security

• Passwords hashed with PBKDF2-SHA256 (Django default), per-user salt, hundreds of thousands of iterations. Plaintext passwords are never stored or logged.
• Password validators enforce minimum length, prevent common passwords, and reject all-numeric passwords.
• Sessions are server-side, signed cookies. 30-minute idle timeout. Cookies marked Secure, HttpOnly, SameSite=Lax.
• Forgot-password tokens are single-use, signed, and expire within 4 hours. Used tokens are invalidated.
• Rate limiting: 5 attempts per IP per 5 minutes on login; 3 password-reset requests per IP per hour. Excessive attempts return HTTP 429 with a back-off page.
• Two-factor authentication (TOTP) is on the security roadmap.

4. Access control and tenancy isolation

• Six-tier role model: org owner / org admin / program manager / location admin / field manager / viewer. Each role has explicit capability flags (can_manage_org, can_manage_billing, etc.) — code asks "can this user do X?" not "what role are they?"
• Every record in the database carries an organization foreign key. Querysets are filtered by the active tenant on every request. List-level scoping respects role: a field user sees only their own records, a unit admin sees their unit's records, an org admin sees the whole organization.
• Object-level access checks return HTTP 404 (not 403) for unauthorised access — preventing information leak by URL guessing.
• Platform administration is gated by a separate flag (is_platform_admin) and a separate URL prefix. Tenant users cannot reach platform administration.

5. Audit logging

• Every state-changing action is recorded in an append-only audit log: who (user ID), when (UTC timestamp), what (action code + summary), target (object ID), originating IP.
• Audit log entries are retained indefinitely for the lifetime of the organization account, even after raw personal data is purged. This preserves the compliance trail.
• Audit logs are exposed to organization administrators in-app and exportable as CSV.
• Tamper-evidence: each entry is hash-chained with the previous entry (SHA-256 of prior content + hash). Retroactive deletion or modification is detectable.

6. Application-layer hardening

• SQL injection: ORM-only data access. No raw SQL in user-facing code paths.
• XSS: Template engine auto-escapes by default. User-uploaded HTML is never rendered inline.
• CSRF: Django CSRF middleware on every state-changing request. CSRF tokens propagated to htmx requests via hx-headers.
• Clickjacking: X-Frame-Options: DENY.
• Open redirect: Redirects only to named URLs; user-supplied ?next= values validated against an allow-list.
• File uploads: Type allow-list (image/*, application/pdf), 10 MB cap, per-org/per-feature storage path prefix. Uploads served with Content-Disposition: attachment to prevent inline rendering.
• Debug mode: Disabled in production. No stack traces returned to users.
• Allowed hosts: Locked to the production domain.

7. Vulnerability management

• Python dependencies scanned with pip audit on each deploy.
• Operating system patches applied weekly via unattended-upgrades.
• PostgreSQL minor releases applied within 30 days of release.
• Security advisories from Django and major dependencies subscribed and triaged within 24 hours.

8. Backups and disaster recovery

• Daily pg_dump, encrypted, shipped to off-site object storage (EU region).
• Retention: 30 daily, 12 monthly, 7 yearly.
• Recovery time objective (RTO): 4 hours to restore service in the event of a host failure.
• Recovery point objective (RPO): 24 hours (loss limited to one day of writes; offset by point-in-time WAL archiving where enabled).
• Restore procedure documented in an internal runbook; tested at least twice per year.

9. Personnel

• Production access is limited to a small number of named engineers under written confidentiality agreements.
• SSH access is key-based only. No password SSH, no shared accounts.
• Access is revoked promptly when a person leaves the team.
• Production actions (deploys, database access) are logged at the OS level.

10. Incident response

1. Detect: Error monitoring (Sentry), uptime monitoring, log review.
2. Triage: Within 1 hour of detection during business hours, within 4 hours otherwise.
3. Contain: Suspend affected functionality if necessary; preserve evidence.
4. Notify: Affected customer organizations within 72 hours of confirming a personal-data breach. Regulators within statutory windows.
5. Eradicate & recover: Patch root cause; restore from clean state; resume service.
6. Lessons learned: Post-incident review documented; preventive controls added.

11. Data retention and deletion

Documented in §5 of the Privacy Policy. Headlines: raw PII purged 7 days after batch processing (default, configurable per organization); metadata retained for the life of the account; full deletion within 30 days of account closure (subject to backup rotation).

12. Compliance

• NDPR 2019 / NDPA 2023 — Nigeria's data protection regime. Muster aligns with the principles of lawful processing, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, accountability.
• GDPR / UK GDPR — for customers and data subjects in the EU/UK. The DPA in §10 provides the contractual safeguards required.
• ISO 27001 — controls aligned, certification not yet pursued. Mapped controls available to enterprise customers under NDA.
• Independent penetration testing — planned for the first major enterprise contract.

13. Coordinated vulnerability disclosure

We welcome reports from security researchers. Please email security@datadruidtech.org.ng with:

• A description of the issue
• Steps to reproduce
• The potential impact
• Any suggested mitigation

We commit to:

• Acknowledge your report within 48 hours
• Provide a triage update within 5 business days
• Not pursue legal action against good-faith researchers who follow this disclosure process and do not access or modify customer data
• Credit you (with your permission) once a fix is deployed

14. Roadmap

Items planned for the next two quarters:

• Two-factor authentication (TOTP) for all org owners and platform admins
• WAF (Cloudflare) in front of the application
• Independent third-party penetration test
• SOC 2 Type I / ISO 27001 readiness assessment
• SSO (Microsoft Entra, Google Workspace) for enterprise customers

15. Contact

General security: security@datadruidtech.org.ng
Detailed packet (under NDA): same address; responses within 5 business days.