NCSC Cloud Security Alignment

OFFICIAL Threat Tier — POPS Notebook

1. Scope & Classification

This report maps POPS Notebook's authentication flow, zero-knowledge encryption model, and session termination protocols against the NCSC Cloud Security Principles for handling data at the OFFICIAL threat tier.

The platform processes operational reference data, officer profiles, and command broadcasts for UK Public Order and Public Safety officers. No data is classified above OFFICIAL. The application compensates for the absence of IP restrictions and MDM certificates through the controls documented below.

2. NCSC Cloud Security Principles Mapping

P1. Data in transit protection

Met

All client-server communication uses HTTPS/TLS (enforced by the hosting platform). Sensitive payloads (officer profiles, command broadcasts) are additionally encrypted client-side with AES-GCM-256 before transmission, providing end-to-end encryption that is independent of the TLS layer. Even if TLS were compromised or terminated at an intermediary, the payload remains encrypted.

P2. Asset protection and resilience

Met (compensated)

Data at rest in the cloud database exists only as ciphertext (EncryptedBlob fields). The server does not possess decryption keys — keys are derived client-side via PBKDF2 from values (HomeForceHash +ForceSalt) that are themselves insufficient to reconstruct the key without the officer's device performing the derivation. Per-force salts prevent cross-force rainbow table attacks against stored hashes.

P3. Separation between users

Met

Cross-force isolation is enforced at three independent layers: (1) database-level Row Level Security matching ForceHashagainst HomeForceHash, (2) per-force encryption keys that make cross-force decryption impossible, and (3) server-side salted-hash comparison in backend functions. Standard users can only read/update their own records. Force admins are scoped to their own force's data.

P4. Governance framework

Met

Force admins manage feature toggles, guidance text, callsign directories, and user roles within their force. App-level admins manage force license creation and global settings. All administrative actions are logged to theForceAdminAudit table with per-force hash isolation, enabling post-hoc forensic review.

P5. Operational security

Met

The platform enforces a backend kill-switch: theIsSuspended flag is checked server-side on every API call (verifyWorkOTP, requestWorkVerification, checkForceAccess, relayForceBroadcast). Suspended access attempts are logged for forensic review. Operational data is subject to a configurable TTL in local cache (default 24 hours, reducible per force), after which it is automatically purged.

P6. Personnel security

Met (compensated)

Officers undergo work email verification against a whitelist of all legitimate UK police force domains (43 territorial + national forces). Verification requires OTP delivery to the force-issued email, with strict single-@parsing to prevent domain spoofing. Re-verification is enforced every 6 months. The zero-knowledge model complements existing MDM and enterprise infrastructure: rather than relying solely on device-level controls, the platform ensures that device compromise does not expose plaintext data. This extends your M365 and MDM investment into connectivity-denied operational environments without creating additional attack surface. A per-deployment PIN gate provides offline protection against device seizure scenarios where MDM reach is unavailable.

P7. Secure development

Met

The application follows least-privilege principles: backend functions verify caller identity and force membership before every data operation. Server-side identity is used for broadcast sender metadata (never client-supplied). Stripe webhook handlers verify line items against metadata to prevent privilege escalation. Rate limiting is applied to public checkout endpoints (by IP) and to broadcast, tactical update and stand-down submission endpoints (per user). Backend functions return generic error messages to the client — diagnostic detail stays in server logs.

P8. Supply chain security

Met

The platform uses the Base44 BaaS infrastructure for hosting, authentication, and database services. Third-party dependencies are limited to audited npm packages. Stripe is used for payment processing via their PCI-DSS compliant API. SendGrid is used for OTP email delivery. No unvetted external services process plaintext operational data.

P9. Secure user management

Met

User provisioning is invite-based or self-service with mandatory work email verification. Force admins can suspend officer accounts, which triggers immediate server-side denial, local data purge, and session termination. Account deletion is supported via a dedicated backend function. Audit logs record all administrative user actions.

P10. Identity and authentication

Met

Authentication uses the platform's managed auth (email/password with OTP verification, Google OAuth). Session tokens are validated server-side on every request. The configurable suspension polling interval (default 5 minutes) ensures that revoked access is enforced within minutes, not hours. OTP brute-force is limited to 5 attempts before invalidation.

P11. External interface protection

Met

All external interfaces are backend functions that perform authentication, authorisation, and suspension checks before processing. Public endpoints (registration checkout) are rate-limited by IP. Force admin endpoints verify force membership via salted-hash comparison. No raw database access is exposed to the client.

P12. Secure service administration

Met

Admin access is role-gated (app admin vs force admin). Force admins are restricted to their own force's data via server-side filtering. Admins cannot self-reactivate a suspended force — only app admins can restore to 'live'. GoLiveDate modification is restricted to app admins to prevent grandfathering bypass. Admin consoles sign out after 10 minutes of inactivity. All admin actions are audited.

P13. Audit information for users

Met

The ForceAdminAudit table records all administrative actions — including Secure Stand-Down initiation and encrypted data retrieval (session ID and blob count, never content) — with timestamps, admin identity (Username, not PII email), and per-force hash. Force admins can export a comprehensive CSV audit report covering the last 12 months, including user directory, license status, and data sovereignty metrics.

P14. Secure use of the service

Met

Officers are presented with a mandatory Acceptable Use Policy before registration. Operational data is subject to a configurable local TTL (default 24 hours). A per-deployment PIN gate provides a soft deterrent against device seizure in Faraday bag scenarios — three failed attempts trigger an automatic local data wipe (see Security Brief Section 12 for its threat model). Device integrity checks gate access on login, blocking rooted, jailbroken, or automated browser environments. The screenshot guard prevents unauthorised screen capture. Night-vision and training modes are available for operational safety. The burn protocol automatically purges expired local data.

3. Data in Transit Protection

Transport layer: All HTTP communication uses HTTPS/TLS 1.2+ as enforced by the hosting platform. No plaintext HTTP endpoints are exposed.

Application layer (end-to-end): Sensitive payloads (officer profiles, command broadcasts) are encrypted with AES-GCM-256 on the officer's device beforethe HTTPS request is made. The server receives and stores only the ciphertext blob. This means:

  • TLS compromise at any intermediary does not expose plaintext.
  • Database breach exposes only ciphertext with no server-side decryption keys.
  • Server-side code cannot read the data it stores (zero-knowledge).

Key exchange: No explicit key exchange is needed — both sender and receiver independently derive the same AES key from their sharedHomeForceHash and the force'sForceSalt. TheForceSalt is retrieved from the server (it is not secret — it only prevents pre-computation attacks), whileHomeForceHash is computed locally from the officer's verified force domain and never transmitted.

4. Data at Rest Protection

Cloud database: The following sensitive fields are stored as ciphertext only:

  • EncryptedOfficerProfile.EncryptedBlob — AES-GCM-256 ciphertext of officer PII.
  • ForceBroadcast.EncryptedBlob — AES-GCM-256 ciphertext of command messages.

Hashed identifiers (not reversible):

  • User.HomeForceHash — SHA-256(force domain + ForceSalt).
  • User.WorkEmailHash — SHA-256(work email + ForceSalt).
  • ForceLicense.ForceHash — SHA-256(force domain + ForceSalt), used for RLS matching.

Device storage: Operational data is encrypted with a per-session AES key stored in sessionStorage. localStorage contains only ciphertext. Both are purged on suspension, logout, or 24-hour TTL expiry.

5. Authentication Flow

The authentication and verification flow operates in distinct stages:

  1. Registration: User creates an account (email/password or Google OAuth). Account is unverified — no operational access.
  2. Acceptable Use Policy: Mandatory AUP acceptance before proceeding.
  3. Work verification request: User submits a .police.uk email. The server validates the domain against a whitelist of all UK police forces, checks for exactly one @ symbol, and generates a 6-digit OTP.
  4. OTP delivery: The OTP is sent via SendGrid to the verified work email. The OTP is stored as a temporary field on the User entity with a 15-minute expiry.
  5. OTP verification: User submits the code. The server validates against the stored OTP (max 5 attempts). On success, IsWorkVerified is set, VerifiedAt timestamp is recorded, and all OTP fields are cleared.
  6. Force affiliation: The user's HomeForceHash is computed from the force domain + ForceSalt and stored. This hash determines all subsequent data access.
  7. Re-verification: Every 6 months, the VerifiedAt timestamp triggers a re-verification requirement.

6. Session Termination Protocols

Active polling: The auth context pollsIsSuspended every 5 minutes. If the flag is true, the application immediately:

  • Purges all pops_-prefixed keys from localStorage (ciphertext).
  • Purges all pops_-prefixed keys from sessionStorage (decryption keys).
  • Clears the authentication token.
  • Hard-redirects to a suspension notice page directing the officer to contact their Force Admin.

Backend enforcement: All backend functions independently checkIsSuspended at the start of every request. Even if a client-side token remains valid, suspended users receive a 403 error and the access attempt is logged toForceAdminAudit. This server-side check cannot be bypassed by client-side manipulation.

Token invalidation: The suspension clears the auth token, preventing further API calls. The 5-minute polling interval bounds the window during which a suspended user could continue using a stale session.

Voluntary logout: On explicit logout, the auth token is cleared and the user is redirected to the login page. SessionStorage keys are not explicitly cleared on voluntary logout (they are wiped on tab close), but the loss of the auth token prevents further data retrieval.

7. OFFICIAL Tier Considerations & Residual Risks

The platform is assessed as suitable for handling OFFICIAL data, with the following notes:

  • Zero-Trust Tactical Edge Extension: The platform extends enterprise IT into operational environments where IP restrictions and VPN tunnels cannot reach. Rather than replacing these controls, POPS Notebook operates as a zero-trust edge module that maintains security posture independently of network-level infrastructure. An attacker with network access cannot decrypt intercepted data without the PBKDF2-derived key.
  • MDM Complement: The platform complements existing MDM deployments rather than replacing them. The backend kill-switch, configurable local data TTL (default 24 hours), and per-deployment PIN gate ensure that a compromised device loses access within the configurable suspension polling interval (default 5 minutes) of suspension — even if the device is placed in a Faraday bag and MDM reach is unavailable.
  • Key derivation on device: The AES key is derived in the browser's Web Crypto API, which is non-extractable. However, a compromised device with a controlled browser environment could theoretically capture the derived key in memory. This is mitigated by the session-based key lifecycle and the 5-minute suspension polling.
  • ForceSalt is non-secret: The ForceSaltis returned to authenticated officers (needed for key derivation). It is not a secret — its purpose is to prevent pre-computed rainbow tables, not to serve as a password.

Recommendation: For deployments handling data approaching OFFICIAL-SENSITIVE, the suspension polling interval can be reduced to 60 seconds and the local data TTL reduced to 4 hours. These parameters are configurable per force by POPS Notebook administrators. To discuss enhanced security configurations for your force, contactforces@popsnotebook.co.uk.