Chapter 4: Full-spectrum data protection measures
Encryption
Earlier in the book, we briefly discussed encryption and its importance in IT security. In this section, we'll take examine the different types of data we encrypt and how we encrypt them.
We have a dedicated Key Management Service (KMS) to create, store, and manage encryption keys across our offerings. We typically use two types of keys: encryption keys and master keys.
We encrypt data using encryption keys and further encrypt the encryption keys using a master key. We store the encryption keys in the KMS server and the master key in a separate server. Furthermore, our security engineering team periodically rotates the master key. The physical isolation and rotation of the master key ensures we can retrieve data even if the encryption keys are compromised.
Let's take a look at the different types of data and how we encrypt them.
| Data encrypted | How we encrypt them |
|---|---|
|
Database (DB) |
We encrypt sensitive data in our database using AES 256 standard with AES/CBC/PKCS5 padding mode. The data in the DB is in the form of tables. The level of encryption depends on the sensitivity of the data field and user preferences. We have two levels of DB encryption: Level 1: This default encryption level applies to all organizations. Each org is assigned a key KMS, which encrypts the corresponding data using this key. The encrypted key is then stored separately after encrypting it with a master key. Level 2: This encryption level applies to sensitive and Personally Identifiable Information (PII) such as bank account numbers and identification data. For each column in the table, the KMS generates a unique key. Data within a specific column is encrypted using the corresponding key. These keys are encrypted with a master key and stored separately. We use an initialization vector (IV) as a random value to make encryption unique. This IV ensures that each data block is encrypted differently, even if the same data is encrypted multiple times. This encryption approach provides a strong level of protection for data, with varying levels based on sensitivity and user requirements. |
|
Files |
We store the files in our system in our Distributed File System (DFS), and the encryption of files at rest depends on the services chosen. We utilize AES 256 encryption with either CTR or GCM mode. In AES 256 encryption, the plain text is divided into blocks, ensuring independent encryption of each block. This method prevents the compromise of one block from revealing information about the entire file. For this purpose, we use the CTR mode. Similar to DB encryption, file encryption also has two levels: Level 1: Each organization (Org) is assigned a key, and files from that Org are encrypted using this key. We encrypt each file with a unique random IV and store it alongside the file. The key is encrypted with a master key and stored in KMS. Level 2: Each file is assigned a unique key for encryption. The file is encrypted using this key, and the encrypted key alongside the file in the DFS. The master key, specific to the service or application, encrypts each key used for file encryption. This master key is securely stored and managed in the KMS. By employing these encryption levels and techniques, we ensure the security and confidentiality of files, providing an additional layer of protection. |
|
URLs |
To ensure secure communication, sensitive data in the invitation links or other communication are encrypted within the URLs. Identifiable information, like a document ID in the URL, is also encrypted. The encryption process for URLs happens at one of the two levels: One key per Org or one key per URL. The choice between these levels depends on the sensitivity of the data contained within the URL. |
|
Backup data |
We have two backup schedules: daily and weekly. Our backup servers are as secure as our main servers, and all backup data is encrypted using the AES 256 algorithm. We store the encryption keys in a separate server for added security. Additionally, our redundant Data Centers (DCs) ensure high availability and maintain encrypted copies of your data. These DCs receive the same back up as our main DCs to ensure data resilience. |
Log data |
We use the Hadoop Distributed File System (HDFS) for log storage and management. The data is encrypted using Hadoop Inc.'s encryption technology, and our Key KMS takes care of key management. |
Cache data |
We use open-source software to handle caching of data. The cache comprises frequently accessed information required for service operations and is stored only for a specified duration. Occasionally, we may cache data for service enhancement or troubleshooting purposes. When sensitive personal information is involved, we prioritize encrypting the data. |
How do we manage the encryption keys?
All of our encryption methods adhere to the AES 256 algorithm. This algorithm operates on data blocks for the database fields and files in the DFS. Encryption begins by encrypting a data block with a Data Encryption Key (DEK). The DEK is then encrypted using a Key Encryption Key (KEK). The KEK, in turn, is encrypted using a master key stored on a separate server. To summarize, the elements that require management include the following:
- Encrypted data
- DEK
- Encrypted DEKs
- KEKs
- Encrypted KEKs
- The master key
Here's how the KMS works:
The KMS generates 256-bit keys following the AES 256 protocol with an Initialization Vector (IV) to ensure randomness in encrypted data blocks. The KMS generates the keys and IVs using a secure random number generator in a Java Secure library.
DEKs generated in the KMS are encrypted using a KEK, adding an extra layer of security. We store these encrypted DEKs in the KMS database.
To enhance security, we physically separate the keys, storing them in different locations. This separation prevents an attacker from gaining access to multiple related keys. The KEK is encrypted using a master key and stored on a separate server.
To safeguard the keys, we have implemented the following controls:
Physical separation: The master key is stored in a physically separate and secure server, making it challenging for attackers to compromise the DEKs and the KEKs.
Access control: Access to keys is controlled strictly using an Access Control List (ACL), allowing only selected services to access specific keys. Each key access requires authentication, and we log the entire process for monitoring them through regular audits.
Restricted access: A KMS is restricted by default, granting access only to authorized personnel of Zoho Corp, the parent company of ManageEngine. Any other access requests must go through a ticketing system and receive management approval.
Key rotation: We have a system to rotate the keys such that the master key is periodically changed, enhancing security. When the KMS generates a new master key and IV, all keys in the database are decrypted using the old master key and then re-encrypted using the new master key, updating them in the database.
Availability of keys: In case of a primary storage failure in a DC, a slave and a secondary slave serve as backups, holding the same encrypted DEKs as the master DC.
Encryption in transit
Data encryption during transit is crucial to protect user data from man-in-the-middle attacks as it travels over the internet. Here's how we ensure data encryption in transit:
When data travels from users' browsers to our servers, we enforce Transport Layer Security (TLS) across all connections. TLS provides a secure connection by authenticating both parties involved in the exchange and encrypting the transferred data. This method ensures that communication between users and our servers remains confidential and secure.
We follow the HTTPS protocol when data travels from our servers via integrations to third parties. For transactions involving sensitive data, we employ asymmetric encryption. This encryption method utilizes a pair of public and private keys.
To implement this, we generate a public-private key pair in our KMS, which securely creates, stores, and manages keys across all services. The key pairs are encrypted using a master key and stored within the KMS. The master key is stored securely on a separate server.The public keys are shared with third parties through certificates, while the private key remains securely stored in the KMS. Upon authentication, the encrypted data is decrypted within the KMS using the private key. By adopting these best encryption practices, we ensure that data remains protected throughout the journey from users' browsers to our servers and during communication with third-party integrations.
Data isolation
Over the years, we've crafted a framework that distributes and maintains the cloud space for our customers. Each customer's data is logically separated from other customers' data using a set of secure protocols in the framework. This separation ensures that no customer's service data becomes accessible to another customer.
We have a dedicated team that manages this data isolation framework. The team also provides guidelines on storing and managing data in an application, and our product teams apply these frameworks in their codes.
Protecting the infrastructures that host data
Network security
Our network firewall implements a multi-level approval process for access requests. We follow a ticket-based system to manage or request access to LAN, WAN, WLAN, or VPN networks. These tickets go through at least two levels of review before reaching the network operating center. Based on ticket requirements and usage analysis, our network operations center (NOC) approves or denies the request.
We monitor access and change management tools regularly with a strict schedule. A network engineer reviews any changes made to the firewall trigger via a support ticket. Additionally, a periodic review cycle of three months ensures that rules are regularly revised and updated.
To ensure secure server access, we employ MFA and the Kerberos protocol. This combination provides robust authentication using secret-key cryptography, adding an extra layer of security.
Intrusion detection
Our data centers have dynamic anomaly detection systems. Depending on the Internet Service Provider (ISP), we employ round-the-clock intrusion detection systems or automatic systems that activate when needed.
These systems utilize a multi-layered security approach, incorporating scrubbing, network routing, rate limiting, and filtering techniques. They can handle attacks from network layers to application layer (level-7) attacks. The goal is to ensure clean traffic, reliable proxy service, and prompt reporting of detected attacks.
To learn more about how we manage and protect our data centers and networks, check out our detailed ITOM playbook.