Security Hardening Checklist

ThemisDB Production Security Hardening Checklist

Version: 1.4.0
Last Updated: April 2026
Status: Production Ready
Security Score: 92/100

---

📋 Overview

This checklist ensures ThemisDB is configured with production-grade security before deployment. Follow each section to harden your ThemisDB installation against common attack vectors and meet compliance requirements.

Target Environments:

• ✅ Enterprise Production
• ✅ GPU-Accelerated Deployments
• ✅ Cloud Environments (AWS, Azure, GCP)
• ✅ On-Premises Data Centers
• ✅ Healthcare (HIPAA)
• ✅ Financial Services
• ✅ Government (BSI C5, SOC 2)

---

🔒 P0 - CRITICAL Security Controls

✅ 1. VRAM Secure Clear (GPU Deployments)

Status: ✅ IMPLEMENTED
Priority: P0 - CRITICAL
Compliance: GDPR Art. 32, SOC 2 CC6.1, HIPAA § 164.310

Verification:

# Check if secure clear is enabled
grep -r "VRAMSecureClear" src/
grep "secureClearCUDA\|secureClearHIP" src/llm/

# Test VRAM clearing
./build/tests/test_vram_secure_clear --gtest_filter="*SecureClear*"

Configuration:

# config/security.yaml
gpu_security:
  vram_secure_clear:
    enabled: true
    num_passes: 3           # Multi-pass overwrite
    verify_clear: false     # Set true for compliance audits
    audit_log: true         # Log all VRAM operations

What It Protects Against:

• ❌ Cold-boot attacks
• ❌ Memory dump attacks
• ❌ Inter-process memory leakage
• ❌ Encryption key exposure in VRAM
• ❌ Model weight extraction
• ❌ Embedding theft

Checklist:

• VRAM secure clear enabled in production config
• Tested with GPU workloads (LoRA training, inference)
• Audit logging enabled for VRAM operations
• Verified secure clear in GPU memory manager
• Confirmed no performance degradation (<5% overhead)

---

✅ 2. Multi-Factor Authentication (MFA)

Status: ✅ IMPLEMENTED
Priority: P1 - HIGH
Compliance: SOC 2 CC6.1, NIST SP 800-63B Level 2

Verification:

# Test MFA implementation
./build/tests/test_mfa_authenticator --gtest_filter="*MFA*"

# Check MFA enrollment
curl -X POST http://localhost:8080/api/v1/auth/mfa/enroll \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json"

Configuration:

# config/auth.yaml
mfa:
  enabled: true
  totp:
    time_step_seconds: 30
    code_length: 6
    time_window: 1          # ±30 seconds tolerance
    issuer: "ThemisDB"
  recovery_codes:
    count: 8
    length: 8
  enforcement:
    admin_required: true    # MFA mandatory for admins
    operator_required: true
    user_optional: true     # Optional for regular users

Setup Procedures:

1. Enable MFA for admin accounts:

   themisctl auth mfa enroll --user admin

2. Generate QR code for mobile authenticator:

   themisctl auth mfa qr-code --user admin > qr.png

3. Generate recovery codes:

   themisctl auth mfa recovery-codes --user admin

4. Test MFA login:

   curl -X POST http://localhost:8080/api/v1/auth/login \
     -d '{"username":"admin","password":"***","mfa_code":"123456"}'

Checklist:

• MFA enabled for all admin accounts
• MFA enabled for operator accounts
• Recovery codes generated and securely stored
• Mobile authenticator apps configured (Google Authenticator, Authy)
• MFA bypass disabled in production
• Audit logging enabled for MFA events
• User training completed on MFA procedures

---

🛡️ P1 - HIGH Priority Security Controls

✅ 3. TLS 1.3 Encryption

Status: ✅ CONFIGURED
Priority: P1 - HIGH

Configuration:

# config/tls.yaml
tls:
  enabled: true
  version: "1.3"
  fallback: "1.2"          # TLS 1.2 for legacy clients
  cipher_suites:
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_GCM_SHA256
  certificate: /etc/themis/certs/server.crt
  private_key: /etc/themis/certs/server.key
  client_ca: /etc/themis/certs/ca.crt  # For mTLS

Checklist:

• Valid TLS certificate installed (not self-signed in prod)
• TLS 1.3 enabled
• Weak cipher suites disabled
• HSTS header enabled
• Certificate expiry monitoring configured
• Automated certificate renewal (Let's Encrypt/ACME)
• mTLS configured for service-to-service communication

---

✅ 4. Enhanced Audit Logging

Status: ✅ IMPLEMENTED
Priority: P1 - HIGH
Compliance: GDPR Art. 30, SOC 2 CC7.2, HIPAA § 164.312

Configuration:

# config/audit.yaml
audit_logging:
  enabled: true
  encrypt_then_sign: true
  log_path: /var/log/themis/audit.jsonl
  key_id: saga_log
  
  # Hash chain for tamper detection
  enable_hash_chain: true
  chain_state_file: /var/lib/themis/audit_chain.json
  
  # SIEM integration
  enable_siem: true
  siem_type: syslog       # or "splunk"
  siem_host: siem.company.com
  siem_port: 514
  splunk_token: ${SPLUNK_HEC_TOKEN}
  
  # Event filtering
  log_levels:
    - HIGH
    - MEDIUM
  
  # Retention
  retention_days: 365     # 1 year minimum for compliance
  archive_after_days: 90
  archive_path: /archive/themis/audit/

New Event Types (v1.4.0):

MFA Events:
- MFA_ENROLLED
- MFA_ENABLED
- MFA_DISABLED
- MFA_TOTP_SUCCESS
- MFA_TOTP_FAILED
- MFA_RECOVERY_CODE_USED
- MFA_RECOVERY_CODES_REGENERATED

GPU/VRAM Security:
- VRAM_ALLOCATED
- VRAM_DEALLOCATED
- VRAM_SECURE_CLEAR
- GPU_MEMORY_EXHAUSTION

Binary Integrity:
- BINARY_SIGNATURE_VERIFIED
- BINARY_SIGNATURE_FAILED
- MANIFEST_UPDATED

Checklist:

• Audit logging enabled
• Encrypt-then-sign configured
• Hash chain enabled for tamper detection
• SIEM integration configured
• Log retention policy configured (365+ days)
• Automated log archival configured
• Audit log integrity verified on startup
• Alert rules configured for suspicious events
• Regular audit log reviews scheduled

---

✅ 5. OWASP ZAP Automated Security Scanning

Status: ✅ IMPLEMENTED
Priority: P1 - HIGH

GitHub Actions Workflow: .github/workflows/owasp-zap.yml

Scan Types:

1. Baseline Scan (PR/Push): Fast passive scanning
2. Full Scan (Weekly): Deep active scanning with spider
3. API Scan (PR/Push): OpenAPI specification testing

Configuration:

# .github/zap/rules.tsv
40012	FAIL	Cross Site Scripting (Reflected)
40018	FAIL	SQL Injection
90020	FAIL	Remote OS Command Injection
90023	FAIL	XML External Entity Attack
90034	FAIL	JWT None Algorithm

Checklist:

• OWASP ZAP workflow enabled
• Baseline scan runs on PRs
• Weekly full scan scheduled
• API scan configured with OpenAPI spec
• Scan results reviewed and triaged
• High/critical findings addressed before release
• False positives documented

---

🔐 P2 - MEDIUM Priority Security Controls

✅ 6. Binary Integrity Verification

Status: ✅ IMPLEMENTED
Priority: P2 - MEDIUM
Compliance: NIST SP 800-218 (SSDF), SOC 2 CC7.1

Binary Manifest Signing Framework

ThemisDB now implements RSA-4096 manifest signing to verify the integrity of release binaries and detect tampering.

Features:

• ✅ RSA-4096 digital signatures for non-repudiation
• ✅ SHA-256 file hashing for integrity verification
• ✅ Manifest generation from build artifacts
• ✅ Startup verification with automatic checks
• ✅ Audit logging for all verification events

Configuration:

# config/binary_verification.yaml
binary_verification:
  enabled: true
  manifest_path: /etc/themis/release_manifest.json
  binaries_root: /opt/themis/bin
  
  # Signing configuration
  signing:
    algorithm: RSA-4096-SHA256
    key_id: release_key
  
  # Verification on startup
  verify_on_startup: true
  fail_on_invalid: true      # Exit if verification fails
  
  # Update verification
  verify_updates: true
  allow_unsigned_dev: false  # Reject unsigned binaries in production

Generating Release Manifest:

# Generate manifest for release binaries
themisctl manifest generate \
  --root /opt/themis/bin \
  --version 1.4.0 \
  --build-id $(git rev-parse HEAD) \
  --output release_manifest.json \
  --include "*.exe" "*.so" "*.dll"

# Sign manifest with RSA-4096 key
themisctl manifest sign \
  --input release_manifest.json \
  --key-id release_key \
  --output signed_manifest.json

# Verify manifest signature
themisctl manifest verify \
  --manifest signed_manifest.json \
  --binaries /opt/themis/bin

Programmatic Usage:

#include "security/manifest_signer.h"

// Generate manifest
auto signing_service = createKeyProviderSigningService(key_provider);
ManifestSigner::Config config{.key_id = "release_key"};
ManifestSigner signer(signing_service, config);

BinaryManifest manifest = signer.generateManifest(
    "/opt/themis/bin",
    "1.4.0",
    "abc123",
    {"*.exe", "*.so", "*.dll"}
);

// Sign manifest
SignedManifest signed = signer.signManifest(manifest);
signed.saveToFile("/etc/themis/signed_manifest.json");

// Verify on startup
StartupVerifier::Config verifier_config{
    .manifest_path = "/etc/themis/signed_manifest.json",
    .binaries_root = "/opt/themis/bin",
    .fail_on_invalid = true
};
StartupVerifier verifier(signing_service, verifier_config);
bool valid = verifier.verify();  // Exits if invalid

Manifest Structure:

{
  "manifest": {
    "metadata": {
      "version": "1.4.0",
      "build_id": "abc123def456",
      "timestamp": 1705579200,
      "release_type": "release",
      "platform": "linux-x64"
    },
    "files": [
      {
        "path": "bin/themisdb",
        "sha256_hash": "a1b2c3d4...",
        "size_bytes": 52428800,
        "version": "1.4.0"
      }
    ]
  },
  "signature": "base64_encoded_rsa4096_signature",
  "signature_algorithm": "RSA-4096-SHA256",
  "signer_id": "release_key"
}

Security Benefits:

• ❌ Prevents binary tampering
• ❌ Detects supply chain attacks
• ❌ Verifies update authenticity
• ❌ Ensures release integrity

Checklist:

• Binary integrity verification implemented
• RSA-4096 signing keys generated
• Public key distributed securely
• Release manifest signed
• Startup verification enabled
• Update verification enabled
• Invalid signature handling tested
• Audit logging configured
• CI/CD pipeline integration (sign on release)
• Documentation updated

---

🔒 Additional Security Hardening

7. Rate Limiting

# config/rate_limit.yaml
rate_limiting:
  enabled: true
  algorithm: token_bucket
  per_ip:
    requests: 100
    window_seconds: 60
  per_user:
    requests: 1000
    window_seconds: 60
  per_endpoint:
    /api/v1/auth/login:
      requests: 5
      window_seconds: 300      # 5 attempts per 5 minutes
    /api/v1/admin/*:
      requests: 50
      window_seconds: 60

Checklist:

• Rate limiting enabled globally
• Authentication endpoints rate limited (brute force protection)
• Admin endpoints rate limited
• Rate limit headers exposed (X-RateLimit-*)
• Rate limit exceeded responses logged

---

8. Input Validation & Sanitization

Checklist:

• AQL injection prevention validated
• Path traversal protection tested
• XSS prevention in all user inputs
• JSON schema validation enabled
• Request body size limits enforced (10MB default)
• Content-Type validation strict
• Unicode normalization applied

Tests:

# Run security tests
./build/tests/security/test_input_validation_security
./build/tests/security/test_jwt_security

---

9. Network Security

Checklist:

• Firewall configured (allow only necessary ports)
• Internal services not exposed publicly
• VPC/network segmentation configured
• Egress filtering configured
• DDoS protection enabled (CloudFlare, AWS Shield)
• Intrusion detection system (IDS) configured

---

10. Database Security

Checklist:

• Field-level encryption enabled for sensitive data
• Encryption at rest enabled (AES-256-GCM)
• Key rotation policy configured (90 days)
• HSM integration for key management (production)
• Database backups encrypted
• Access control (RBAC) configured
• Least privilege principle enforced

---

📊 Compliance Validation

GDPR Compliance

• Right to erasure implemented (PII deletion)
• Data minimization (only necessary data collected)
• Audit trail for PII access
• Encryption at rest and in transit
• Data breach notification procedures
• DPO contact information documented

SOC 2 Type II Compliance

CC6 - Logical Access:

• Multi-factor authentication
• Role-based access control
• Password policies enforced
• Session management

CC7 - System Operations:

• Audit logging with integrity verification
• Security monitoring and alerting
• Incident response procedures
• Change management process

HIPAA Compliance

• PHI encryption (field-level encryption)
• Access controls and audit trails
• Automatic logoff (session timeout)
• Encryption at rest and in transit
• Backup and disaster recovery
• Business associate agreements

---

🧪 Security Testing

Pre-Production Testing

Automated Tests:

# Run all security tests
cmake --build build --target test_security

# VRAM security
./build/tests/test_vram_secure_clear

# MFA validation
./build/tests/test_mfa_authenticator

# JWT security
./build/tests/security/test_jwt_security

# Input validation
./build/tests/security/test_input_validation_security

# Audit logging
./build/tests/test_audit_logger

Manual Testing:

# Penetration testing
./scripts/security/pentest.sh

# Vulnerability scanning
trivy image themisdb/themisdb:latest

# Secret scanning
gitleaks detect --source .

---

📝 Production Deployment Checklist

Pre-Deployment

• All P0 (CRITICAL) controls implemented
• All P1 (HIGH) controls implemented
• Security tests passing
• Penetration testing completed
• Vulnerability scan completed (no high/critical findings)
• Security configuration reviewed
• Secrets rotated (no dev/test secrets in production)
• Backup and recovery tested
• Monitoring and alerting configured
• Incident response plan documented
• Security team trained

Post-Deployment

• Security monitoring active
• Audit log verification scheduled
• Security scan scheduled (weekly)
• Penetration test scheduled (quarterly)
• Security patch process established
• User security training completed
• Compliance audit scheduled (annual)

---

🚨 Incident Response

Security Event Response

High-Severity Events:

1. Unauthorized access attempts (5+ failed logins)
2. JWT none algorithm detected
3. SQL/AQL injection attempts
4. VRAM secure clear failures
5. MFA bypass attempts
6. Binary signature verification failures

Response Procedures:

1. Alert security team (email, Slack, PagerDuty)
2. Isolate affected systems
3. Collect forensic evidence (logs, memory dumps)
4. Analyze attack vector
5. Apply remediation
6. Verify fix
7. Post-incident review
8. Update security controls

---

📚 References

• Security Hardening Guide
• Penetration Testing Guide
• MFA Setup Guide
• VRAM Security Guide
• Audit Logging Guide

---

✅ Final Sign-Off

Security Review:

• Security team approval
• Compliance team approval
• CTO/CISO approval

Deployment Authorization:

Reviewer: _____________________
Date: _____________________
Signature: _____________________

---

Security Score: 92/100 ⭐⭐⭐⭐⭐

Deployment Status: ✅ PRODUCTION READY

---

ThemisDB 1.9.0-beta · Home · Module-Index · GitHub · Issues