Top Tip #15 takes you through encrypting data at rest in EFT using the High Security Module (HSM) or PGP. This article references GDPR requirements and is written by our EFT expert Mark Allen.
Did you know that 200 million personally identifiable records of voters in the US were leaked earlier this year? The data was on an unsecured Amazon S3 storage pool. This brings home the importance of securing your data ‘at rest’ as well as in transit.
Not doing so risks your organisation’s GDPR compliance too. Article 32 says you need “a level of security appropriate to the risk” for all data processing activities, which includes data storage (Article 4). So let’s take a look at how to encrypt data at rest using the High Security Module (HSM) or PGP and what you need to watch out for.
Encrypting data using the High Security Module (HSM) is the most straightforward and secure method for EFT users. Any file written to a specified folder is automatically and transparently protected without needing to resort to a third party encryption method, such as PGP. This is achieved using Windows EFS and can encrypt an entire folder structure or a single directory. Any file written to an encrypted folder is automatically encrypted and never written anywhere in an unencrypted state.
Other advantages of this method are that you don’t need event rules to trigger the encryption process. There are no issues with the file being deleted either, as it is never stored unencrypted.
Please be aware though that if you access the file storage directly, it only presents the encrypted files. This means you may not be able to access the files directly and any files you may write to the folder may not be visible to EFT. In order to save or retrieve the files, you need to “upload” or “download” them from the server using EFT.
Encrypting data at rest using PGP is a bit more complicated. You can use the PGP action of an event rule to automatically encrypt uploaded files once they have finished being written. This is done by “streaming” the data from the unencrypted file into the encrypted file. Once this has taken place, EFT will automatically delete the original file.
While this process is good enough for many organisations, there are two drawbacks that you need to be aware of.
Firstly, there’s a short but finite period of time when the file sits unencrypted on the file system while it’s being encrypted. While this isn’t usually a problem (it usually takes seconds) there is the risk that the encryption takes longer or the event rule fails to trigger. If this was to happen, your data sits at rest in the file system unencrypted.
The second drawback is that EFT by default uses a standard Windows delete to remove the unencrypted file from the storage. Utilities could be used to recover this unencrypted file directly from the storage. You could use the High Security Module to ensure the deleted file is “wiped” with pseudo-random data, which would ensure the file is not recoverable in a useable state after deletion. If you had the High Security Module though, you’d be better off using the more secure option 1 anyway.
Considering all these factors, I’d recommend anyone using EFT to transfer sensitive or personally identifiable data should be using the High Security Module. If you’d like to find out more, download the data sheet. You can also find out other ways GDPR impacts your data transfer and file sharing processes and systems by downloading our White Paper.