In the beginning, there was the granddaddy of protocols, called FTP, and it was a great way to transfer data from one place to another. After awhile, it became more and more burdensome to juggle all the destinations, transfer methods, usernames and passwords. The whole affair started to strangle itself when trying to update batch scripts with new passwords, changed IP addresses and firewall restrictions, not to mention the security risk of coding your passwords in an easily accessible text file.
Something needed to be done and the solution was MFT (managed file transfer) software. MFT software offered a single place where you could define all your connections, usernames and passwords on a central server controlling all the data being sent and received from your internal network.
Meanwhile, all was not good for FTP. While it was getting easier to manage the connections, there was still a big security hole where the data could be intercepted and accessed by others. To enhance security, three new extensions were created—SFTP (Secure Shell FTP), FTP-S (FTP Secure) and S-FTP (Secure FTP)—all of which provided improved security for data being transferred, but at the expense of interoperability. All three protocols are not interoperable with each other and need to be explicitly defined and used. So even though plain FTP was enhanced with updated security, and is still very fast, it is viewed by some as a less-than-desirable file transfer protocol.
As a result, new protocols were developed that could take advantage of enhanced security, guaranteed delivery and non-repudiation of the sending and receipt of data. Enter the AS (Applicability Standard) protocols. These were designed to alleviate the problems with plain FTP and guarantee interoperability between different software providers. The first of them, AS1, was designed to be used with existing email servers. This new standard introduced encryption of data and the ability for each side of the connection to know if the files were received, and received unaltered. This was accomplished by introducing an acknowledgement message known as an MDN (Message Disposition Notification). The first system would request that an MDN be sent by the receiving system when it processed the file. This would let the first system “know” that the file was received correctly, or even incorrectly if there was a problem with the file.
The basic problem with AS1 is the inherent limit of email in the size of the file being transferred. To address this problem, the next standard, AS2, was developed. Instead of using an intermediate server, AS2 was designed to talk directly to the receiving system using HTTP (Hyper Text Transfer Protocol). This allowed the data files to be magnitudes greater than could be achieved via AS1. In addition, enhanced security could be introduced using SSL (Secure Sockets Layer) that would further encrypt the data in transit, along with synchronous return of the MDN. It requires that servers be running constantly, however, otherwise the sending system would not be able to connect to transfer the data. Another significant problem is if the connection dropped while in the midst of a large file transfer, the the whole file would need to be resent. AS2 has been refined to allow a restart after a failed transfer without sending the entire data file.
AS3 picks up where AS2 left off. AS3 uses the same underlying FTP structure but enhances it with the same features as the other AS protocols, thereby making it a great choice for large file transfers. While it has been a defined standard for quite some time, AS3 has not had the take up of either AS1 or AS2 and is relatively unused.
The last AS protocol to be defined is AS4, which is a secure document exchange format utilizing web services. This allows companies using ebXML formats to exchange data in more direct format between applications, and allows the use of those same benefits of AS2 but for the web services protocol. This is another protocol that is in its infancy and has not had a wide acceptance as yet. In fact, the AS2 protocol is probably the most widely used protocol in the MFT space.
So, where does that leave you, the reader, in picking the protocol to use? For me, the AS2 protocol is easy-to-use and provides a good mix of availability, speed and security, and is easy to implement and maintain. However, we have seen many requests recently for the secure FTP protocols, especially for companies needing to comply with security audits.
As with most MFT-related issues, though, the best place to start is by understanding your data flows and deploying those secure protocols that are best-suited for your business. We can help in that regard. Please contact us at info@btrade.com to speak with our experts in data security and MFT. Also, feel free to post a comment with your thoughts about the secure transfer protocols.