Supply chain disaster: Do you need an MFT dev environment?

The reasons why you need an MFT dev environment

MFT dev environment - lorries in supply chain disaster

 

In all the years we’ve been working in file transfer, there have been a few occasions when we’ve witnessed the financial impact and reputation damage a system failure can have. This article looks at:

 

  • Why you should think twice before testing in a live environment;
  • When you need to consider a development (dev) environment for your Managed File Transfer (MFT) solution;
  • Details of the six stages for testing and development.

“A few years ago, one organisation was developing workflows in a live environment, and broke other automated processes. The system was down for just a few hours, but the impact was huge. This business supplied products to retailers across the country, but were unable to access the order information. The lorries couldn’t leave the factory and delivery drivers had to be paid overtime. Worse still, the retailers were left out of stock, consumers bought other brands and some ended up staying with that brand. The impact on the business’ finances and reputation were catastrophic.”

 

Richard Auger, Pro2col technical consultant

This particular example could have been prevented if the IT team were developing in a test environment, instead of a live environment. But so many organisations only have a live MFT production licence. That might be to save money, or because decision makers just don’t think a file transfer server needs a test licence. But we know an MFT system is doing so much more than transferring files, so if you have any workflows involved, you need to reconsider.

Is a dev environment business critical?

This will depend on the value of the data your system is handling. Is it critical to business processes? Do you risk breaching service level agreements (SLAs)? Or will you simply not be able to operate, like the example above? While you may be able to send files by some other method for a few hours, it isn’t viable for a sustained period.

You also need a change control policy to meet ISO27001 requirements. While it is down to you to determine the right policy for your unique set of circumstances, example ISO best practice advocates testing in an isolated, controlled and representative environment. Similarly ITIL requires an organisation to follow both ‘change management’ and ‘release and deployment management’ processes from non-production to production systems. It’s an old IT joke that in weaker, less secure environments TIP doesn’t mean ‘Transfer into Production’ – it ends up being ‘Test in Production’ instead.

So to avoid disrupting your system when deploying new releases, building workflows or making other changes, you should follow these six stages for testing, developing and transfer into production:

  1. Sandbox, or experimental environment: This is a local environment no one else can access, where the developer has a working copy of the code. Here they can try it out and change it without putting it live. This environment will typically be an individual developer’s workstation. Once they are happy with it the developer would submit the code to the repository for the next stage of development. Most MFT solutions by default don’t have a sandbox but you can sometimes set it up by installing the software onto a private virtual machine.
  2. Development or integration environment: This is a clean environment where you test how your code is interacting with all the other bits of code associated with the system. The code itself doesn’t get changed in this environment – updates are made to the working copy back in the sandbox and resubmitted. When ready, the developer accepts the code and it is moved to the test environment.
  3. Testing: This is the environment to test the new or changed code, either manually or using automated techniques. You may have different test environments to focus on different types of testing. The developer looks at how it interacts with and impacts other systems and tests performance and availability. If you are upgrading, for example, this will show how your system will behave once the upgrade is in place. From here, the code can be promoted to the next deployment environment.
  4. User acceptance testing (UAT) or quality assurance (QA): In this stage users will trial the software, making sure it can deliver against requirements. Stress testing is also carried out in this stage.
  5. Pre-production, or staging environment: This final stage tests in conjunction with all the other applications in the infrastructure. The aim here is to test all installation, configuration and migration scripts and procedures. For example, load testing happens here. It’s really important that this environment is completely identical to the production (live) environment. All systems should, for example, be the same version.
  6. Production or live environment: Transfer into production – or TIP – is the final stage, bringing the updates live. This is the environment that users actually interact with. This can be done by deploying new code and overwriting the old code, or by deploying a configuration change. Some organisations choose to deploy in phases, in case of any last minute problems.

If you follow these steps you can be confident that any upgrades to the production environment will be completed reliably and efficiently. But if your budget or internal policy won’t allow you to invest in all of these, we would recommend at least a test environment, which should be an exact copy of the production environment.

All our vendors offer test licences at reduced rates. If it’s time to get this set up for your MFT solution, get in touch now. You can contact us via the website or by emailing your account manager.

Interested in a file transfer solution?

What do the new SSL and early TLS requirements mean for my file transfer solution?

What do the new SSL and early TLS requirements mean for my file transfer solution?

PCI DSS is the security standard for processing and storing credit card information. From 30th June 2018, organisations can no longer use SSL and early TLS to meet the PCI DSS standard. This blog post will remind you of the requirements and what this means for your file transfer solution.

Earlier this year we reminded you that Secure Sockets Layer (SSL) and early Transport Layer Security (TLS) are no longer considered secure protocols. It’s because of the growing number of attacks and vulnerabilities, with online and e-commerce the area most at risk.

From 30th June 2018 organisations will need a more secure encryption protocol in order to safeguard payment data and meet the PCI DSS standard. With just over a week to go, we wanted to share these key points, so you can check you have everything in place and understand what it means for your file transfer solution.

What do I need to put in place?

Essentially, you need to have a secure alternative – both at the network layer and at the data protection layer – and disable any fallback to SSL or early TLS. Your two options are as follows:

1. Migrate to TLS 1.2

The PCI council make a clear recommendation that you transition to TLS 1.2:

“TLS 1.2 is considered secure and is the recommended option from the council.”

SSL and Early TLS Migration webinar, Feb 2018.

TLS 1.1 is a more complicated option because it is possible to meet the requirements for strong cryptography, but it depends on the configuration, algorithms, strength of keys and other aspects of the implementation.

2. Compensatory controls

SSL and early TLS are not considered strong cryptography so they cannot be used as a security control for PCI DSS. You could add alternative security controls that remove the reliance on SSL and early TLS. Encryption would need to be in place to secure the transmission before it is sent using SSL or early TLS. Eg: at the application layer.

Exception for POI devices

This exception is in place because Point-of-Interaction (POI) terminals are not as susceptible to the vulnerabilities as browser based systems. If the device is built and configured in a way that’s not susceptible to the known vulnerabilities, it is possible to keep using it. You need to contact the vendor or support provider for that terminal, who can evidence this.

The device will still need up to date patches, must not use weak cipher suites or unapproved algorithms (eg: RC4 or MD5) and you must continually check that it hasn’t become susceptible to any new vulnerabilities. You should also have a migration plan in place that you can execute at short notice, should the device become susceptible. Any new devices should be configured to TLS 1.2.

You can find out more information on all the topics covered in this blog by watching the video from the PCI Security Standards Council.

What does this mean for my file transfer solution?

If you are running a file transfer solution and have kept it up to date, there is a good chance you won’t need any major changes. All the current versions from the main MFT vendors support TLS V1.2 and many default to only have TLS enabled.

Some products have PCI compliance scans built in, which will warn you if you are running SSL v3.0. It may not differentiate between TLS V1.0 and V1.2 though, so you will need to do a manual check. If you have a support contract with Pro2col, raise a support ticket and one of our technical consultants will find out if your solution is configured for TLS V1.2 or not.

If you are running an older version of your file transfer solution, you may need to upgrade. Again, Pro2col can advise on the process and our professional services team have experience getting out of date software up to the latest version.

If you are running an older SSL certificate built using 512-bit or 1024-bit key sizes, it is worth renewing it. The recommendation is now to use 2048-bit or greater.

To compare Managed File Transfer (MFT) solutions with PCI DSS compliant features, complete the Managed File Transfer Comparison Report. This will recommend and compare solutions meeting your specific requirements.

Interested in a file transfer solution?

Monsoon Selects Ipswitch for Secure, Managed File Transfer

Monsoon Selects Ipswitch for Secure, Managed File Transfer

full_monsoonMonsoon, one of the world’s leading retail outlets for fashion and accessories, has selected Ipswitch File Transfer’s MOVEit suite of managed file transfer (MFT) solutions to add security and audibility for file transfer between its international operations.

“We needed to replace our existing FTP products with a file transfer solution that would meet all our security and compliance requirements, and improve our governance over file and data transfers with our subsidiaries, partners and suppliers,” said Anish Shah, Operation Systems Manager, Monsoon. “We also needed a solution that would cleanly integrate with our existing systems, especially for secure banking transactions. MOVEit DMZ and MOVEit Central ticked all those boxes and provided us with an intuitive solution with the level of visibility we required.”

Monsoon’s IT team required three secure SFTP servers for its International Operations, Operations Data Interchange and Secure Banking Transactions. It was completely explicit in its demands – ultimately to give end users a simple and secure way to quickly transfer files with other people, but also the ability to manage and automate all file and data movements and workflows, ensure privacy and confidentiality with end-to-end encryption and non-repudiation and gain visibility and insight with extensive and customisable reporting.

“MOVEit DMZ and MOVEit Central were able to provide an extremely secure environment for all our data interactions as well as a single web interface for setting up and managing the data flow around the system,” said Shah. “We have been so impressed with the MOVEit products that we have subsequently deployed them to support our e-commerce site.”

 

“With hundreds of data breaches occurring over the past few years, some with multi-million dollar consequences, organizations must have the right solutions and practices in place when transferring sensitive information,” said Loic Triger, vice president of International Sales, Ipswitch File Transfer. “Companies trust Ipswitch to help them safeguard confidential information and the MOVEit suite can deliver an extremely secure MFT solution that provides three hundred and sixty degree visibility into global file transfer activity, coupled with automated controls and policy enforcement.”

Ipswitch’s MOVEit suite of products is the world’s most comprehensive and easy-to-use secure managed file transfer solution. The technology goes well beyond traditional file transfer by combining best-in-class encryption with global visibility into all file transfer activity across the business. The system streamlines data transfer workflows, provides a quick and easy way to exchange sensitive information regardless of file location or size and automatically authenticates employees, business partners and customers based on internal directories and databases.

If your company would like to know more about Ipswitch File Transfer’s secure and managed file transfer solutions, Pro2col their UK representative is able to provide you with on-site demonstrations and fully featured evaluations.  Contact Pro2col on 0333 123 1240 for assistance.