Organizations must rethink how file transfers are secured and controlled within the organization.

Every day, millions of files are transmitted around the world by corporations, government, and other organizations. These electronic transfers include the critical data needed to conduct business, such as customer and order information, EDI documents, financial data, payment information, as well as employee and healthcare information.

File Transfer Protocol (FTP) has been used for decades to transmit vital information, but this popular protocol has serious security risks that should not be ignored.

History of FTP

When FTP was introduced in the '70s, the public Internet did not exist and information security was an immature science. FTP was initially used within private networks or over dedicated lines to trading partners, so it was considered a relatively safe way to move files.

Over the last several years, most organizations have migrated a bulk of their file transfers to the public Internet to take advantage of its cheap bandwidth. But even though the Internet is much more vulnerable to attacks than private lines, many have continued to use FTP because it's familiar and embedded within their legacy applications.

The FTP specifications have retained their basic structure and functionality over the decades. And because it has not evolved, FTP is a protocol that is rife with security exposures and management issues for the modern enterprise.

Figure 1: Standard FTP is vulnerable to attacks.

Everything that flows over a standard FTP connection is in "the clear," meaning that a would-be attacker can simply sit on the network or router and watch all of the user IDs, passwords, and data that are transmitted over the FTP connection. The attacker can not only capture this information easily with readily available "packet sniffing" tools, but also manipulate this data since FTP does nothing to protect its integrity.

FTP Costs and Compliance Issues

A loss of sensitive data can be very expensive for your organization. Besides the direct costs associated with an exposure, your organization can lose goodwill and trust from your customers if you cannot properly protect their information. Depending on the extent of the FTP breach, the combination of direct and indirect costs (due to lost business) could easily reach millions of dollars.

Organizations should look for alternatives to unsecure FTP to also get in compliance with data security regulations such as PCI DSS, HIPAA, and state privacy laws. Many of these regulations require that sensitive data is encrypted if it's transmitted over the Internet, which standard FTP does not offer.

Non-compliance can result in significant fines and penalties for organizations. For instance, an organization could lose its ability to accept credit card payments if it does not comply with PCI DSS requirements.

With the competitive global marketplace and increased scrutiny, companies simply cannot afford the risks associated with using standard unsecure FTP.

Secure FTP

One of the best solutions for protecting your FTP transmissions is to upgrade to "Secure FTP" encryption technology. The two mainstream protocols available for Secure FTP transfers are SFTP (meaning FTP over SSH) and FTPS (meaning FTP over SSL). 

Both SFTP and FTPS offer a high level of protection because they create encrypted tunnels between your system and your trading partners. In essence, anything that flows over those tunnels will be encrypted, including any files, user IDs, passwords, and commands.

Both SFTP and FTPS support a wide variety of functionality with a broad command set for transferring and working with files. The most notable difference between SFTP and FTPS is how connections are authenticated and managed.

SFTP

With SFTP, a connection can be authenticated using a couple different techniques. For basic authentication, you (or your trading partner) may just require a user ID and password to connect to the SFTP server. Remember, any user IDs and passwords supplied over the SFTP connection will be encrypted, which is a big advantage over standard FTP.

SSH keys can also be used to authenticate SFTP connections in addition to, or instead of, passwords. With key-based authentication, you will need to generate the SSH private key and public key beforehand. If you need to connect to a trading partner's SFTP server, you send your SSH public key to them, which they will load onto their server and associate with your account. 

Figure 2: SFTP provides an encrypted tunnel and key authentication.

When you connect to your partner's SFTP server, your client software will transmit your public key to the server for authentication. If the keys match, along with any user ID/password supplied, then the authentication will succeed.

FTPS

With FTPS, a connection is authenticated using a user ID, password, and certificate(s). As with SFTP, the user IDs and passwords for FTPS connections will be encrypted. When connecting to a trading partner's FTPS server, your FTPS client will first check whether the server's certificate is trusted. 

The certificate is considered trusted if either the certificate was signed off by a known Certificate Authority (CA), like Verisign, or the certificate was self-signed (by your partner) and you have a copy of their public certificate in your trusted key store.

Figure 3: FTPS alternatively provides certificate-based authentication.

Your partner may also require that you supply a certificate when you connect to them. Your certificate may be signed off by a third-party CA, or your partner may allow you to just self-sign your certificate, as long as you send them the public portion of your certificate beforehand (which they will load in their trusted key store).

SFTP or FTPS: Which to Choose?

SFTP only needs a single port number (default of 22) to be opened through the firewall. This port will be used for all SFTP communications, including the initial authentication, any commands issued, as well as any data transferred.

On the other hand, FTPS can be very difficult to patch through a tightly secured firewall since FTPS uses multiple port numbers. The initial port number (default of 21) is used for authentication and passing any commands. However, every time a file transfer request (get, put) or directory listing request is made, another port number needs to be opened. You and your trading partners will therefore have to open a range of ports in your firewalls to allow for FTPS connections, which can be a security risk for your network.

SFTP and FTPS are both very secure, providing strong authentication options. However, since SFTP is much easier to port through firewalls, and we are seeing an increasing percentage of trading partners adopting SFTP, I believe SFTP is the clear winner for your secure FTP needs.

Moving Away from Unsecure FTP

The first step of moving away from standard FTP is to investigate how it is being used in your organization. For instance:

• What kinds of data do you send or retrieve over FTP?
• Where do the FTP client applications reside?
• Where are FTP scripts being used?

The answers to these and other questions will help you understand the breadth of the security problems facing your organization with FTP.

Network monitoring tools can find unsecure FTP traffic that is flowing within and out of your organization. These tools will track the FTP origination to a source IP address in your network. From there, you will have to do more investigation to find the actual FTP scripts or tools.

A more drastic approach is to block FTP traffic at the firewall level and then wait and "see what happens." While this will solve the FTP security issue, your trading partners may not get their files, and business operations may be disrupted. Blocking FTP traffic should be implemented only after you believe all existing FTP scripts and tools have been converted to alternative secure approaches.

Implementing Secure FTP on IBM i

Secure FTP can be implemented on IBM i by using either free utilities or a third-party commercial product.

If you want to go with the free approach for FTPS, you can import your trading partner's public certificate and start the FTP connection with the SECCNN keywords of *SSL or *IMPLICIT. You can then continue to use existing FTP scripts over the SSL connection. Note that additional ports will probably have to be opened in the firewall for the FTPS control and data channels.

For the free SFTP implementation, you will need to use IBM's OpenSSH utilities and PASE to create the SSH keys and perform the SFTP transfers. There are quite a number of cryptic steps to get everything set up initially, and these steps must be followed precisely for the SFTP connection to work. You will also have to create new programs to automate any transfers because SFTP will not recognize your current FTP scripts.

When using the free Secure FTP utilities, you will also have to do programming to trap for errors and to generate alerts when problems arise. This is very important: you don't want to have to wait for your trading partner to call and tell you that they did not receive the file.

It is generally easier to use a commercial solution to set up Secure FTP on the IBM i since programming is usually not required to set up the transfers. Commercial products also provide advanced features like auto-resume and packet integrity checks to help guarantee delivery. They have built-in alerts that can be sent by email or system messages when transfers fail. Commercial products also provide integrated audit trails and reporting to meet strict compliance requirements like those of PCI DSS.

Other Options to Secure FTP

There are several other alternatives to the SFTP and FTPS protocols, including these:

• AS2
• HTTPS
• Open PGP
• ZIP with AES encryption

While these are all viable approaches for protecting sensitive data, they are not as easy to implement as Secure FTP on the IBM i, unless you are using a commercial solution.

The secure protocol that you use will be dependent on your trading partner's capabilities. For instance, most banks and financial institutions support SFTP for secure transmissions but may not support FTPS. And if you are in manufacturing or distribution, many retailers (e.g., Walmart) require AS2 protocol for transmitting orders securely.

The Next Level: Managed File Transfer (MFT)

Typically, standalone FTP tools and scripts are scattered throughout the organization. End users will use PC tools like Filezilla to perform manual FTP transfers, the network team is using Windows and Linux shell FTP scripts, and the IBM i team has built their own CL-based FTP scripts.

This decentralization of file transfers has made it very difficult to control and track the movement of files that are leaving the organization. Compliance and auditing requirements are forcing organizations to rethink their file transfer strategy.

The solution that is gaining popularity is called Managed File Transfer (MFT), which centralizes all file transfers under one umbrella. MFT solutions provide support for a wide range of secure standards, including SFTP, FTPS, SCP, Open PGP, AS2, and ZIP with AES encryption. Transfers can be scheduled or can be triggered by the presence of a file in MFT solutions.

Figure 4: Managed File Transfer offers centralized control and auditing.

MFT solutions were built not only to simplify and centralize file transfers, but also to help companies report on where files are being transferred and by whom for compliance purposes.

Controlling the FTP Exposure

As a file transfer mechanism, FTP has had a long history. But the inherently weak security of its basic design has left organizations with serious security hazards. IT must therefore bring their file transfers into compliance by using secure protocols like SFTP and FTPS.

Finally, organizations must rethink how file transfers are controlled within the organization. They should consider a Managed File Transfer solution to accommodate their growing trading partner base, while centralizing these file transfers under "one pane of glass" for compliance and reporting.

Bob Luebbe is Chief Architect at Linoma Software (www.linomasoftware.com) and has spent nearly 30 years in IT with the last decade focused on developing encryption technologies and managed file transfer solutions. Bob also consults with organizations on achieving regulatory compliance in data protection.

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility