Stealing the Death Star plans – would Managed File Transfer have helped?

Coping with unplanned File Transfer Request

MFT FirewallI recently went to the cinema to see Star Wars Rogue One; overall I really quite enjoyed the movie, but in hindsight there was maybe one area where perhaps a Managed File Transfer solution may have helped, namely stealing the plans for the Death Star from the planet Scarif.

Unplanned File Transfer Request

In most organisations the Managed File Transfer administrator will at some point have been handed a large critical file and although it’s likely that no rebels will die if the file isn’t delivered, it might sometimes feel that way.  So let’s look at the basics of what you really need to prepare for unplanned File Transfer Requests critical transfers.

Be Prepared!

This is the crux of the issue really – how much you can prepare in advance for an unplanned File Transfer Request.  We can break this up into a two key areas – where we get the file from, and where we deliver it to.  As long as we have this information in some detail, we can make a start planning the transfer.

The Source

Generally, someone is going to give you the location of the file on a server somewhere for you to go and collect; in Rogue One, this is the data bank on Scarif, protected by a planetary shield.  That planetary shield is analogous to a firewall – so the first thing you will need to do is ensure that you can pass the firewall when you need to (flying an imperial shuttle is optional!).  This is only half the story however; once you have passed the firewall you obviously need access to collect the file.  You also need to know what to do with the original file following the transfer.  In many cases it makes sense to prepare in advance a temporary staging area to which you grant users write access, but which only the Managed File Transfer service has read access to.  You can use it whenever the sudden requests arrive and publish your own rules for use.

The Target

Sending the plans for the Death Star from the planets surface again seemed problematic; in real terms there is once more a firewall to traverse, but this time we don’t have any control over it. Our options are limited to either requesting access (which may be time consuming), or making use of whatever channels are available for us to transfer files on.

In my experience, if you need to request access then you can save time by having your connection requirements (your IP address, preferred protocols) prepared in advanced and shared with your customers. That way, you will find that the information is often already distributed to the receiving organisation and actioned before your customer gives you the file.

If however you need to use an existing channel then it is important to understand the capabilities of your Managed File Transfer solution – which protocols it supports and how they are configured. There are some file transfer servers out there that are very specific about incoming connections; you will need to be aware of how these ‘specialities’ are handled in your Managed File Transfer solution.

Finally, we will generally need the receiving organisation to provide us with access to write the file. This is an area that you can do very little to prepare for in advance, short of insisting that your customers provide credentials when requesting transfers. To this end, a useful tool to have available is a simple form for your customers to complete, for example:

[table width=”500″ colwidth=”250|250″ colalign=”left|left”],

Requester Name:,

File Name:,

Destination Address:,

Destination Protocol:,

Destination User:,

Destination Password:,

Destination File Name & Folder:,


Of course, these are all just suggestions, but I cannot stress how much time you will save yourself by these few small preparations to deal with an unplanned File Transfer Request.

And in the event of still having troubles sending the files, you can always hide them in a passing service ‘droid!

Unplanned File Transfer Request

Unplanned File Transfer Request