Self-provisioning is the ability for individual end users and partners to set up (or “provision“) their own accounts.

Self-provisioning is a common element of most cloud services but remains relatively rare in file transfer applications.  A major difference between those environments is that self-provisioning in cloud services usually involves linking a credit card or other form of payment to each provisioned account.  This gives cloud services two important things that encourage the use of self-provisioning: a third-party validation of a user’s identity and an open account to bill if things go astray.  File transfer environments also involve a lot of trusted links and require, either by law or regulation, human intervention before such a link is authorized.

BEST PRACTICE: Self-provisioning may or may not be right for your environment.  As is the case with many types of automation, evaluation of this technology in a file transfer environment should involve a cost-benefit analysis of manually provisioning and maintaining groups of users vs. building a self-provisioning application that meets your organization’s standards for establishing identity and access.    An common alternative that lies between manual provisioning and self-provisioning is the ability to delegate permission to provision a partner’s user to a particular partner’s administrator.  (File transfer Community Management often involves delegating provisioning privileges this way.)


The Single Euro Payments Area (SEPA) is an EU initiative to unify payments within the EU.  It is primarily driven by the European Payments Council.  (SEPA is not, by itself, a standard.)

Service Level Agreement

A file transfer service level agreement (SLA) establishes exactly what a particular customer should expect from a particular file transfer provider, and how that customer should seek relief for grievances.

A file transfer SLA will often contain the following kinds of service expectations:

Availability: This expresses how often the file transfer service is expected to be online.  An availability SLA is often expressed as a percentage with a window of downtime.  For example: “99.9% uptime except for scheduled downtime between 2:00am and 5:00am on the second Sunday of the month.”

Different availability SLAs may be in effect for different services or different customers. Availability SLAs are not unique to file transfer; most Internet-based services contain an availability SLA of some kind.

Round-Trip Response Time: This expresses how fast a complete response to a submitted file will be returned.  A round-trip response time SLA is often expressed as a certain length of time.  For example, “we promise to return a complete response for all files submitted within 20 minutes of a completed upload”.  Sometimes a statistical percentage is also included, as in “on average, 90% of all files will receive a completed response within 5 minutes.”

The reference to “round-trip” response time rather than just “response time” indicates that the time counted against the SLA is the total time it takes for a customer to upload a file, for that file to be consumed and processed internally, and for any response files to be written and made available to customers.  Simple “response time” could just indicate the amount of time it would take the system to acknowledge (but not process) the original upload.

Different round-trip response times SLAs may be in place for different customers, types of files or times of day. Round-trip response time SLAs are similar to agreements found in physical logistics: “if you place an order by this time the shipment will arrive by that time.”

Completed Body of Work: This expresses that a particular set of expected files will arrive in a particular window and will be appropriately handled, perhaps yielding a second set of files, within the same or extended window.  For example, “we expect 3 data files and 1 control file between 4pm and 8pm everyday, and we expect 2 response files back at any time in that window but no later than 9pm”

Files in a body of work can be specified by name, path, size, contents or other pieces of metadata.  There are typically two windows of time (“transmission windows“) associated with a body of work: the original submission window and a slightly larger window for responses.

SLAs can be set up between independent partners or between departments or divisions within an organization.  A less stringent form of SLA known as an operating level agreement (OLA) when it is between two departments in the same organization, especially when an OLA is set up to help support a customer-facing SLA.

BEST PRACTICE: A good file transfer SLA will contain expectations around availability and either round-trip response times or expected work to be performed in a certain transfer window, as well as specific penalties for failing to meet expectations.  File transfer vendors should provide adequate tools to monitor SLAs and allow people who use their solutions to detect SLA problems in advance and to compensate customers appropriately if SLAs are missed.


SHA-1 (“Secure Hash Algorithm #1”, also “SHA1”) is the second most common data integrity check standard (a.k.a. “hash”) used throughout the world today.  SHA-1 codes are 160-bit numbers and are usually represented in hexadecimal format (e.g., “de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3”).

SHA-1 is the least secure hash algorithm NIST currently supports in its FIPS validated cryptography implementations.   However, SHA-1 is faster than SHA-2 (its successor) and is commonly available in file transfer technology today (e.g., FTP’s unofficial “XSHA1” command).

BEST PRACTICE: Modern file transfer deployments should use FIPS validated SHA-1 or SHA-2 implementations for integrity checks.  Some SHA-1 usage is already prohibited in high security environments.  If you are working with a U.S. Federal Government application, read NIST’s “Transitioning of Cryptographic Algorithms and Key Sizes” to see if your SHA-1 implementation is still allowed.


SHA-2 (“Secure Hash Algorithm #2”) is the most secure hash algorithm NIST currently supports in its FIPS validated cryptography implementations.  SHA-2 is really a collection of four hashes (SHA-224, SHA-256, SHA-384 and SHA-512), all of which are stronger than SHA-1.

Complete SHA-2 implementations in file transfer are still uncommon but becoming more common as time passes.

A “SHA-3” contest to find a future replacement for SHA-2 is currently underway and expected to conclude in 2012.

BEST PRACTICE: Modern file transfer deployments should use FIPS validated SHA-1 or SHA-2 implementations for integrity checks.


SHA-224 is the 224-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”).  It is not a unique hash algorithm within the SHA-2 standard but is instead a truncated version of SHA-256.

See “SHA-2” for more information.


SHA-256 is the 256-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”).  Like SHA-512, it is one of two unique algorithms that make up a SHA-2 hash, but SHA-256 is optimized for 32-bit calculations rather than 64-bit calculations.

See “SHA-2” for more information.


SHA-3 refers to the new hash algorithm NIST will choose to someday replace SHA-2.   A contest to select the new hash is scheduled to conclude in 2012.


SHA-384 is the 384-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”).  It is not a unique hash algorithm within the SHA-2 standard but is instead a truncated version of SHA-512.

See “SHA-2” for more information.


SHA-512 is the 512-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”).  Like SHA-256, it is one of two unique algorithms that make up a SHA-2 hash, but SHA-512 is optimized for 64-bit calculations rather than 32-bit calculations.

See “SHA-2” for more information.


SLA is an abbreviation for “Service Level Agreement“, which is a specific contract between a customer and a provider that lays out exactly what each side can expect from the other.   The minimum amount of work and minimum level of due care that a file transfer operations team is responsible for is often determined by the SLAs it must meet.

See “Service Level Agreement” for more information.


SMTP is an email protocol used to push messages and attachments from server to server.  Many technologies have been used to secure SMTP over the years, but the best technologies available today use SSL (version 3) or TLS to secure the entire SMTP connection.

SMTP typically uses TCP port 25 to move unsecured traffic and often uses TCP port 465 to move secured traffic.  Use of alternate ports with SMTP is extremely common to reduce connections from spammers who try to exploit servers listening on the most common ports.

BEST PRACTICES: SMTP should always be secured using SSL (version 3) or TLS.  If your file transfer deployment uses email notifications, then email sent through SMTP should either always be accepted within a few seconds or should be automatically queued up in the file transfer application in case of delay.  If SMTP services are unreliable and no queue mechanism exists in your file transfer solution, then a standalone mail server relay should be implemented to ensure that timed-out notifications do not cause unnecessary delay or failure of file transfer activities.


SSL (“Secure Sockets Layer”) was the first widely-deployed technology used to secure TCP sockets.  Its use in HTTPS (HTTP over SSL) allowed the modern age of “ecommerce” to take off on the world wide web and it has also been incorporated into common file transfer protocols such as FTPS (FTP over SSL) and AS2.

In modern usage, “protected by SSL”, “secured by SSL” or “encrypted by SSL” really means “protected by TLS or SSL version 3, whichever gets negotiated first.”  By 2010 clients and servers knew how to negotiate TLS sessions and will attempt to do so before trying SSL version 3 (an older protocol).  Version 2 of SSL is considered insecure at this point and some clients and servers will attempt to negotiate this protocol if attempts to negotiate TLS or SSL version 3 fail, but it is rare that negotiation falls through to this level.

SSL depends on the use of X.509 certificates to authenticate the identity of a particular server.  The X.509 certificate deployed on an SSL/TLS server is popularly referred to as the “server certificate”.  If the name (CN) on the server certificate does not match the DNS name of a server, clients will refuse to complete the SSL/TLS connection unless the end user elects to ignore the certificate name mismatch.  (This is a common option on web browsers and FTP clients.)  If the server certificate is expired, clients will almost always refuse to complete the SSL/TLS connection.  (Ignoring certificate expiration is usually not an option available to end users.)  Finally, if the server certificate is “self signed” or is signed by a CA that the client does not trust, then most clients will refuse the connection.  (Browsers and FTP clients usually have the option to either ignore the CA chain or import and trust the CA chain to complete the negotiation.)

Optional X.509 client certificates may also be used to authenticate the identity of a particular user or device.  When used, this certificate is simply referred to as a “client certificate.”  File transfer servers either manually map individual client certificates to user codes or use LDAP or Active Directory mappings to accomplish the same goal.  File transfer servers rarely have the ability to ignore expired certificates, often have the ability to import a third-party CA certificate chain, and often have the ability to permit “self-signed” certificates.

Whether or not client certificates are in use, SSL/TLS provides point-to-point encryption and tamper protection during transmission.  As such, SSL/TLS provides sufficient protection of “data in motion”, though it provides no protection to “data at rest.”

SSL/TLS connections are set up through a formal “handshake” procedure.  First, a connecting client presents a list of supported encryption algorithms and hashes to a server.  The server picks a set of these (the combination of algorithms and hashes is called a “ciphersuite”) and sends the public piece of its X.509 server certificate to the client so the client can authenticate the identity of the server.  The client then either sends the public piece of its X.509 client certificate to the server to authenticate the identity of the client or mocks up and sends temporary, session-specific information of a similar bent to the client.  In either case, key exchange now occurs.

When you hear numbers like “1024-bit”, “2048-bit” or even “4096-bit” in relation to SSL, these numbers are referring to the bit length of the keys in the X.509 certificates used to negotiate the SSL/TLS session.  These numbers are large because the exchange of keys in asymmetric public-key cryptography requires the use of very large keys, and not every 1024-bit (etc.) number is a viable key.

When you hear numbers like “80-bit”, “128-bit”, “168-bit” or even “256-bit” in relation to SSL, these numbers are referring to the bit length of the shared encryption key that is negotiated during the handshake procedure.  This number is dependent on the algorithm available on clients and servers.  For example, the AES algorithm comes in 128-bit, 192-bit and 256-bit editions, so these are all possible values for software that supports AES.

It is uncommon to refer to hash bit lengths in conversations about SSL; instead the named hash – typically MD5 or SHA-1 – is typically stated instead.

The three most important implementations of TLS/SSL today are Microsoft’s Cryptographic Providers, Oracle’s Java Secure Socket Extension (“JSSE”) and OpenSSL.  All of these libraries have been separately FIPS validated and all may be incorporated into file transfer software at no charge to the developer.

BEST PRACTICE: The SSL/TLS implementation in your file transfer clients and servers should be 100% FIPS validated today. More specifically, the following file transfer protocols should be using FIPS validated SSL/TLS code today: HTTPS, FTPS, AS1, AS2, AS3 and email protocols secured by SSL/TLS.  Modern file transfer software supports the optional use of client certificates on HTTPS, FTPS, AS1, AS2 and AS3 and allows administrators to deny the use of SSL version 2.  If you plan to use a lot of client certificates to provide strong authentication capabilities, research the level of integration between your file transfer software, your enterprise authentication technology (e.g., Active Directory) and your PKI infrastructure.


The Society for Worldwide Interbank Financial Telecommunication (SWIFT) runs a popular system used by banks around the world to quickly exchange transactions with each other.  Most international interbank messages use this system.  Unlike clearing houses or other institutions that provide intermediate or final settlement of financial transactions, SWIFT is simply a secure transaction service.  Remote banks may use the system to directly transact with one another, but SWIFT is not itself responsible in any activity that may occur within any bank-to-bank transaction.

SWIFT provides limited file transfer services.  For example, SWIFTNet Mail can be used to intercept messages bearing attachments and route them to other SWIFT members through the SWIFT network rather than the open network.   Internally, SWIFT has standardized on XML-wrapped transactions in its store-and-forward architecture.

Though an early advocate of near-realtime geographic redundancy across continents (North America and Europe), SWIFT pulled all operations back into the EU in 2009 after a 2006 ruling in which the Belgium government declared that SWIFT cooperation with U.S. Federal authorities were a breach of Belgian and EU privacy laws.   (Today, cloud service providers often avoid spanning geopolitical boundaries because of this and similar landmark rulings.)

Event Log Analyzer by SolarWinds