In the modern world where we live, constant advancement, refinement and people’s needs regularly demand infrastructure overhauls to a road, building or city, where what was reliable and efficient before, has quickly become unreliable and vulnerable to failure. 

Data is the new water, secure file transfer is the new “pipe”

Even the most common and simple conceptual requirement to deliver water to and around a city requires detailed planning and foresight so that there is no interruption of service. In our world, data is the new water, and secure file transfer is a key component of any organization’s data infrastructure.

The tricky part is when deciding to make changes that any alterations made don’t cause problems further down the line.  So to use the analogy above, upgrading the water delivery pipe to the city may reveal bigger problems to a growing city infrastructure that can’t deliver the volume or may provide technical challenges of connecting new technology to old.

As we all know, change is inevitable, but it’s how we perform change that is important for success.

Old “pipes” are risky

As transaction numbers increase, databases become bigger, more intelligence is captured and regulations drive for the need to trace data. Weaknesses are exposed in the once simple system of transferring bulk information.  Therefore the evolved practices of using basic FTP, freeware, having the business units use whatever software they want or supporting many versions of the same software, are out-dated, unreliable, inefficient and insecure.

So a change of thinking needs to occur and one of the benefits of having customers who are the who’s who of the world’s business and government organisations, means we get to see what the big players are doing.

The fact is, worldwide, some of the biggest organisations are standardising their day to day, point to point, secure file transfer needs on a single high quality product…especially on their Microsoft Windows servers.

Specifically in the APAC region where I work, two major regional banks have mandated and completed the overhaul and replacement of all outdated, freeware and basic FTP products based on the following mandate.

All data files transferred internally or in and out of the DMZ, must be transferred using SSH.

Why?  Because a quality SSH product uses a standard protocol for secure file transfer that protects data in motion, adheres to compliance requirements, offers the best encryption and authentication options available and connect well to different SSH technologies and MFT environments.  This strategy as a whole has been found to reduce cost and an organisation’s risk.

Finally, a real solution for Microsoft Windows

Microsoft Windows Servers do not come standard with any secure file transfer components. This is a major concern for organisations with highly sensitive data, so one of our banks deploys SSH on every Windows Server requiring file transfer (around 40%) while the other bank, deploys SSH on every Windows Server as standard.

For Unix, since the OS often bundles a free SSH product, some organisations will standardise on this where as others prefer to deploy a fully supported product by a known vendor that will respond to service requests and requests for changes, and provide regular security updates.

For example, it is for the reasons described above that customers standardise on Attachmate’s Reflection for Secure IT (RSIT) for their SSH/SFTP File Transfer needs on Windows and/or UNIX platforms.

For the business thinkers, our customer research has found providing a single high quality product means support costs are low, a simple to manage product means maintenance costs are low, a highly secure product means the risk team are happy and deployment is simple.

“Plumbing” advice

My suggestion to the reader is to investigate how many flavors of file transfer are being used on each operating system in your organisation, are they meeting quality and security standards, and if you are paying for a bulldoser to move the data when a shovel will do just fine.

Infrastructure will always change, security will always increase and efficiencies are mandated.  It’s worth taking a look at one of the most basic functions in an organisation and that is secure file transfer, to make sure you are not left exposed and your quality of service is maintained.

Upgrading your pipes – SSH for a secure file transfer infrastructure is a post from: Data In Motion - a Managed File Transfer blog

Share and Enjoy

The post Upgrading your pipes – SSH for a secure file transfer infrastructure appeared first on Data In Motion - a Managed File Transfer blog.

I’ve always heard stories about restaurants that throw challenges at their patrons claiming, “if you eat the whole thing, you don’t have to pay for it.” 

I’ve most recently heard about the “World Famous” 72-ounce (about 2 kilograms) steak dinner that one can get for free (if eaten in 1 hour).  This feast is offered by the Big Texan Steak Ranch in Amarillo, Texas.

To quote their web site, “Many have tried.  Many have failed.”

Just as 72-ounce steaks will provide a significant challenge to the gastro-intestinal systems of the average human being, so too do large files when one attempts to transfer them via legacy file transfer systems.

One of the most pervasive file transfer methods in use is good old FTP.  FTP, which stands for “file transfer protocol” has its roots in specifications that go back as far as early 1971.  While some may argue that the FTP protocol itself has nothing inherently in it that prohibits the transfer of very large files, these large files often present a real challenge when transferred between FTP clients and servers.  Just search on the Internet for “FTP 4Gb”.  The problems frequently lay instead with design limitations of the software implementing the FTP protocol (often old clients or servers, written long ago), or the platforms on which the software is running.

The SFTP transfer protocol, an extension to the secure shell (SSH) protocol provides for more reliability while also adding security.  It does this by means of a message authentication code (MAC) that is computed for each TCP/IP packet.  This provides for data integrity which helps ensure that the file is transferred with complete accuracy and isn’t corrupted (or intentionally altered) in transit.

As managed file transfer solutions have evolved, more proprietary protocols have been developed in the interest of driving additional reliability into large file transfers.  Some of these protocols implement key reliability capabilities:

• Notification that a file transfer has been accurately completed
• Detailed feedback on errors and their causes
• Checkpoint control packets

Out of these capabilities, implemented in the proprietary protocol, file transfer recovery features have been designed that really drive reliability into the file transfer process.  These include:

• Automatic Retries – if the file transfer client knows that an error is one that can be recovered from, it can reattempt a file transfer after a pre-defined waiting period.
• Checkpoint/Restart – Checkpoint control packets tell the sender and receiver how much of the file has been transferred so far.  In the event of a failed transfer, the file transfer can resume at the last checkpoint, rather than restart at the beginning of the file.

In addition to the reliability benefits gained through proprietary protocols, some managed file transfer solutions implement the concept of a work queue in which file transfers are lined up, waiting for their chance to execute.  Work queue recovery is the process by which those jobs are retained in the event of a system crash and loaded back into the queue upon system restart.

Maybe you only push out a 4Gb file with the same frequency that you would eat a 72-ounce steak.  In other cases, you may be experiencing reliability issues on much smaller files.  Regardless, having the added reliability of a managed file transfer solution that supports both open and proprietary protocols will make a big difference when the file has to get there, complete and unaltered.

“I can’t believe I ate the whole thing!” is a post from: Data In Motion - a Managed File Transfer blog

Share and Enjoy

The post “I can’t believe I ate the whole thing!” appeared first on Data In Motion - a Managed File Transfer blog.

One of my favorite tales by Hans Christian Andersen is titled “The Emperor’s New Clothes.” In this story, a couple of swindling weavers offer to make a suit of clothes for a gullible emperor, invisible to anyone not sufficiently intelligent or capable.  The suit of clothes wasn’t real, of course, but since the emperor and his ministers couldn’t see it, they wouldn’t risk pointing out that fact and being exposed as stupid and incompetent.

Over the years, there have been many times when I’ve found myself nodding my head in pretend understanding when various technical acronyms, jargon and concepts are thrown around in a meeting or during a presentation. I feel like one of those advisors, pretending to know something that I do not, and I kind of feel like everyone else in the room is either like the advisor, or like the swindlers.

No invisible clothes here…

Since we use the acronyms SSL and SSH frequently in these blog posts, I figured it wouldn’t hurt to provide some fundamental description of what they are and what they do.

If you’ve never been confused about the difference between Secure Sockets Layer (SSL) and Secure Shell (SSH), then you’re a rare specimen. It’s not enough that the letters are so close–they’re both associated with securing data in motion. They’re also both used when securing interactive access to host-based applications, such as those running on IBM mainframe systems, or on UNIX platforms.

SSL started life as a specification developed by the Netscape Corporation for the purpose of providing a cryptographic protocol to secure HTTP communications.  The most recent version of the SSL specification (version 3.0) was released in 1996. Since then, the Internet Engineering Task Force (IETF) has defined an equivalent, but not strictly interoperable standard called “Transport Layer Security” (TLS). 

Convention often dictates that when SSL is “added” to a nonsecure protocol an “S” should be added to the end of the protocol name; for instance, HTTPS or FTPS. When IBM needed a way to encrypt terminal-based access to their mainframe and midrange systems, they implemented SSL for encrypting TN3270 and TN5250 protocols. You will occasionally see those represented as TN3270S and TN5250S, respectively.

The SSH network protocol was designed by researcher Tatu Ylönen in 1995 for the purpose of securing remote access and command execution on UNIX servers. Like SSL, subsequent revisions of the standard were developed by the IETF. 

SSH “the protocol” is different than the set of client utilities (including one called ssh) that make use of the SSH protocol. These utilities provide remote interactive and batch access to UNIX and Linux command lines as well as secure file transfer capabilities. When SSH is applied to file transfer, you will frequently see the acronyms SFTP and SCP; both are SSH-protected file transfer methods.

So, there you have it. A basic explanation of SSL and SSH that will let you nod your head earnestly next time you hear them.

What’s that guy wearing? is a post from: Data In Motion - a Managed File Transfer blog

Share and Enjoy

The post What’s that guy wearing? appeared first on Data In Motion - a Managed File Transfer blog.