Security News > 2004 > October > When is secure FTP not secure? When it reaches your network

http://www.computerworld.com/securitytopics/security/story/0,,96265,00.html Advice by James King ID Analytics Inc. OCTOBER 01, 2004 COMPUTERWORLD It's widely accepted that file transfer protocol (FTP) is the simplest way for organizations to send data across the Internet. To enhance security, many companies now use sFTP or FTP/S, the "secure" forms of FTP, believing that data traveling across this protocol is safe. But is it? It's true that secure forms of FTP have additional encryption while commands and data are in transit across the Web. But it's commonly overlooked that while files are indeed secure during transit, they are nonetheless extremely vulnerable for the period of time they reside at the Internet-facing, final point of handoff at the edge of the receiving network. Due to limited Internet bandwidth and large file sizes, it will always take some amount of time for this final transfer because a software program or script at the receiving end must wait for the download to be complete before securing the entire file inside the interior firewall. Imagine a pipe carrying water to a bucket. Though the pipe holds the water securely, the bucket can't be secured until it's filled with the water it's waiting for. The larger the file, the longer the transfer takes. The longer the transfer takes, the greater the vulnerability. The exposure is due to new vulnerabilities discovered, seemingly daily, within operating systems. If a hacker can gain access to the operating system, any files on the computer's disk are available to him. If the files on the disk aren't encrypted, you have made the hacker's day. In an environment where security breaches have become so commonplace that legislation such as California's Senate Bill 1386 makes companies even more liable for data security violations, greater measures of protection are needed. Hackers only need one part of the file to do their dirty work. All it takes is one stolen Social Security number from a customer for your company to be at risk. Here are some measures that IT managers and network architects can take to better ensure data security: 1.) Install a dedicated transfer server in a true DMZ with equipment from different manufacturers, Perhaps the most common method for supporting automatic data transfer is to add this duty to an existing internal server and present the server to partners through the external firewall via network address translation. Unfortunately, this is also the most insecure method. If the single firewall is compromised through a known vulnerability or if the server is compromised through the protocol used for data transfer, the entire network segment where the servers are located is exposed. Isolating the data-transfer duty to a server that isn't multipurposed, being sure to disable any unnecessary services, reduces the number of potential vulnerabilities, but the internal network is still vulnerable. The best method to minimize risk is to create a true DMZ by using two firewalls, each with two interfaces to keep the Internet-facing firewall completely separate from the firewall facing the private network. Also, most organizations source their firewall equipment from a single manufacturer. However, newly discovered vulnerabilities often affect entire ranges of a manufacturer's products. Ideally, the two firewalls in this scenario will be sourced from different manufacturers because it's rare for new vulnerabilities to be effective across platforms. 2.) Establish strict rules at the firewall. A good beginning rule set for the exterior firewall would be explicit denial of access to all, but with implicit access to well-known clients and partners. The interior firewall rule set should explicitly deny all access, including access from the FTP server in the DMZ. Any processes waiting for files from the outside must reach out through the interior firewall and pull files in from the sFTP server. 3.) Require a key exchange for connectivity. Secure FTP provides functionality allowing access only to outside contacts with a valid cryptologic key. This eliminates the need for a user ID and password log-on. The key may also be capable of differentiating individual computers accessing the sFTP server from within a client organization, where there otherwise may be only a single log-in ID or IP presented. If key exchange isn't possible, require the use of strong passwords, meaning those with an eight-character minimum length, required mixing of upper and lower case, and inclusion of punctuation marks. Don't reuse passwords, and change them frequently. 4.) Encrypt, encrypt, encrypt. One of the most important measures is to require exchange of public encryption keys and encrypt the data files that will be transferred. Many programs are available for this level of data encryption in both the commercial and public domains, including Pretty Good Privacy and the GNU version, GPG. An additional bonus of encryption is that almost all of today's encryption programs also include file compression. 5.) Exercise additional caution when using FTP/S. FTP/S uses a Secure Sockets Layer (SSL) wrapper around an FTP server or client to encrypt the log-in and data exchanged between them. But differences in the various SSL implementations and versions used can result in incompatibilities and failures between server and client software. If the initial SSL authentication between two SSL implementations fails, they will often fall back to sending the user log-in and password as clear text rather than fail the log-in. This allows the FTP user log-in data to be clearly read by anyone monitoring the traffic. Oddly enough, once the clear-text log-in is authenticated, the data transfer itself will be encrypted. So the rule is: Check the log files, since this is the only place where this particular failure will show up, especially because your outside contacts can change implementations of FTP/S without your knowledge. If possible, configure the chosen FTP/S server or client to deny or fail the log-in if the initial SSL authentication fails. 6.) Stay current with the latest operating system patches. FTP programs are implemented on a number of platforms, including Windows, Linux, Solaris and many flavors of Unix, so attentive daily updates are essential. 7.) Look for security holes, especially by frequently checking logs. Even with all the latest technology in place to protect data, vulnerabilities can exist. It takes smart people vigilantly applying investigative skills to keep a network truly secure. In a world where new vulnerabilities appear daily and where the rate of litigation increases as rapidly as computing power, it's imperative to secure your data transfers with clients and business partners. Fortunately, a straightforward architectural approach to systems and process design can mitigate most of the risks. Employing the strategies outlined here will make it much easier for IT and security professionals (and their executive management) to sleep at night, knowing that their data is as secure as possible. James King is vice president, engineering and operations, at ID Analytics Inc., a San Diego-based vendor of identity management products and services. _________________________________________ Open Source Vulnerability Database (OSVDB) Everything is Vulnerable - http://www.osvdb.org/

News URL

http://www.computerworld.com/securitytopics/security/story/0,,96265,00.html