SC Magazine just published a short article titled “FTP described as unsecure and generally unmonitored”.

In the article, fellow Managed File Transfer (MFT) vendor Axway correctly points out that “usernames, passwords, commands and data can be easily intercepted and read while files transferred via FTP are uploaded or downloaded without any encryption.”

Not to overstate the obvious, but I wholeheartedly agree (and this should come as no surprise to our avid blog readers).  The FTP protocol turned 40 years old in 2011 and although still functional, it was not designed to provide any encryption or guaranteed delivery.  Unfortunately, many organizations are still relying on outmoded homegrown FTP scripts or have deployed basic FTP servers scattered throughout their organization – all lacking basic security measures, not to mention important visibility, management and enforcement capabilities.

Today, the 40-year old FTP protocol proudly serves as the foundation for the majority of data transfer and application integration technologies that organizations rely on so heavily.    But luckily for us all, modern file transfer solutions deliver much more than basic FTP:

  • VISIBILITY capabilities such as logging; reporting; alerts; notifications; chain-of-custody and file life cycle tracking
  • MANAGEMENT capabilities such as workflows and scheduling of file related processes; person-to-person file transfer;  integration with systems/applications; data transformation; high availability;  virtualized platform support
  • ENFORCEMENT capabilities such as user provisioning;  password policies;  encryption requirements (for example, requiring 256-bit AES encryption over FTPS or SFTP protocols);  file integrity checking;  non repudiation

Now is the time to replace old and often insecure point FTP solutions and hard-to-maintain scripts with technology that includes the benefits of a modern MFT solution.

Ziff Davis recently published a study on Managed File Transfer that heralds MFT solutions as “the unsung security and compliance solution”.  Eric Lundquist sets the stage nicely:

“Everyone is talking about the need to collaborate more effectively and put employees closer to customers in a real time business environment.

But until you can assure the security, privacy, and compliance requirements of data transfer, the collaborative enterprise is just a good idea.  MFT is one of those enabling technologies designed to make it a reality.”

The study found that security concerns about current file transfer methods include the usual suspects, such as:  encryption; viruses, user authentication, backup, hacking, enforcing security policies, managing external users, auditing, reporting and defining security policies.

Not surprisingly, data from the study shows that many of those very security concerns that people had with their organizations current file transfer methods are actually strengths of today’s MFT solutions.

Keep in mind that many organizations still rely on homegrown scripts and point-to-point solutions, oftentimes using unencrypted FTP protocol for transport… And with very little visibility, management or policy enforcement.  In addition to being time consuming and expensive to manage and maintain (and commonly built by developers that left the company years ago), many existing file transfer methods are insecure and introduce risk and inefficiency into an organization.

Plus, many companies haven’t even begun to crack the person-to-person nut of file transfer beyond relying on corporate email, unsanctioned personal email or file sharing websites, and even sneakernet!

In my next post, we’ll take a closer look at some of the areas where the study identified MFT solutions as being superior to many commonly used methods for file transfer.

I just returned from the PCI Security Standards Council .  It was great to spend a couple of days talking tech and trends with other security experts.

The hottest trend this year in the payment security industry is “tokenization”.   This technology lifts credit card numbers from sets of data and replaces them with unique one-way tokens (e.g., “234cew23”) in the data instead.  The original credit card numbers are stored in a “secure token vault” and may only be retrieved by authorized people and processes who present another set of credentials (preferably two-factor credentials).

The reason businesses find tokenization compelling is because PCI requirements state that data sets with credit card numbers must be treated with more care than data sets without that information (e.g., just your name, expiration date, etc.).  The higher degree of care often translates into full encryption, good key management, regular key rotation and a host of other security controls.  All these extra controls cost money, so if businesses can ratchet down the sensitivity of their data with tokenization, they can enjoy cost savings by not having to implement (or audit) other security controls.

Anyone buying in at this stage would be an early adopter: the Council has not yet endorsed the use of this technology.  However, the Council has formed a working group to come up with specific guidance (e.g., are hashes OK, if so, which ones, are unique IDs OK, etc.), so some level of future acceptance seems likely.  So far the working group has only provided a definition of the technology (essentially, the one I provided above).   However, a draft recommendation from the Council with specifics is expected around the new year.