Here are the influential voices leading the conversations where nonprofits and technology overlap.
The File Transfer Protocol (FTP) is one of the oldest Internet protocols, and like the Simple Mail Transfer Protocol (SMTP), it is still in use today. While most business-to-consumer traffic is through web pages, FTP is widely used by many companies to exchange information with other companies, regulatory agencies and business partners.
If your company is among those that use FTP, how do you ensure that your transfers are secure when you control only half the connection? Here are four ways to keep your company’s data — and your partner’s data — secure.
When you browse a website containing private data, such as your bank account, you are typically using the HTTPS protocol. This means that data transferred to and from your bank is transmitted through a secure tunnel.
A similar way to make sure your FTP experience is secure is to use a Secure Sockets Layer (SSL) on top of FTP. In a method similar to creating a secure website, you purchase an SSL certificate from a qualified vendor and apply it to your FTP server. FTP clients then verify the validity of your certificate, exchange secure keys and “talk” to each other over a secure channel.
FTP servers are often targets for attack because they are exposed to the Internet. So why store your data on them? Even the default FTP server in Microsoft Windows lets you specify that transfers should land on another server, perhaps one inside your network. When files are uploaded to that FTP server, the server automatically transfers the data to another server and never stores the data on the FTP server itself.
Reporting is the key to keeping your FTP server safe from harm. “Hammering” reports can alert you if someone is trying to continually hit your site and upload files or attempt a denial-of-service attack. Failed login attempts with invalid user names — not just bad passwords, but user names that don’t exist — indicate a dictionary hacking attack. Both of these can be easily identified in an audit report of your server.
Some FTP server vendors include automated responses to threats. For example, servers can be configured so that five invalid user-name attempts from an IP address block that address, and you receive an alert of potential malicious activity.
Using your FTP server or your company’s firewall, limit both the outbound and inbound connections to the FTP server. If you know the remote FTP server’s IP address, you can set up your server or firewall to permit FTP connections from only that address.
While in theory this seems like an excellent practice, there can be difficulties. First, limits can’t be used with ad-hoc FTP transfers because you don’t know which client will be connecting to you (or from where). Second, if your business partners change their Internet service providers or FTP servers, this might break the firewall or FTP server rules.
Sometimes the information is of such a sensitive nature that you need to take an extra step and encrypt not just the data stream, but also the data itself. Many companies do this already with e-mail: They use a product that allows individuals to exchange secure keys.
When they send e-mail to a user with whom they’ve exchanged keys, the client automatically encrypts the data before sending it over Simple Mail Transfer Protocol to the remote organization. On the other end, the e-mail client opens and decrypts the data.
The advantage here is that even when the data is not in flight (for example, sitting in an e-mail store or on a file system), it is still encrypted. Not until the final recipient actually opens the message does the data become readable.