Encryption in transfer and encryption at rest are equally important aspects of secure encrypted file transfer. They are critical security controls when handling personally identifiable or sensitive data, and not applying them puts your security and compliance at risk. This blog post examines the different options for secure encrypted file transfer.
Secure encrypted file transfer: Encryption in transit
Transfers are generally going to be secured using either SSL (both FTP & HTTP) or SSH. We’re all familiar with SSL and tend to use it to describe both the “Secure Sockets Layer” and “Transport Layer Security” (TLS) cryptographic protocols. Only TLS, however, can still be considered secure encrypted file transfer. SSL is no longer safe to use (In 2016, the PCI Council updated the PCI-DSS standard to exclude all SSL versions plus TLS 1.0 as well). Whilst TLS 1.1 is still considered secure, it’s preferable to only use TLS 1.2, which is considered by some to be “more secure”.
Unfortunately, though, many older computers cannot transfer using TLS. This leaves some organisations with a dilemma. Allow these older insecure protocols or insist that clients upgrade their computers? With the introduction of GDPR, this is no longer an option.
SSL relies on certificates, which need managing and ensuring they are properly signed. It is safe to say that self-signed certificates will not be acceptable from a GDPR perspective.
SFTP (SSH file transfer) is generally considered to be secure and in many cases is preferred to SSL because it only requires one firewall port to be opened. SSH public keys should be exchanged between the client and server in advance of use, to ensure that the correct keys are accepted.
In either case, regardless of which protocol you decide to employ, you will also need to be aware of ciphers and algorithms. In the same way that some cryptographic protocols are considered insecure, some ciphers and algorithms are too. For example, for SSL you would disable DES and RC4 and for SSH you would disable arcfour. Your data protection officer should be able to tell you the full list of which ciphers to disable.
Another important point to consider is whether you need to play the client or server role. In other words, will you transfer the files, or provide a secure location for people to exchange files. As a client, you are somewhat at the mercy of the server owner who will dictate which protocols may be used. Conversely, as the server owner, you need to ensure that either the software that you select supports a broad variety of clients, or else distribute client software to your trading partners.
Secure encrypted file transfer: Encryption at rest
The level of risk surrounding your data will vary, depending upon where in a network it is resting in its transfer process. It’s fairly safe to assume though that any data that’s potentially internet-facing (and therefore at greater risk) will need to be encrypted. So how do we achieve this? Protocols used in secure encrypted file transfer (SSH and SSL) address the transfer itself, but not before or after the transfer takes place. Three distinct methods to manage encryption at rest spring to mind. Each of these measures help protect data at rest and they can all be combined to give a high level of protection. These methods can assist in meeting regulatory compliance such as PCI DSS, ISO 27001, etc.
This method relies upon the File Transfer application itself to perform the encryption. The list of acceptable encryption functions changes periodically, but it will generally use symmetric key encryption; either the AES (128, 192 or 256 bit) or TDEA (3DES; 56, 112 or 168 bits) algorithms. Symmetric algorithms use a key to first encrypt the data for storage and then decrypt it again afterward when it’s needed. The key is held inside the File Transfer software, ensuring the data is only ever accessed through the application. As a rule of thumb, the longer the length of the key, the more secure the encryption (just like with a password).
Filesystem level encryption
Using this method, the entire filesystem is encrypted, often using an Operating system level function. The most commonly used example is BitLocker from Microsoft.
Bitlocker uses AES128 or AES256 algorithms for encrypting the data stored on the file transfer server. The wide availability of Bitlocker though, means it’s more frequently targeted by hackers than an application-specific encryption method and therefore is more exposed to attack.