AV Doesn’t Always Cut it When it Comes to MFT
Whenever data is moved there is a risk. Managed File Transfer (MFT) reduces that risk by introducing things like secure protocols, effective user permissioning and encryption at rest to mitigate them. Furthermore, most IT teams deploy some form of Anti-Virus (AV) to their MFT servers, which is of course a good practice.
What of the data though? Effectively MFT should be thought of as another Ingress and Egress point to your network, and subject to as much stringent sanitation as possible. Consider all the checks an email goes through as it enters or leaves your organisation. I am willing to bet email attachments traverse at least one device or software solution that checks the body, x-headers and attachments for sensitive or dangerous content before making decisions on permitting or denying the traffic?
If your MFT is licensed for person-to-person secure email delivery, are the same checks applied to the https delivery of that data? I doubt it.
Now consider the data being moved by MFT. Is it more or less sensitive than standard email? Daft question.
Again, compare the level of checking, it is common for our customers to admit that data from external parties uploaded to their SFTP listener in MFT is not checked in a way other than standard AV. So how much do you trust your trading partners? Just because data is perceived to be part of an automated process and largely system to system it doesn’t mean it should automatically be inherently permitted. Automated checking for malicious payloads or unexpected sensitive data should be performed wherever possible.
One of the themes identified by a HelpSystems survey of CISOs last year was that 46% identified Cyber Security weakness in the supply chain as most likely to cause damage in the next 12 months. On top of that the good folks at The National Institute of Standards and Technology have been saying the same for years!
Moving on to the subject of risk, providing any connectivity to MFT to your end users, how much do you know about the data they’re sharing or uploading to the platform? Does it contain PII, PCI or Intellectual Property?
Enter the Internet Content Adaption Protocol, (ICAP). Running on TCP port 1344 and supported by any MFT platform worth its salt, ICAP uses HTTP messages such as /POST and /GET to pass the data to other platforms to make decisions around that data.
This now gives your MFT server all the power of whatever is at the other end of that ICAP connection. Commonly supported by DLP, AV and Next Gen Firewall products, the platform can evaluate the content, the data type and even associated metadata before responding back to MFT with its evaluation in the form of ICAP and HTTP codes:
| Action | ICAP | HTTP |
| None | 204 | n/a |
| Blocked | 200 | 403 |
| Modified (redaction etc) | 200 | 200 |
By interpreting these codes returned to MFT, platforms can make decisions on how to handle the file. Common outcomes include delete, replace with an error page or send the end user a notification.
By including ICAP services on top of the already achievable security practices MFT gives, it is possible to not just reject data based on name or source, but on what the content is. This way of protecting your MFT allows you to essentially add a data firewall, the content and corresponding attributes being subject to checking whenever data is being moved.
To learn more, get in touch with HANDD, we’ll be more than happy to discuss how integrating ICAP minimises the data security risk of content flowing through MFT solutions.
Email [email protected] or call +44 (0)845 643 4063.
Sam Malkin – Lead Solutions Architect, HANDD Business Solutions
