WATCHDESK

WATCHDESK is built to protect the sensitive personal information that volunteer fire departments entrust to it — including Social Security Numbers, personal contact details, and service records. Security is not an afterthought; it is engineered into every layer of the platform, from how data is stored and encrypted to how users authenticate and how stations are isolated from one another.

This document provides a technical overview of the security controls in place. If you have questions about any of these measures, contact admin@watchdesk.org.

Social Security Numbers are the most sensitive data WATCHDESK handles. They are required for LOSAP retirement credit forms and Maryland State Tax Credit submissions, and they receive the highest level of protection in the system.

Encryption at Rest

SSNs are encrypted before being written to the database using AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode). This is an authenticated encryption algorithm, which means it provides both confidentiality (data cannot be read without the key) and integrity (any tampering with the ciphertext is automatically detected and rejected).

• Key length: 256-bit (the strongest AES key size)
• Mode: GCM (Galois/Counter Mode) with a 128-bit authentication tag
• Initialization vector: A cryptographically random 96-bit IV is generated for each encryption operation, ensuring that encrypting the same SSN twice produces completely different ciphertext
• Key storage: The encryption key is stored in Google Cloud Secret Manager, a dedicated secrets vault — completely separate from the database. The key never resides in source code, configuration files, or environment variables on disk

Access Controls on SSN Data

• SSNs are never displayed in standard application views. Only a masked format (e.g., ***-**-1234) is shown in the interface
• Full SSN decryption occurs only when generating official LOSAP or State Tax forms required by government agencies
• Administrative access to reveal a full SSN is rate-limited (maximum 10 requests per 15-minute window per user) and individually logged with the requesting user's identity and timestamp
• Members can view their own SSN through the self-service portal, subject to the same rate limiting and audit logging

All communication between your browser and WATCHDESK is encrypted using TLS (Transport Layer Security). This prevents anyone on the network — including ISPs, Wi-Fi operators, or other devices on the same network — from reading or modifying data in transit.

HTTPS Enforcement

• WATCHDESK is served exclusively over HTTPS. Unencrypted HTTP connections are not accepted
• The server sends a Strict-Transport-Security (HSTS) header with a one-year duration, instructing browsers to always use HTTPS for all future requests — even if a user types http:// in the address bar
• TLS termination is handled by Google's global load balancer infrastructure, which supports TLS 1.2 and TLS 1.3 with modern cipher suites

Database Connection Encryption

The connection between the application server and the PostgreSQL database is encrypted automatically through Google Cloud's internal networking. In the production environment, the application connects via a secure Unix domain socket provided by Google Cloud SQL, which does not traverse any external network.

WATCHDESK uses OAuth 2.0 Single Sign-On (SSO) for all member authentication. This means WATCHDESK does not store or manage user passwords. Instead, authentication is delegated to your station's existing identity provider — either Google Workspace or Microsoft 365.

Why This Matters

• No password database to breach. Since WATCHDESK never stores passwords, there is no password database that could be compromised
• Your IT policies apply automatically. Password complexity requirements, multi-factor authentication (MFA), account suspension, and session policies set by your station's IT administrator are enforced by Google or Microsoft — not by WATCHDESK
• Credential phishing is mitigated. Users sign in through Google or Microsoft's own login page — never through a WATCHDESK-hosted password form
• Instant deactivation. If a member leaves the department and their Google Workspace or Microsoft 365 account is disabled, they immediately lose access to WATCHDESK. No separate account to remember to deactivate

Per-Station OAuth Configuration

Each station has its own OAuth credentials, registered under that station's own Google Workspace or Microsoft 365 tenant. This means your station's IT administrator controls which identity provider is used and maintains full ownership of those credentials.

After a user is authenticated, WATCHDESK enforces role-based access control (RBAC) to determine what actions they are permitted to take. Roles are assigned per member and are checked on every request.

WATCHDESK serves multiple fire stations from a single platform. Each station's data is logically isolated so that members and administrators at one station can never view, query, or modify data belonging to another station.

How Isolation Works

• Every record in the database (members, responses, meetings, hours, training, attachments, audit logs, etc.) is tagged with a station identifier
• When a user signs in, the system determines their station from their member record. Every subsequent database query is automatically scoped to include only records matching that station identifier
• This scoping is applied at the service layer — the code that executes before any database query runs. There is no mechanism in the application for a user to override or alter their station scope
• File attachments are organized into station-specific storage paths. A download request for a file belonging to another station will be denied even if the file identifier is known

What This Means for Your Station

Your member roster, response history, hours, training records, meeting attendance, LOSAP and State Tax data, and uploaded documents are visible only to authorized members of your own station. No other station on the platform can access your data through the application.

WATCHDESK sends a suite of security headers with every HTTP response. These headers instruct the browser to enable built-in protections against common web attacks.

Sensitive endpoints are protected by rate limiting, which restricts the number of requests a single client can make within a time window. This defends against brute-force login attempts, credential stuffing, and automated data harvesting.

When a rate limit is exceeded, the server responds with 429 Too Many Requests and the client must wait for the window to reset. Rate limits are applied per IP address.

Members and administrators can upload file attachments (certificates, training documents, images, etc.) to various record types. Every upload passes through three layers of validation before being accepted.

Three-Layer File Validation

1. MIME type allowlist — Only approved file types are accepted (PDF, JPEG, PNG, GIF, WebP, Microsoft Office, and plain text). All other types are rejected
2. Extension cross-validation — The file extension must match the declared MIME type. A file claiming to be image/jpeg but named with an .html extension is rejected
3. Magic byte inspection — The actual binary content of the file is inspected to verify its true format matches the declared type. This prevents attackers from disguising executable or script files as images or documents

Storage & Access

• Files are stored in a private cloud storage bucket that is not publicly accessible. There are no direct download URLs
• All file downloads are served through authenticated API endpoints that verify the requesting user's identity and station membership before returning the file
• Files are organized into station-specific paths, reinforcing data isolation
• Maximum file size is 10 MB per upload
• Per-station storage quotas can be configured to prevent abuse
• All uploads and deletions are recorded in the audit log

WATCHDESK maintains a comprehensive audit trail of all significant actions taken within the application. This log provides accountability, supports incident investigation, and helps station administrators monitor activity.

What Is Logged

• Record operations — every create, update, and delete across all modules (members, responses, meetings, hours, training, drills, certifications, etc.)
• Approval actions — when an admin approves or rejects a member submission
• SSN access — every time a full SSN is revealed, including who requested it
• File operations — uploads and deletions, including filename and size
• Certification actions — when a certifier marks a member as LOSAP or State Tax qualified

Log Details

Each audit entry records the date and time, the email address of the user who performed the action, the type of action (create, update, delete, approve, reject, etc.), and a description of what was affected. Logs are scoped to each station and viewable by station administrators through the admin dashboard.

After a user signs in, the application creates a session to maintain their authenticated state across page requests. Sessions are designed with the following protections:

• Server-side storage — session data is stored in the database, not in the browser. The browser receives only an opaque session identifier cookie
• HttpOnly flag — the session cookie cannot be read by client-side JavaScript, protecting against cross-site scripting (XSS) attacks that attempt to steal session tokens
• Secure flag — the cookie is transmitted only over HTTPS connections, preventing interception on unencrypted networks
• SameSite attribute — set to Lax, which prevents the cookie from being sent on cross-origin POST requests — a defense against cross-site request forgery (CSRF) attacks
• Automatic expiration — sessions expire after 4 hours of inactivity. Expired sessions are automatically purged from the database on an hourly cycle
• No token persistence — OAuth access tokens received during sign-in are used once for identity verification and then discarded. They are not stored in the session or anywhere else in the system

WATCHDESK runs entirely on Google Cloud Platform (GCP), one of the three major hyperscale cloud providers. Google Cloud's infrastructure is SOC 1/2/3 certified, ISO 27001 certified, and FedRAMP authorized.

Platform Components

Operational Security

• No direct server access — the application runs on a fully managed platform (App Engine). There is no SSH access, no operating system to patch, and no server configuration files exposed
• Automatic scaling — the platform scales instances up and down based on traffic. When idle, it can scale to zero instances, minimizing the attack surface
• Secrets never in code — database passwords, encryption keys, and OAuth credentials are fetched at startup from Secret Manager. They are never committed to source code or stored in configuration files
• Automated backups — the database is automatically backed up by Google Cloud SQL, with point-in-time recovery available

If you have questions about WATCHDESK's security practices, want to discuss specific compliance requirements, or need additional information for your station's evaluation, please contact:

admin@watchdesk.org

For information about what data WATCHDESK collects and how it is used, see our Privacy Statement. For a full overview of platform features, see the Platform Overview.