Security Overview

CheckTick implements comprehensive security controls aligned with the OWASP Top 10 (2021) to protect healthcare data. This document provides an overview of our security architecture and maps features to OWASP categories.

CheckTick is committed to UK Data Sovereignty; we intentionally prioritize UK-resident infrastructure and application-layer defenses over US-based interception services.

Related Security Documentation:

• Authentication & Permissions – Access control, SSO, and role-based permissions
• Encryption for Users – How your data is encrypted
• Key Management for Administrators – Enterprise key management
• Business Continuity – Disaster recovery and backup
• Audit Logging and Notifications – Security event logging
• Recovery Dashboard – Account and data recovery
• AI Security and Safety – LLM and AI feature security

Summary

A01:2021 – Broken Access Control

Risk: Users acting outside their intended permissions.

Controls Implemented

Role-Based Access Control (RBAC)

CheckTick implements a hierarchical permission model:

• Organization level: Owner, Admin, Creator, Viewer roles
• Team level: Owner, Admin, Creator, Viewer roles
• Survey level: Creator (owner), Editor, Viewer roles

Each action is verified against the user's role at the appropriate level.

Survey-Level Permissions

• Survey encryption keys are derived per-user
• Collaborator access is explicitly granted by survey owners
• Public survey links have read-only access for submissions

API Authentication

• JWT tokens with short expiration (access: 15 min, refresh: 7 days)
• Token refresh requires valid refresh token
• API endpoints enforce same permissions as web UI

Related Documentation:

• Authentication & Permissions
• Account Types & Tiers

A02:2021 – Cryptographic Failures

Risk: Exposure of sensitive data due to weak or missing encryption.

Controls Implemented

Data Encryption at Rest

• Survey data: AES-256-GCM encryption for patient-identifiable fields
• Key derivation: Argon2id with memory-hard parameters
• Key hierarchy: User KEK → Survey DEK → Field encryption

Encryption in Transit

• TLS 1.2+ required for all connections
• HSTS headers enforced
• Certificate pinning for API clients (recommended)

Key Management

• HashiCorp Vault integration for enterprise deployments
• Key escrow for ethical recovery (prevents data loss)
• Automatic key rotation support

Related Documentation: - Encryption for Users - Key Management for Administrators - Encryption Technical Reference

A03:2021 – Injection

Risk: SQL injection, command injection, or other code injection attacks.

Controls Implemented

SQL Injection Prevention

• Django ORM used exclusively (no raw SQL)
• Parameterized queries for all database operations
• Input validation on all user-supplied data

Template Injection Prevention

• Django templates with autoescaping enabled
• User content sanitized before display
• CSP headers prevent inline script execution

Command Injection Prevention

• No shell command execution from user input
• File operations use safe path handling
• Subprocess calls avoided; pure Python implementations preferred

A04:2021 – Insecure Design

Risk: Missing or ineffective security controls due to design flaws.

Controls Implemented

Privacy by Design

• Encryption is the default for patient data
• Data minimization principles applied
• Survey responses stored with minimal metadata

Threat Modelling

• Security review for all new features
• Healthcare-specific threat scenarios considered
• Recovery procedures designed with abuse prevention

Security Requirements

• All PRs reviewed for security implications
• Automated security scanning in CI/CD
• Pre-commit hooks for secret detection

Related Documentation:

• Data Governance Overview
• Business Continuity

A05:2021 – Security Misconfiguration

Risk: Insecure default settings, incomplete configurations, or exposed debug features.

Controls Implemented

Secure Defaults

• DEBUG=False enforced in production
• Secret keys generated securely
• Database credentials via environment variables

HTTP Security Headers

# Content Security Policy
CSP_DEFAULT_SRC = ("'self'",)
CSP_SCRIPT_SRC = ("'self'",)
CSP_STYLE_SRC = ("'self'", "'unsafe-inline'")  # Required for HTMX
CSP_IMG_SRC = ("'self'", "data:")
CSP_CONNECT_SRC = ("'self'",)

# Additional headers
X_FRAME_OPTIONS = "DENY"
X_CONTENT_TYPE_OPTIONS = "nosniff"
SECURE_BROWSER_XSS_FILTER = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True

Environment Separation

• Separate configurations for dev/staging/production
• Production secrets never in source control
• Environment variables for all sensitive configuration

Related Documentation:

• Self-Hosting Configuration
• Self-Hosting Quickstart

A06:2021 – Vulnerable and Outdated Components

Risk: Using components with known vulnerabilities.

Controls Implemented

Dependency Vulnerability Scanning

• pip-audit integrated in CI/CD pipeline
• Daily scheduled vulnerability scans
• Pre-commit hook for dependency changes
• Local s/security-audit script for developers

Automated Updates

• Dependabot enabled for security updates
• GitHub Actions workflows check for library updates
• Weekly version checks for CDN libraries

Self-Hosted Libraries with SRI

All client-side JavaScript libraries are self-hosted with Subresource Integrity verification:

See CDN Libraries for current versions and hashes.

Known Limitations

Some vulnerabilities are blocked by upstream dependencies:

• ggshield pins older versions of cryptography and urllib3
• These are tracked and will be updated when upstream releases fixes

Related Documentation:

• CDN Libraries

A07:2021 – Identification and Authentication Failures

Risk: Weak authentication allowing unauthorized access.

Controls Implemented

Two-Factor Authentication (2FA)

• TOTP-based 2FA using authenticator apps (Google Authenticator, Authy, etc.)
• Mandatory for password users accessing sensitive features
• Backup codes for account recovery (10 single-use codes)
• SSO/OIDC users exempt (rely on provider's MFA)

Password Policies

Healthcare-compliant password requirements:

Session Management

Brute Force Protection

• django-axes limits failed login attempts
• Default: 5 failures → 1 hour lockout
• IP-based and username-based tracking
• Email notification sent when account is locked

Related Documentation:

• Authentication & Permissions
• OIDC SSO Setup

A08:2021 – Software and Data Integrity Failures

Risk: Code and infrastructure without integrity verification.

Controls Implemented

Subresource Integrity (SRI)

All external JavaScript includes SRI hashes:

<script src="/static/js/htmx.min.js"
        integrity="sha384-EfwldhYywH4qYH9vU8lMn+pd6pcH0kGpPUVJuwyHnj/5felkkIUVxf1wMAEX7rCY"
        crossorigin="anonymous"></script>

CI/CD Security

• Pre-commit hooks: Secret scanning (GitGuardian), formatting, linting
• GitHub Actions: Automated testing, security scanning
• CodeQL: Static analysis for Python and JavaScript

Signed Commits

• GPG signing recommended for all contributors
• Verified commits badge on GitHub

Related Documentation:

• CDN Libraries

A09:2021 – Security Logging and Monitoring Failures

Risk: Insufficient logging preventing detection of breaches.

Controls Implemented

Unified Audit Logging

All security-relevant events are logged to the AuditLog model:

Authentication Events:

• login_success / login_failed – with IP and user agent
• logout – session termination
• account_locked – after failed attempts

2FA Events:

• 2fa_enabled / 2fa_disabled – configuration changes
• 2fa_verified / 2fa_failed – verification attempts
• backup_codes_generated / backup_code_used – backup code lifecycle

Account Events:

• user_created – new account registration
• password_changed – password updates

Log Entry Structure

Each audit entry includes:

• Timestamp
• Actor (user performing action)
• Action type with severity (INFO/WARNING/CRITICAL)
• IP address and user agent
• Target user (if different from actor)
• Structured metadata

SIEM-Ready Format

Audit logs are structured for export to SIEM systems:

• JSON format compatible with Elasticsearch, Splunk, etc.
• Correlation IDs for request tracing
• Severity levels for alerting

Note: SIEM integration is not pre-configured; administrators can export logs to their preferred system.

Retention

Related Documentation:

• Audit Logging and Notifications

A10:2021 – Server-Side Request Forgery (SSRF)

Risk: Server making requests to unintended locations.

Controls Implemented

URL Validation

• User-provided URLs validated before use
• Allowlists for external service integrations
• Internal network addresses blocked

Network Segmentation

• Database not accessible from internet
• Vault (if used) on private network
• Outbound requests limited to known services

Container Isolation

• Docker containers with minimal privileges
• Network policies restrict inter-container communication
• No privileged containers

Continuous Improvement

Security Scanning Schedule

National Cyber Security Centre (NCSC) Integration

CheckTick is registered for and actively utilizes the NCSC Early Warning Service.

• Threat Intelligence: We receive automated notifications from the NCSC regarding malicious activity, compromised credentials, or vulnerabilities detected on our registered UK IP addresses and domains.
• Triage Process: Critical alerts from the NCSC are triaged by the CTO within 4 hours.
• National Grid: This integration ensures CheckTick is connected to the UK's national cyber defense infrastructure, providing an advanced layer of threat detection.

Sovereign Advanced Threat Protection (ATP)

In alignment with DSPT Standard 8.3, CheckTick manages an active ATP capability through application-layer and platform-native tools, ensuring data never leaves UK jurisdiction for security processing.

Reporting Security Issues

If you discover a security vulnerability:

1. Do not open a public issue
2. Email [email protected] with details
3. Include steps to reproduce
4. Allow 90 days for fix before disclosure

We follow responsible disclosure and credit researchers who report valid issues.

Developer Environment Security Standard

1. Tooling & Patching

Because developer machines hold access tokens for GitHub and Northflank, they are treated as 'Remote Endpoints':

• Automated OS Updates: macOS is configured to install security response files automatically (Window: <7 days).
• IDE & Tooling: VS Code and Extensions are set to auto-update.
• Git Client: Checked monthly for security updates to prevent 'Clone-based' vulnerabilities.

2. Dependency Sync (Poetry)

We avoid 'Version Drift' between laptops and production: * Local development must be performed within a virtual environment managed by Poetry. * Running poetry install is a prerequisite for any local development session to ensure the local stack is patched to the latest approved versions in pyproject.toml.

3. Credential Protection

• No Hardcoded Secrets: Local .env files are added to .gitignore.
• MFA: Access to the GitHub repository and Northflank console requires Hardware/App-based MFA.
• SSH Keys: SSH keys used for Git pushes are stored in the macOS Keychain and protected by biometric/password lock.

References

• OWASP Top 10 (2021)
• OWASP ASVS
• NHS DSPT
• HIPAA Security Rule
• NCSC Early Warning Service