As your organization and its trading partners become more and more integrated, it is becoming critical that file transfers are performed without delays or disruptions.

For instance, a document containing a batch of transactions could traditionally be delivered within a window of several hours without causing any issues. But today, in the effort to make business processes as efficient as possible, that same document must now be delivered within seconds.

Organizations are therefore taking a closer look at how they can provide the best high availability for their systems to minimize any potential disruptions to their file transfers.

Comparing High Availability Strategies

Many of the secure file transfers from your trading partners are probably going through an SFTP server in your organization’s network.  If that SFTP server were to go down (for example, due to a CPU or drive failure), then you would need to fail over to a redundant backup system to continue to service your trading partners, thus maintaining high availability.

Two common approaches for providing high availability for SFTP servers and most other applications are Active-Passive or Active-Active.

Active-Passive

With an Active-Passive approach, only one SFTP server will be active at a time to service your trading partners. A backup copy of the SFTP server would exist on your network as a “passive” system, meaning that it is installed and configured, but it is not actively running.

To prepare in the event of a failure of the active SFTP server, it is important that you frequently replicate all settings and configuration files from the active SFTP server to the passive system. If the active SFTP server fails, then the passive SFTP server could be launched and your network configured to point to this new system.

In an Active-Passive configuration, the downtime for your trading partners (when a failure occurs) can be a few seconds or several hours depending on how the passive system is started.

The least efficient and often slowest implementation of an Active-Passive approach is to rely on human intervention to detect the failure and then manually start up the passive system.  This could take several hours depending on when the outage is reported, the process to start the passive system, and the complexities of configuring the network to route traffic to the new system.

A much better approach would be to have a third-party system monitoring tool that would immediately detect when the SFTP server fails, and then would automatically start up the passive system.  The result should be a a much shorter disruption for trading partners of only a few seconds.

Active-Active, or Clustering

The next level in high availability is to use an Active-Active approach, also referred to as “clustering.”

With Active-Active, two or more installations of the SFTP server can be running concurrently, sharing the same set of configurations and trading partner accounts. The SFTP servers in the cluster are in constant communication with each other, so if one of the SFTP servers were to fail, the remaining systems in the cluster will continue to service the trading partners. This configuration will provide the maximum high availability since it is not dependent on human interaction or third-party tools to start up other systems.

If you need maximum up-time for your SFTP server, GoAnywhere Services™ now offers clustering.

Another advantage of an active-active configuration is that you can load balance the traffic over multiple systems, which is important when you need to service a large number of trading partners.  This will require that you install a load balancer like GoAnywhere Gateway™ in front of the cluster.  Typically this load balancer will be in your DMZ and will be your trading partners’ initial point of contact.

The Bottom Line

Both Active-Passive and Active-Active methods provide high availability for your SFTP server environment if configured properly.  However, Active-Active will provide the maximum up-time because it keeps multiple SFTP servers running concurrently in a cluster, along with the added benefit of load-balancing.

How critical up-time is to your bottom line will be the best guide to determining which high availability approach best fits your organization.

Bob Luebbe

Bob Luebbe has worked in the IT field since 1985. During his career, he has worked in a wide variety of roles including software development, project management, consulting and architecting large-scale applications. Bob has been with Linoma Software since 1994 and is currently serving its Chief Architect. His main focus for the last several years has been developing technologies to help organizations to automate and secure their file transfers, as well as to protect data at rest through encryption and key management.

More Posts - Website

Moving files from one computer to another has been essential since the start of computing. Once we were able to connect computers via network protocols and cables, we worked to find ways to send data and files back and forth across the network connections. Thus, FTP was developed specifically for this.  FTP also allowed programmers and system administrators to begin writing scripts to automate transfers based on some event that occurred in software applications.

Of course, once the Internet came along, businesses found more reasons to exchange files with their business partners and an FTP solution became an everyday necessity.

The Problem

Early users of the Internet were universities sharing information that was freely available to the public.  But as businesses began using the Internet, the culture of data security changed.

Sending files to trading partners including confidential transactions and detailed customer information were becoming daily events.  In response, hackers expanded from hacking into computers connected to the Internet to plucking confidential data from the streams now traveling across the public network.

Network firewalls were developed to block hackers from access to individual networks, but the FTP protocol and its problems remained essentially the same.

The Solution

The flaws with standard FTP soon became obvious. To better secure file transfers, more secure protocols such as SFTP, FTPS, HTTPS, and PGP were developed for Internet file transfers. While these protocols allow greater protection for confidential data, many businesses and organizations still lack the understanding and the expertise to properly manage all of the processes that each of these methods involve. Some have turned to free PC-based tools like as Filezilla and CoreFTP, but most organizations that do regular file transfers need a much more robust way to manage these critical processes.

This need trigged the development of what are called “managed file transfer (MFT)” solutions that help IT staffs confidently manage and secure the file transfer process.  In particular, these MFT products make it easy to set up and manage FTP workflows that can be scheduled, automated, and logged with alerts for successful and/or failed connections and transmissions. A flexible MFT solution, like GoAnywhere, will work on most databases and run on multiple platforms.

So from the early days of sending files through rudimentary network connections to the fast-paced Internet driven business processes of today, finding the right FTP solution for your organization is more critical than ever.  Your customers, trading partners and compliance auditors are depending on you.

Bob Luebbe

Bob Luebbe has worked in the IT field since 1985. During his career, he has worked in a wide variety of roles including software development, project management, consulting and architecting large-scale applications. Bob has been with Linoma Software since 1994 and is currently serving its Chief Architect. His main focus for the last several years has been developing technologies to help organizations to automate and secure their file transfers, as well as to protect data at rest through encryption and key management.

More Posts - Website

An increasing number of our customers are looking to move away from standard FTP for transferring data, so we are often asked which secure FTP protocol we recommend. In the next few paragraphs, I will explain what options are available and their main differences.

The two mainstream protocols available for Secure FTP transfers are named SFTP (FTP over SSH) and FTPS (FTP over SSL). Both SFTP and FTPS offer a high level of protection since they implement strong algorithms such as AES and Triple DES to encrypt any data transferred. Both options also support a wide variety of functionality with a broad command set for transferring and working with files. So the most notable differences between SFTP and FTPS is how connections are authenticated and managed.

With SFTP (FTP over SSH), 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. Its important to note that 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 first need to generate a SSH private key and public key beforehand. If you need to connect to a trading partner’s SFTP server, you would send your SSH public key to them, which they will load onto their server and associate with your account. When you connect to their SFTP server, your client software will transmit your public key to the server for authentication. If the keys match, along with any user/password supplied, then the authentication will succeed.

With FTPS (FTP over SSL), a connection is authenticated using a user id, password and certificate(s).  Like SFTP, the users and passwords for FTPS connections will also be encrypted. When connecting to a trading partner’s FTPS server, your FTPS client will first check if 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 if the certificate was self-signed (by your partner) and you have a copy of their public certificate in your trusted key store.

Your partner may also require that you supply a certificate when you connect to them.  Your certificate may be signed off by a 3^rd 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).

In regards to how easy each of the secure FTP protocols are to implement, SFTP is the clear winner since it is very firewall friendly. 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.

In summary, SFTP and FTPS are both very secure with 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.

Bob Luebbe

Bob Luebbe has worked in the IT field since 1985. During his career, he has worked in a wide variety of roles including software development, project management, consulting and architecting large-scale applications. Bob has been with Linoma Software since 1994 and is currently serving its Chief Architect. His main focus for the last several years has been developing technologies to help organizations to automate and secure their file transfers, as well as to protect data at rest through encryption and key management.

More Posts - Website

FTP was designed as an easy mechanism for exchanging files between computers at a time when networks were new and information security was an immature science. In the 1970s, if you wanted to secure a server from unwanted access, you simply locked the computer room door. User access to data was controlled by the basic User ID and password scenario. (Right is a reminder of how much technology has advanced since the 1970s. The photograph,  taken December 11, 1975, is the Apollo Project CSM Simulator Computers and Consoles. Photo Courtesy of NASA.)

The Internet did not yet exist and the personal computer revolution was still a decade away.

Today, the security of business file transfers is of paramount importance. The exchange of business records between computing systems, between enterprises, and even across international borders has become critical to the global economy.

Yet, the original native FTP facility of TCP/IP wasn’t designed for the requirements of the modern, globally connected enterprise. FTP’s basic security mechanisms – the User ID and password — have long ago been outdated by advances in network sleuthing technologies, hackers, malware, and the proliferation of millions of network-attached users.

Risks associated with using native (standard) FTP include:

• Native FTP does not encrypt data.
• A user’s name and password are transferred in clear text when logging on and can therefore be easily recognized.
• The use of FTP scripts or batch files leaves User IDs and passwords in the open, where they can easily be hacked.
• FTP alone, does not meet compliance regulations. (For example: HIPAA, SOX, State Privacy Laws, etc.)
• When using an FTP connection, the transferred data could “stray” to a remote computer and not arrive at their intended destination leaving your data exposed for third parties or hackers to intercept.
• Conventional FTP does not natively maintain a record of file transfers.

The first step is to examine how FTP is being used in your organization. The next step is to identify how your organization needs to manage and secure everyone’s file transfers. The final step is to evaluate what type of Managed File Transfer Product your company needs.

For more information download our White Paper – Beyond FTP: Securing and Managing File Transfers.

Bob Luebbe

Bob Luebbe has worked in the IT field since 1985. During his career, he has worked in a wide variety of roles including software development, project management, consulting and architecting large-scale applications. Bob has been with Linoma Software since 1994 and is currently serving its Chief Architect. His main focus for the last several years has been developing technologies to help organizations to automate and secure their file transfers, as well as to protect data at rest through encryption and key management.

More Posts - Website

Highly sensitive data is frequently exchanged between organizations. For instance, a business will routinely transmit financial information to their bank including payroll direct deposits and ACH payments. These transactions most likely contain sensitive elements like bank account numbers, routing numbers, social security numbers and payment information.

Industry-specific transactions may also contain highly sensitive data. For example, in the health care business, patient records are regularly exchanged between hospitals, doctors and payment providers. In the insurance business, policy information is often transmitted between carriers. This information may contain names, addresses, birth dates, social security numbers and other private information.

Loss of sensitive data can result in great financial expense, lawsuits and public embarrassment for the affected organization. Therefore it is no surprise that industries are setting new regulations and standards to address the security of their data.  For instance:

• PCI DSS requires that credit card numbers are encrypted while “at rest” and “in motion”.  Failure to do so can result in severe fines and potential loss of your merchant account.
• HIPAA requires that healthcare records are secured to protect the privacy of patients.
• State privacy laws require that customers are notified if their personal information may have been lost or stolen. Some states will also assess large fines against organizations if this data is not protected properly.

Organizations should consider compliance requirements and regulations when looking for a Managed File Transfer solution. An effective solution should have a number of encryption methods available to protect sensitive data including SSL, SSH, AES and Open PGP encryption. Audit trails should also be in place to track file transfer activity so you can easily determine what files are being sent, what time they are sent, who the sender and receiver is, and so on. If you are looking for a comprehensive solution be sure to check out our GoAnywhere Managed File Transfer Suite.

Related Blog: PCI DSS v2.0

Bob Luebbe

Bob Luebbe has worked in the IT field since 1985. During his career, he has worked in a wide variety of roles including software development, project management, consulting and architecting large-scale applications. Bob has been with Linoma Software since 1994 and is currently serving its Chief Architect. His main focus for the last several years has been developing technologies to help organizations to automate and secure their file transfers, as well as to protect data at rest through encryption and key management.

More Posts - Website