0333 123 1240 info@pro2colgroup.com

Secure encrypted file transfer:

Encryption at rest and in transit

Secure encrypted file transfer:

Encryption at rest and in transit

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.

Application-level encryption
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.

File-level encryption
File-level encryption has been popular for a number of years. It’s frequently used as a method to transfer financial files across the internet. The most common example of this is PGP (Pretty Good Privacy). PGP uses both symmetric AND asymmetric algorithms to ensure encryption (files have a digital signature produced using RSA or DSA algorithms). The great thing about this approach is that it can be combined with either of the other methods to create a very secure file.

Unfortunately, there are many commonly used file transfer applications that don’t use these methods to store their data. Instead, they focus on the security of the actual transfer. An example of this is Microsoft IIS FTP, which has recently been improved to allow FTPS (but not SFTP) transfers. Without protecting the filesystem, an IIS FTP site will without doubt fail a GDPR audit. Similarly, many open source ftp platforms or older versions of established FTP applications are at risk in the same way.

Managed file transfer (MFT) solutions provide several ways to protect data. In addition to using secure protocols for data in transit and the protection against DDos, Hammering and Brute Force attacks, many solutions provide mechanisms for securing files at rest, while they are awaiting collection or processing. Our free, independent managed file transfer comparison service will help you identify the right solution for your secure encrypted file transfer requirements. You answer a series of questions, which will be reviewed by independent experts who have been specialising in this technology since 2004. They will recommend the best product for your requirements and budget, saving you huge amounts of time spent researching multiple vendors. This takes the risk our of choosing your secure encrypted file transfer infrastructure.

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.

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.

Application-level encryption
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.

File-level encryption
File-level encryption has been popular for a number of years. It’s frequently used as a method to transfer financial files across the internet. The most common example of this is PGP (Pretty Good Privacy). PGP uses both symmetric AND asymmetric algorithms to ensure encryption (files have a digital signature produced using RSA or DSA algorithms). The great thing about this approach is that it can be combined with either of the other methods to create a very secure file.

Unfortunately, there are many commonly used file transfer applications that don’t use these methods to store their data. Instead, they focus on the security of the actual transfer. An example of this is Microsoft IIS FTP, which has recently been improved to allow FTPS (but not SFTP) transfers. Without protecting the filesystem, an IIS FTP site will without doubt fail a GDPR audit. Similarly, many open source ftp platforms or older versions of established FTP applications are at risk in the same way.

Managed file transfer (MFT) solutions provide several ways to protect data. In addition to using secure protocols for data in transit and the protection against DDos, Hammering and Brute Force attacks, many solutions provide mechanisms for securing files at rest, while they are awaiting collection or processing. Our free, independent managed file transfer comparison service will help you identify the right solution for your secure encrypted file transfer requirements. You answer a series of questions, which will be reviewed by independent experts who have been specialising in this technology since 2004. They will recommend the best product for your requirements and budget, saving you huge amounts of time spent researching multiple vendors. This takes the risk our of choosing your secure encrypted file transfer infrastructure.

[^s@]
[^s@]
[ 'me', 'mac', 'icloud', 'gmail', 'googlemail', 'hotmail', 'live', 'msn', 'outlook', 'yahoo', 'ymail', 'aol', ]
[ 'me', 'mac', 'icloud', 'gmail', 'googlemail', 'hotmail', 'live', 'msn', 'outlook', 'yahoo', 'ymail', 'aol', ]
[a-z]
[a-z]
[i]
[i]