Security Architecture

Last updated: March 2026

1. Architecture Overview

M4NG0 OS Hospital Edition is a locally deployed clinical operating system built on Electron with a local SQLite database. The system is designed for on-premise operation with no dependency on external cloud services for core clinical functions.

┌─────────────────────────────────────────┐
│         Client Interfaces               │
│   Desktop App / Tablet / QR Kiosk       │
├─────────────────────────────────────────┤
│         Application Core                │
│   Authentication → RBAC → Modules       │
├─────────────────────────────────────────┤
│         Data Layer                       │
│   Encrypted SQLite │ Audit Logs │ Files  │
├─────────────────────────────────────────┤
│         Hospital Infrastructure         │
│   Local Server / Workstation / Network  │
└─────────────────────────────────────────┘

2. Data Protection

2.1 Encryption at Rest

• PHI fields encrypted using AES-256-GCM.
• Encryption applied at the field level — non-PHI columns remain queryable without decryption.
• Database files are additionally protected by filesystem-level encryption where supported by the host OS.

2.2 Encryption in Transit

• All internal communication uses TLS 1.3.
• Multi-facility sync (when enabled) uses end-to-end encryption with hospital-held keys.
• QR self-intake connections use HTTPS with certificate pinning.

2.3 Key Management

• Encryption keys generated during initial deployment using cryptographically secure random number generation.
• Keys stored on the hospital's hardware, never transmitted to M4NG0.
• Key rotation supported on configurable schedule.
• Separate keys for data encryption, backup encryption, and sync encryption.

3. Authentication & Access Control

3.1 Authentication Stack

3.2 Role-Based Access Control

Seven predefined clinical roles with non-overlapping permission sets:

3.3 Session Management

• Auto-lock after 5 minutes of inactivity.
• Maximum session duration: 12 hours.
• PHI cleared from display on lock screen.
• Concurrent sessions prevented per user account.
• PIN re-authentication for session resume.

4. Audit Architecture

4.1 Log Structure

Every access to PHI generates an audit entry containing:

{
  "timestamp": "2026-03-05T14:21:03Z",
  "actor": "dr.ahmed",
  "staff_id": "S-0042",
  "action": "VIEW_PATIENT_RECORD",
  "resource": "patient:P-20240301",
  "fields_accessed": ["name", "diagnosis", "medications"],
  "device": "ER-Doctor-Tablet-03",
  "session_id": "sess_abc123",
  "prev_hash": "a3f8c1...",
  "entry_hash": "7b2e9d..."
}

4.2 Tamper Detection

• Each log entry includes a SHA-256 hash of its contents combined with the previous entry's hash.
• Hash chain integrity is verified automatically during system startup.
• Any modification, deletion, or insertion into the log sequence is detectable.
• Audit log database is append-only — the application service account has INSERT and SELECT permissions only.

4.3 Retention

• PHI access logs retained for minimum 6 years.
• System logs retained for 1 year.
• Audit logs stored separately from the main application database.
• Audit log backups included in the encrypted backup schedule.

5. Network Security

• M4NG0 OS operates within the hospital's local network. No inbound connections from the public internet are required.
• QR self-intake uses a local web server accessible only within the facility network.
• Optional cloud sync uses outbound-only connections with certificate pinning.
• No remote access capability is built into the system. Remote support requires explicit hospital authorization and a temporary secure tunnel.

6. Emergency Access

Break-the-Glass procedure for emergency clinical situations:

• Authorized clinicians can override role restrictions to access any patient record.
• Emergency access is logged with a distinct action type and requires a reason code.
• Hospital administrators are notified immediately.
• Post-incident justification required within 24 hours.
• All emergency access events are flagged in the audit log for compliance review.

7. Vulnerability Management

• Security patches released within 24 hours of critical vulnerability discovery.
• Dependencies audited weekly for known CVEs.
• Penetration testing conducted quarterly by independent assessors.
• Responsible disclosure program available for external security researchers.