Most companies have a policy that requires them to revoke access to company data when an employee leaves the company. It is common for the IT department to disable the former employee’s account in Active Directory, revoke their access to the corporate VPN, and request that the employee return their work-issued devices. This approach works well when employees are on-site. However, when employees are working remotely, enforcing this policy becomes more difficult.
One particular challenge is ensuring that remote employees cannot access files that have been previously downloaded to their devices. This issue is not limited to remote employees. This same problem applies to other use cases, such as controlling when a third party contractor can view files or revoking access to data from cloud providers.
In general, enterprises need to control access to their resources (i.e., files, intellectual property, data, etc.), even when the resources are not physically in their possession. Most enterprise Identity & Access Management (IAM) systems provide a solid level of security for resources available over the network (e.g., email exchange server, web applications, file servers, etc.), but do very little to manage, monitor, and restrict access to resources that have already been downloaded to users’ devices. In the era of work-from-home and bring-your-own-device policies, this presents serious challenges for the enterprise. Locally-stored files aren’t visible to security leaders. They can also be easily copied and transferred to unmanaged devices that may be vulnerable, heightening the risk of data breaches and insider threats.
This post describes a solution to this problem that works transparently in the background, supports the most common use cases and tools, doesn’t require end-user training, and integrates with existing identity systems and providers.
Solution Overview
A naive solution to this problem is to put some kind of agent on every device that checks the user’s permissions against a remote server when the user attempts to access a file. Solutions like this are just obfuscation, as the enforcement of the access control is done locally on the device. A better approach is to ensure that the data remains encrypted by default and is only decrypted when accessed under valid conditions.
Of course, if the decryption keys are also stored locally on the system, then this solution would not provide much security. Instead of storing the keys locally, the decryption keys should be centrally managed by the enterprise in a key management system (typically backed by a set of hardware security modules). When an encrypted resource is accessed on a remote device, i.e. when a user attempts to open a file, the content is decrypted using the remote key. If the user is not allowed to access the key— for instance, if the user is no longer employed by the company— then the resource will not be decrypted, thereby restricting access to the resource via cryptographic access controls.
Enforcing Additional Security Controls
With the right key management system deployed, the enterprise can set policy on a per-user or per-key basis. This includes the option to enforce security controls like multi-factor authentication, device authentication, approval workflows, notifications, and more.
Each set of data has its own security level. Some documents may only require device authentication policies, while other, more sensitive documents, may call for multi-factor authentication and approval from a quorum of approvers before access is granted. If any of the approvers reject the request, the end-user will not be able to view the resource. Notifications can also be activated so that administrators receive a message via email or other messaging system anytime that a particular key is used.
Additionally, the enterprise can choose to leave some decryption keys in a disabled state until it’s necessary for an authorized end-user to use them. Known as Just-In-Time Access, this security policy is ideal for resources that only need to be accessed at certain times.
Enterprise Integration
Security solutions are only useful if they integrate with existing business functions. In this case, that means that the encryption must integrate seamlessly with standard tools. Thankfully, this is possible for the most common use cases.
Email can be encrypted via S/MIME or PGP, PDF files support certificate-based encryption, and general purpose files can be encrypted using encrypted file systems such as Windows EFS or Veracrypt. In all cases, the master decryption key can be stored externally in the enterprise’s key management system, all without affecting how the end user’s tools function.
Frequently Asked Questions
Q: Isn’t decrypting files with remotely managed keys slow?
A: It would be if you had to send the entire file over the network for decryption. However, a better approach (which most tools use by default) is to use enveloped encryption. Using this approach, only the encrypted data encryption key is sent over the network, instead of the entire file. The result is that the data sent over the network is always minimal, even if the file to decrypt is very large.
Q: How can this technique be applied to cloud providers?
A: Similarly to encrypting files stored on remote employees’ devices, you can also encrypt data stored in the cloud using keys that are managed by the enterprise. By revoking (or not granting) access to the decryption keys to the cloud provider, they don’t have access to the data. Some cloud providers offer this solution natively. For example, Azure’s Double Key Encryption and Google’s External KMS.
Q: How does this solution help a company comply with e-Discovery laws?
A: By centrally managing the decryption keys, the enterprise always maintains the ability to decrypt content and provide it to a legal entity.
Q: Should each user have one key or should there be a key per file?
A: There will always be a data encryption key (DEK) per file. However, the question of how many key encryption keys (KEKs) are needed depends on your environment. While it is possible to have one key per employee, this may not be desirable. For example, files within a particular department may need to be shared. In this case, it could make sense to have a key per department. In reality, some use cases make sense to have a key per user (e.g., email) while others make sense to have one or more keys per department.
If you’re interested in deploying this solution in your enterprise, get in touch with the Garantir team. GaraSign natively supports all the features listed here and more.
