Data Security

Integrity

Availability

Every piece of data is stored in database clusters that is, at a minimum, triplicated. Event-driven clustered replication, with a replication factor of at least three, ensures two database instances in our cluster can fail and data will still remain available. Being event-driven, any database change is immediately pushed to all instances in the cluster, rather than changes being replicated on a schedule, making sure that even when an instance fails, the full dataset is available on failover instances.

Durability

Each instance of a database is supported with its own storage volume which is snapshotted hourly. These instances are transient, with only the storage volumes persisting. This enables us to destroy database instances without fear of data loss thanks to the cluster replication factors. Vulnerabilities in database applications, operating systems etc can be rapidly addressed without data loss.

Encryption

All data at rest is encrypted using volume-level encryption – storage volumes, object storage, and virtual drives of virtual machines.

For sensitive user data, we use field-level encryption within storage volumes using a per-field multi-part key. These parts are formed from several different locations, including a key management system. Each key is unique to every customer, and every field.

Transport-level encryption is used to secure management communication between the client software and Sophos Central platform via certificates and server validation.

Sophos never stores nor sends users’ passwords in plain text. When a user signs up for an account, this new user must set a password as part of the activation process.

Central Device Encryption

Sophos Central Device Encryption does not store encryption keys but, instead, recovery keys for BitLocker and FileVault-encrypted volumes.

Storing Keys

A recovery key is randomly generated on the Windows/Mac endpoints. This recovery key is obfuscated and sent to Sophos Central via our Management Communication System (MCS) protocol, protected with Transport Layer Security (TLS). Once it has reached Sophos Central, the recovery key is deobfuscated and stored in the relevant storage volume. The recovery key is transparently encrypted using AES, in addition to residing on an encrypted volume. Recovery key metadata is not stored alongside the recovery key.

Accessing Keys

As soon as an admin or user reads a recovery key from the database (such as via the Sophos Central Admin or Self Service Portal), this recovery key is marked as ‘expired’. When the recovery key is used to recover an endpoint, and the endpoint boots and synchronizes with Sophos Central, it is informed the recovery key is expired. The endpoint generates a new recovery key and sends this to Sophos Central as detailed above. Once Sophos Central confirms it has received the new recovery key, the old recovery key is invalidated on the endpoint so that it no longer can be used. This ensures that recovery keys can only be used once. Recovery keys are never deleted in Sophos Central.