Most organizations need industrial-strength security solutions to conduct e-commerce across their extranets. But SSL, VPNs and private networks are overkill if all you need is secure file transfer between sites. What's the alternative? Many organizations are turning to PGP.
Since its introduction in 1991, PGP has been a staple for encrypting individuals' e-mail and files, and generating digital signatures. Though it's not usually thought of as a B2B application, it's a powerful tool for tasks like securing FTP. Instead of the more common workstation installation, the PGP software is installed on a dedicated FTP server.
Administration of PGP on FTP is straightforward. The public- and private-key rings are owned by a system account. Managing the PGP system involves little more than trading public keys with partners and adding them to the PGP server's public-key ring. VPN installations, by comparison, require considerable configuration and testing at each site even in the best cases. In worst-case scenarios, hours of effort can be wasted only to discover that the VPN devices are simply incompatible.
Although PGP thrives on electronic data interchange (EDI) and other forms of batch processing, it's not the solution to all your B2B security needs. Interactive sessions, in particular, don't lend themselves to a PGP solution. And even when you've found business processes that need encrypted file transfer, PGP won't solve your problem with the click of a mouse.
Here are a dozen best practices to minimize the risk of PGP-based B2B file transfers.
- Use public key encryption. Even though the PGP protocol suite supports several symmetric key algorithms, don't be tempted to use them. Symmetric keys are far easier to defeat through brute-force attacks than any standard asymmetric algorithm or key, especially without a strong passphrase policy and enforcing mechanism. And it's next to impossible to keep passphrases from floating between sites in cleartext via e-mail.
- Maintain as few private keys as possible. Fewer keys are easier to manage. PGP keys may need to be rotated or revoked. Start with a single key pair, and create new keys only when business needs require them.
- Create key pairs with limited life spans. Setting an expiration date for keys is analogous to requiring users to regularly change their passwords. This reduces the chances of theft and may help mitigate potential damage, even if the theft of the key is never discovered. But while the security of a private key is inversely proportional to its life span, its manageability is not. A balance must be struck. Mission-critical or high-risk keys might get rotated every three months, while others may be allowed to live for a year, or even more.
- Severely restrict access to your unencrypted private keys. Publicly accessible servers are by definition high-risk environments -- they're no place for private keys. But since encryption/decryption needs to be automated, you'll either have to embed your private key's passphrase in scripts and store them in memory, or create your private key with a null passphrase. The risk is the same in each case: private keys for batch processing are more vulnerable than most. To protect them, bounce your inbound files from the external/DMZ FTP server to a dedicated internal server for decryption. This has the added benefit of ensuring that no sensitive plaintext is available on exposed FTP servers. Backups are another consideration. You may not want your private keys saved to tape along with everything else, but you'll need to have some method of secure storage.
- Create a special permanent key for signing partners' public keys. To save yourself the trouble of re-signing partners' keys when your private key expires, sign them with a special-purpose key that never expires.
- Verify your partners' key fingerprint by phone or fax. Eliminate the threat of man-in-the-middle attacks by verifying your partners' public keys through out-of-band communication. For example, make a practice of exchanging core technical variables, including PGP fingerprint strings, with partners via fax. During the initial configuration, create a form that includes technical and business contact names and phone numbers, FTP server URLs, usernames, passwords, upload directories, FTP client IP address ranges and PGP fingerprints.
- Require valid signatures. Don't just encrypt your files -- sign and encrypt them. Check for valid signatures during decryption. Let your partners know from the outset that you require valid signatures on all files, and then configure your automated decryption process to reject improperly signed files. Since FTP authentication is inherently vulnerable, digital signatures are the only way to achieve nonrepudiation of origin. Architect your file sharing strategy under the assumption that FTP servers hide no secrets.
- Don't create files that you can't decrypt. In a recovery situation, there's nothing quite like explaining to your management that you have an archived copy of the data they need, but that you can't decrypt it. Avoid that scenario by encrypting all your outbound files for yourself as well as your partners.
- Allow only known clients to FTP through firewalls. Dedicate a new server to PGP data transfer, and firewall it from the Internet so that only the IP addresses of your trusted partners can hit FTP port 21. This will provide some protection from buffer overflows or other ftpd exploits, as well as blocking hackers who have used network sniffers to uncover the passwords in your FTP traffic.
- Configure FTP accounts according to the principle of least privilege. Create separate FTP accounts for each business partner and limit their rights to those actions they need to perform. Configure your FTP server to confine users' access to their home directories. If your server can't do this, find one that can, such as the SANS-recommended vsftpd.
- Scan all files for viruses immediately before encryption and after decryption. Scan all inbound files immediately after decryption -- there's no guarantee that a file wasn't infected prior to encryption. Don't forget to scan all outbound files as well -- these are your trusted business partners, after all.
- Require security agreements with partners. All your efforts will be wasted unless your partners are equally diligent. Spell out the rules for secure file transfer in an agreement with partners. At the very least, communicate and document your expectations.
You can build these security procedures into existing infrastructure. For example, my site was already using a home-brewed Perl application to automate file moves via FTP. It was an easy matter to add modules for PGP using GNU Privacy Guard's GNU Privacy Guard's command-line interface, as well as virus scanning, using McAfee Security's Virus Scan. This allowed us to create processes that won't allow a file to pass unless it's successfully decrypted and scanned for viruses.
These precautions reduce, but don't eliminate, risk. There's always the remote possibility that a partner's private key will be compromised -- hopefully they will have the intrusion detection capabilities to notice. Denial-of-service attacks on an FTP server are more likely than key compromise. For example, anyone who can sniff packets between you and your partners can retrieve passwords for your FTP server. They can then upload files at will, which will easily deny service to legitimate users. Firewalling your FTP server so that only your partners can access it will help, but the bottom line is that there's always inherent risk when you extend your network perimeter. Your business partners may be trustworthy, but their networks are another matter.
About the author: Tim Maletic, CISSP is the IS security officer for Priority Health, a Midwest managed care organization. His recent efforts include collaboration on the Center for Internet Security's HP-UX benchmark and a tutorial on using Secure Shell for automating file distribution in the June 2001 issue of Sys Admin.