Accidental “certificate spill” is a common problem in file transfer security. It occurs when an untrained or careless individual accidentally sends the private key associated with a public/private certificate pair to someone who only needs the public component.
Certificate spill is a dangerous problem because it exposes credentials that allow unauthorized individuals to act with the identity and permission of trusted individuals and systems.
Today, it is common for a file transfer server administrator to ask an end user for “his or her certificate” so the administrator can add the end user’s public certificate credential to the user’s file transfer profile. This will allow future connections to a file transfer server to be negotiated with strong authentication in place. However, end users frequently send both their private and public keys to a request like this. This kind of certificate spill often occurs in cleartext email and is often accompanied with an infuriating note like “I don’t know exactly what you’re looking for, but here’s all the files in my certificate folder”.
A worse case occurs when an untrained administrator broadcasts both the public and private components of a server key or server certificate to every actual or potential end user “to help them connect”. (This happens more frequently than you might believe.)
To prevent certificate spills, proper training and proper deployment of technology that make it easy for end users and administrators to perform certificate exchange are both critical.
BEST PRACTICE: If you use keys or certificates to authenticate, secure and/or vouch for information, you must ensure that all personnel who handle these credentials know the difference between public and private keys and know when to use each type of credential (leaning on features available in software and systems whenever possible). Administrators of these systems should also have a short “certificate spill containment” procedure in place in case a private key is accidentally transmitted. This procedure should include assessment, communication, remediation (e.g., generate/distribute a new certificate and cancel/revoke the old one) and verification.
Certification of software and systems against a standard is better than having software and systems merely in “compliance” with a standard. Certification means that a third-party agency such as NIST or the PCI Council has reviewed and tested the claim of fidelity to a standard and found it to be true. Certifying agencies will usually either publish a public list of all certified implementations or will be happy to confirm any stated claim.
A common example of certification in the file transfer industry is “AS2 certification”. Under this standard, Drummond Group tests various vendors’ cryptography implementations, issues a validation certificate for each that passes and lists all implementations that have passed in a public web page on the NIST site.
Certification is roughly equivalent to “validation“.
Individuals working in the file transfer industry frequently have earned one or more certifications through training and testing. These certifications generally fall into one of three categories:
File Transfer Security Certification: (ISC)2 and SANS certified individuals have a good understanding of security from a vendor-neutral point of view. (CISSP is an (ISC2)2 certification; CCSK is a newer vendor-neutral certification from the Cloud Security Alliance.)
File Transfer Workflow Certification: Surprisingly little exists today for certified training in the area of workflow design, implementation or operations. (Quick plug: this is one area where File Transfer Consulting can help.) PMP certified project managers and Six Sigma trained personnel may fall in this category today.
File Transfer Vendor Certification: Cisco Firewall Specialists and Sterling Integrator Mapping Specialists are examples of vendor-specific certification programs for individuals.
“Check 21″ is the common name for the United States’ Check Clearing for the 21st Century Act, a federal law enacted in 2003 that enabled banks to phase out paper check handling by allowing electronic check images (especially TIFF-formatted files) to serve all the same legal roles as original paper checks.
Check 21′s effect on the file transfer industry has been to greatly increase the size of files transmitted through banks, as check images are frequently large and non-compressible.
A “clear text password” is a common problem in file transfer security. It is a dangerous problem because it exposes credentials that allow unauthorized individuals to act with the identity and permission of trusted individuals and systems.
The problem happens in at least five different areas:
Clear text password during input: This problem occurs when end users type passwords and those passwords remain visible on the screen after being typed. This exposes passwords to “shoulder surfing” and others who may share a desktop or device. Most applications today show asterisks while a password is being typed. Modern implementations (such as the standard iPhone password interface) show the last character typed for a few seconds, then replace it with an asterisk.
Clear text password during management: This problem occurs when an operator pulls up a connection profile and can read the password off the profile when he/she really only should be using an existing profile. To avoid this problem application developers need to code a permissions structure into the management that permits use without exposing passwords. Application developers also need to be careful that passwords are not accidentally exposed in the interface, even under a “masked” display. (Perform a Google search on “behind asterisks” for more information on this.)
Clear text password during storage: This problem happens when configuration files, customer profiles or FTP scripts are written to disk and no encryption is used to protect the stored data. Application developers can protect configuration files and customer profiles, but when FTP scripts are used, alternate authentication such as client keys are often used instead of passwords.
Clear text password in trace logs: This problem occurs when passwords are written into trace logs. To avoid this problem application developers often need to special-case code that would normally dump clear text passwords to write descriptive labels like “*****” or “7-character password, starting with X” instead.
Clear text password on the wire: This problem occurs when passwords are sent across a network. To avoid this problem secure transport protocols such as SSL/TLS or SSH are often used. The most frequent cause of this problem is not application defects but operator error: when an administrator accidentally configures a client to connect without using a secure protocol, credentials are often sent in the clear.
BEST PRACTICE: All modern file transfer clients and file transfer servers should steer clear of these problems; these are entry-level security concerns and several application security design guidelines (e.g., “Microsoft’s Design Guidelines for Secure Web Applications” and the SANS Institute’s “Security Checklist for Web Application Design”) have covered this for years.
“Community Management” is a marketing term used to describe technology and services that use external authentication technology to provision (or “onboard“) users or partners using rich profile definitions and which allows users and partners to maintain elements of their own profiles (e.g., contacts, email addresses, member users with limited rights, etc.).
File transfer and/or EDI solutions that provide community management capabilities are either VANs or direct competitors to VANs.
“Compliance” to a standard is weaker than “validation” or “certification” against a standard. Compliance indicates that a vendor recognizes a particular standard and has chosen to make design decisions that encompass most, if not all, of the standard.
When a vendor has implemented all of the required standard, that vendor will frequently upgrade their statement to “completely compliant” or “guaranteed compliant.”
A common example of compliance in the file transfer industry is a claim to “SFTP interoperability.” Today, there is no universally-recognized third-party laboratory that will test, validate and stand behind these claims, but there are hundreds of vendors who claim that their products are compliant with various known SFTP standards, such as compatibility w/ OpenSSH and/or fidelity to RFC 4250.
Another common example of compliance in the file transfer industry is “FIPS compliance“. This slippery phrase often indicates that the cryptography used a particular solution implements some or all the algorithms specified in FIPS 140-2 (e.g., AES) but that the underlying cryptography component has not been validated by a third party.
A control file is a special file that is sent along with one or more data files to tell applications that handle the data files how to handle them. Control files are typically created by the same application that original sends files into a file transfer system.
The most common type of control file is a “trigger file“. Trigger files are used to initiate further processing or retransmission of files already uploaded to or present on a separate file transfer system.
Other types of control files are often used to communicate final file names, intermediate processing applications, conditions of transfer/processing success or other metadata.
There is no standard format for control files, but many control files are either simple “flat files” with one file configuration entry in each line or simple XML files.
There are three general expectations made on file transfer systems by applications that submit control files.
Send and Forget (No Control File): When applications send files into a file transfer system they rely on the file transfer system to correctly determine when files can safely be processed or retransmitted. This is often a safe assumption, especially when each file can be processed on its own and each file can be processed immediately.
Send and Commit: The use of a control file allows applications to commit a group of transmitted files to final acceptance, further processing or retransmission. The use of a control file is often used here when two or more files need to be submitted together to allow final acceptance, further processing or retransmission.
Send, Commit and Confirm: If a file transfer application returns a status code or file after acting on a submitted control file then it can confirm both the original files sent and the contents of the control file. The use of the extra confirmation step is often used when the submitting application wants to check up on the transfer status or history of its submitted files. (In this case, either the submitted control file or resulting confirmation file will contain an ID the submitting application can use to perform lookups after the initial confirmation.)
Core FTP is a secure FTP software brand that includes a free desktop FTP client (Core FTP LE), a commercial FTP client (Core FTP Pro) and an FTP server (Core FTP Server).
CRC (“cyclic redundancy check”) is an early data integrity check standard (a.k.a. “hash”). Most CRC codes are 32-bit numbers and are usually represented in hexadecimal format (e.g., “567890AB”).
CRC was commonly used with modem-based data transfer systems because it was cheap to calculate and fast on early computers. Its use carried over into FTP software and some vendors still support CRC in their applications today (e.g., FTP’s unofficial “XCRC” command).
However, CRC is not considered a “cryptographic quality” integrity check because it is trivial for an attacker to create bad data that bears the same CRC code as a set of good data.
BEST PRACTICE: Modern file transfer deployments should use FIPS validated SHA-1 or SHA-2 implementations for integrity checks instead of CRC. However, FTP software that supports the XCRC command can be used to supplement stronger integrity checks, particularly over unreliable connections. (i.e., If your application calculates a bad CRC code for a particular transfer, you can avoid the effort of calculating a more expensive SHA-1 or SHA-2 hash.)
In file transfer operations, a cut-off time is a specific time of day a processor must receive a batch or file by so processing can begin on that day. The processor, not the sender, decides the cut-off time.
For example, if a processer publishes a cut-off time of 5pm, then a file received at 4:59pm will be processed today, but a file received at 5:01pm may not. (Special dispensation is often granted to particular files on an operator-by-operator basis.)
See also: transmission window
Cyber liability is the risk posed by conducting business over the Internet, over other networks or using electronic storage technology. Insurance can be bought and “risk based” security strategies can be used to mitigate against both the first- and third-party risks caused by cyber liability.
A “first party” cyber liability occurs when your own information is breached. For example, a hack that results in the exposure of your own trade secrets would create a first party cyber liability.
A “third party” cyber liability occurs when customer or partner information your organization has promised to keep safe is breached. For example, a hack that results in the exposure of your customer’s Social Security numbers would create a third party cyber liability.
Companies have compelling reasons to avoid both types of cyber liability, but third party cyber liabilities can be devastating. First party cyber liabilities threaten a company’s competitiveness, but third party cyber liabilities often ruin brands, open the door to million-dollar lawsuits and trigger statutory fines (e.g., HIPAA HITECH’s $50,000 per-incident “willful neglect” fine).
File transfer technology frequently transmits information whose disclosure would lead to first- or third-party cyber liabilities.
BEST PRACTICE: File transfer technology, policy and procedure decisions should be made under the auspices of a risk-based security strategy that takes into account both first- and third-party cyber liabilities. (File Transfer Consulting can help you identify your risk tolerance, then develop a package of file transfer products and services that specifically matches your ideal tolerance.)
Cyberduck is a free open source file transfer client for Windows and Macintosh desktops.
Cyberduck offers support for FTP, FTPS, SFTP, Amazon S3, Rackspace Cloud Files, Google Storage for Developers and Amazon Cloud Front. Cyberduck features sychronization across multiple server types and support for many languages.
Cyberduck’s official site is cyberduck.ch. It is licensed under GNU.