Security & Compliance
Security & Compliance

The Shortcut Guide to Securing Automated File Transfers

by Ed Tittel


The ability to securely transfer files to clients, business partners, and other corporate branches in your enterprise is an absolute necessity. The Shortcut Guide to Securing Automated File Transfers, authored by 24-year computing veteran Ed Tittel, offers a consolidated explanation of the techniques that you need to know when choosing a technology or application for secure file transfer. Secure Sockets Layer (SSL), IP Security (IPSec), Virtual Private Networks (VPNs), tunneling, and Secure File Transfer Protocol are each examined to give you a better understanding of how you can better protect your enterprise against internal and external security threats. In addition, Tittel lays out the steps to planning for secure file transfer deployment.


Chapter 1: File Transfer Security Issues

Since the creation of the first computer network, there has been sustained interest in leveraging network media to transport data. Just as interstate highways do for commercial transportation, modern computer networks serve as a primary conduit through which business is conducted, so that (virtual) goods, services, and information can be expedited to any location around the world.

The dawn of the Internet era brought with it innumerable opportunities for enterprising and pioneering engineers eagerly seeking to exploit this medium as a means to exchange information. Among these early-information sharing services you can find many forms of information and file sharing protocols and software, including early Usenet and UNIX-to-UNIX Copy (UUCP) implementations to the aptly-named File Transfer Protocol (FTP) that remains widely used for file transfer to this very day. These two approaches illuminate early efforts at distributing information on a wide scale. Although UUCP leverages less server-side capability and tends toward client-to-client (or peer-to-peer) behavior, FTP operates squarely within the framework of a client/server model. Both typify two major classes of file sharing protocols and architectures, with many variations on the same theme still in active development and current use today.

FTP is an official protocol specification that details precisely what is involved in establishing, maintaining, and tearing-down reliable, connection-oriented Transmission Control Protocol/Internet Protocol (TCP/IP) communication. As an Internet Engineering Task Force (IETF) standard, FTP works within just about any conceivable combination of standard FTP client and server protocols—in other words, there are no vendor lock-ins, no proprietary protocol dependencies, nor any real need to ensure version or build compatibility between FTP clients and servers. Owing to its longstanding appearance and widespread use, FTP is an insecure means of communication and file or data transfer. This chapter explores this reality, then goes on to describe similar protocol families as points of comparison.

Chapter 2: Planning Secure File Transfer Deployment

The first chapter set the background and laid the foundation for concepts explained and explored in this chapter. As you now know, today’s typical enterprise file transfer environment is a result of long-term development and deployment of multiple forms of data transfer, often involving different hardware and software platforms. Typically, ad hoc solutions focus around the lowest-common-denominator or principle of least effort, which means leveraging native file transfer utilities to facilitate data transfers. Many times these tasks incorporate scripted interaction and scheduled automation to create periodic transfers for the most common and repetitive forms of shared or archived data.

FTP’s popularity stems from its seamless platform integration, lack of interoperability issues, and nearly ubiquitous presence on everything from Windows workstations to IBM mainframes. Although this sort of “anytime, anywhere” availability seemingly makes FTP well suited to the task of file transfer, the FTP protocol and applications leave much to be desired in terms of centralized management, user accountability, data security, and real-time event auditing. Occasionally, this sort of convenience pays off in the near-term only to produce long-term security consequences by which confidential data can be revealed, intercepted, and possibly even tampered with by intermediate or external parties. There is also the possibility that an organization’s FTP servers can be subverted for use as third-party storage repositories for illicit content or controlled as proxies for external network reconnaissance techniques. Eavesdropping, snooping, and hijacking attacks are three primary vulnerabilities that face improperly secured FTP installations.

Proper planning, implementation, and execution of secure file transfer methods, especially where compliance considerations are concerned, requires a multi-layered approach and thorough attention to detail. This chapter discusses several crucial points to help IT administrators address the issues involved in implementing secure file transfers within the network infrastructure.

Chapter 3: Secure File Transfer

Through earlier chapters, the impetus behind securing any and all forms of at-risk file transfers was clearly elucidated and loosely enumerated. Now that you know the answers to why you should secure at-risk file transfers, you will discover how such transfers can be secured.

This chapter begins with a topical discussion of network reference models, protocols, and services to describe the security concepts that are introduced immediately thereafter. The chapter takes a ground-up approach to describing the aspects of securing digital communications in the context of public networks. A discussion then follows with several worthy and practical solutions to establishing and maintaining secure communications.

Request for Comment (RFC) documentation is far and away the best jumping-off point for most of the material referenced in this chapter. This series of documents encompasses research, insight, and applicable methodologies related to Internet technology, and serves as the basis for drafting and formalizing that terminology, key concepts, and recommended implementations. Because they are such excellent resources for further exploration of the topics described, RFC references are cited for many of the concepts discussed in this chapter.

Chapter 4: Compare/Contrast SFTP, FTPS, and IPSEC

In previous chapters of this book, we’ve examined the issues involved in finding and replacing or strengthening the types of file transfers used for so many important tasks in so many enterprise settings. Along the way, we’ve dug into various key tools and technologies that may be used to help this effort along. Key elements in this laundry list of possibilities have included the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) as well as IP Security (IPSec) and the ever-popular Secure Shell (SSH, which today includes both SSH-1 and SSH-2 versions). We’ve also explained how these various elements may be employed to help boost security for file transfers and to assure reasonable levels of security, confidentiality, and control over file transfer activities and the content and control information they typically convey.

In some cases, it may make sense to simply wrap existing implementations—such as scripts; legacy tools; or other file transfer code for which there may be no source code available nor an easy way to remove older, less secure file transfer applications such as FTP—and to replace them with more secure alternatives such as SFTP or SCP. These are cases in which adding an extra security wrapper, such as IPSec or SSL/TLS can provide the kinds of security, confidentiality, and control that the file transfer programs (and other code inside the wrapper) may lack.

In fact, a Virtual Private Network (VPN) comes very close to realizing the old puzzler about how to have one’s cake and eat it too. That’s because proper use of VPN technology permits public networks—most notably, the Internet—to serve admirably and securely for ferrying private, encrypted communications between senders and receivers. In fact, the more the VPN software can direct traffic through its transports, the more secure ordinary network communications become, especially those that may not be very secure (or secure at all, such as FTP, Telnet, and unencrypted email clients).

The type of VPN arrangement required between each participating endpoint is another major factor to consider when deciding on a solution. There are connection endpoints, or those that establish actual VPN connections from one network to another, and data endpoints that send and receive private information across VPN links. In some situations, these two entities may be part of the same unit or spread across several separate units.