Which file transfer infrastructure is more secure: on-prem and cloud-based?
If you instantly answered "on-prem," you're not alone. It's the dominant line of thought. Enterprises demand it. LLMs reflect it (until you push them for evidence). Experts fall back on it. But that doesn't make it right.
On the face of it, it seems obvious that on-prem infrastructure is more secure. You have full control of the machines with direct, physical access. If one or more components of the infrastructure malfunction or are compromised, you can take them offline. Software, upgrades, and security hardening are all under your control.
Which is also the weakest point. In fact, it's such a weak point, that we'll argue that modern cloud architecture is actually more secure for file transfer infrastructure—but only when done right.
So how can this be? We'll start by covering what most organizations are actually looking for, then examine some of the serious flaws of on-prem file infrastructure and explain how modern cloud architecture can close these security gaps while delivering better performance and more flexibility.
What kind of security do companies actually need?
The supposed security of on-prem has led to many companies having on-premise mandates, even when the actual features and controls they're after aren't related to the type of infrastructure.
Usually, the actual needs boil down to a few recurring requirements:
- Full-data control. Files need to be locked down; company files can't be accessible by a third party like a cloud provider. There might also be uncompromising data sovereignty or compliance requirements. Security Controls like RBAC are also important to control access.
- Compliance. One or more compliance frameworks have strict requirements. Breaking these could have massive ramifications and fines, and keeping everything in-house means they have a full picture of the risks.
- Detailed logs. For auditing purposes, it's essential to know where files are located, where they've moved, and who's had access. When files never leave the infrastructure, it's much easier to be able to answer these questions with verification.
- Remediation. If there's a system compromise, the damage will be limited and controllable, and remediation and backups can be handled onsite. Compromised components can be isolated and shut down, so potentially the whole system may not need to go offline.
For a long time, the only solution was to handle the infrastructure in-house in order to have full control over these elements.
However, technology, cybersecurity, and data privacy in the cloud aren't the same as they were 10, even 5 years ago. There's been a strong push towards using the cloud and its benefits like limitless scalability, better usability, and no infrastructure management while still retaining control over how data is handled and processed.
Now, the cloud can handle all these major concerns as well, and is missing the big, vital security flaw of on-prem infrastructure.
There are no impenetrable systems
Ideally, an organization's cybersecurity would be so comprehensive that threat actors wouldn't be able to get access in any way. But this doesn't reflect how security works in the real world.
The unfortunate truth is that no system is completely immune to exploits, vulnerabilities, or hacks. A decent amount of attacks are "zero-day exploits", meaning that the vulnerability was previously unknown until the attack happened. And while in some cases better protections could've been put into place (easy to say in hindsight), it's extremely challenging to combat something you don't know even exists.
There's simply no way to make any system completely impenetrable, because new threats or breakthroughs could happen at any moment. Instead, the recommended and best option is to follow known security best practices and to have a solid recourse in place to protect and recover data and adapt to the new conditions.
If you want proof of this, look no further than the CISA infiltration event. CISA, the Cybersecurity and Infrastructure Security Agency, is a part of the US Department of Homeland Security and is responsible for cybersecurity and infrastructure protection for the government. They publish exploits and vulnerabilities and give recommendations to improve cybersecurity, both to government bodies and the general public.
And they were hacked. A vulnerability within the Ivanti tool was exploited, allowing threat actors to gain access to two separate systems. While CISA claimed that no data was stolen, the fact that they could be part of a breach at all shows how difficult it is to fully lock down systems. Impossible might be the better word.
Zero-day exploits sound scary, and they are. But they aren't the cause of most organizations' file transfer infrastructure being breached. When you hear about a high-profile breach in file transfer infrastructure like a Managed File Transfer (MFT) exploit, it's more likely a result of the inherent flaw of on-premise security: keeping systems up to date.
The big on-prem security flaw
Yes, on-prem infrastructure can be locked down. But in reality, it often isn't, even when it's meant to be.
The problem is that many organizations have trouble keeping the systems up to date. If you were to take a look at some of the major MFT breaches in the last few years, you'd notice that there's an unusually high number of exploits that had a fix deployed pretty quickly.
This is such a problem that the Ponemon Institute suggests that 60% of organization breaches could've been stopped if the patch was applied. That is a huge percentage.
It also reveals the major problem with the self-update paradigm. Most organizations just don't update in a timely fashion. But why is this the case? No, it's not just that they were too lazy to do it. Instead, it usually falls into one of two categories: concerns about the resources required to update, and concerns about breaking something critical.
Resource concerns
One reason patches aren't applied when they should be is because the organization is worried about the time, effort, and potential revenue loss that it could take to apply them.
Maybe they require too many machine resources. Maybe the person best-qualified to apply it is unavailable. Maybe the opportunity cost vs risk was deemed too high. Whatever the reason, the patch exists and a lot of breached companies just... didn't add it in time.
"Getting more resources" isn't always an option. Sure, more machines and more software can be added. But those systems then have to be managed, a cycle that can quickly balloon in costs.
The missing resource can also be a person. In the Ponemon study, 2/3 of respondents claimed they didn't have enough staff to patch fast enough to prevent a breach. Other times, the people (or person) who know the ins and outs of the on-prem system aren't available. And if they aren't around to fix it, others might not step in for fear of breaking something vital, which is the 2nd major concern.
Compatability concerns
The second big reason why organizations don't patch systems is because of the fear of breaking something vital. With software designed for on-prem systems, updates are typically released in stages with significant changes. These changes could update configurations and support for different systems, or restructure the way elements are configured.
Because of this, updates are usually thoroughly tested and rolled out cautiously. Once they've confirmed that nothing vital is affected (or necessary reconfigurations are done), they can be rolled out across the entire infrastructure. Depending on the extent of the changes, this can be a lengthy process. Sometimes, too long, resulting in a breach due to a vulnerability.
Other times the entire working file transfer infrastructure might be held together seemingly by magic, and messing with it might cause the entire thing to fall apart. It can be especially risky if the old version has custom integrations or scripts that you or your partners rely on.
Once more, this can circle back to the resource concern. In order to make sure that the entire infrastructure won't crumble because of being incompatibilities, someone needs to expend the resources to test it out. And if those resources aren't readily available, the update gets delayed.
Both of these concerns are intertwined, and there's not always a simple way to avoid them. But with a modern cloud infrastructure, it's possible to avoid both of these concerns.
What do we mean by "modern cloud infrastructure"?
It's important to clarify that the cloud isn't inherently more secure than on-prem infrastructure. And to be fair, in many cases, it's not. File transfer infrastructure simulating on-prem software but running "in the cloud" on VMs isn't more secure than that same software on physical machines that are directly accessible by the organization.
It's simply offloading resource usage to somewhere else. But the same flaws still exist.
Where the difference comes in is when the cloud infrastructure is architected in such a way that it has additional safeguards, redundancies, monitoring, and backups that are inherent it's cloud characteristics. This is one of the major differences between cloud and SaaS file transfer infrastructure.
Cloud vs SaaS file transfer infrastructure
There are two ways to think about cloud file transfer infrastructure. The first is a straightforward "using somebody else's computer." It's essentially a single machine running specific programs or processes and using those resources instead of being tied to your local machine. It would be something like setting up a VM in AWS or VMware. While this approach can expand and free up resources, it's still tied to the provisioned machines, so it comes with similar limitations. Add more or better machines, get more power, and better performance.
Providers that offer this cloud file transfer infrastructure might automatically set up those machines for you, but you'll still be limited by their setups and the number of licenses you have. You might be able to improve performance by tweaking advanced settings, but you ultimately are in charge of scaling yourself.
Contrast that to a true SaaS file transfer infrastructure with no machines or servers to manage, and it's actually quite a big difference. Machines will be automatically used and provisioned in the background and settings will be optimized for you to deliver the best performance. The scaling is automatic and will usually be included in your price
So how do they manage this? A common way is through a shared hosted infrastructure. With this approach, a set of machines is reserved from the infrastructure provider (Digital Ocean, AWS, etc.) for that specific provider that no one else can access. And although they're "shared" resources, they're still isolated; getting access to Company A in some way provides no access to Company B or any other separate environment.
With this architecture, setup and onboarding are incredibly fast, but it offers many security advantages as well.
Security advantages of SaaS file transfer infrastructure
Automatic patches and updates
This is both the biggest advantage and the most straightforward. As mentioned above, unpatched systems where a fix was already available are present in many data breaches. Automatic updates can virtually eliminate this concern.
So why don't the major concerns of patching apply to SaaS file transfer infrastructure? The reason is in how releases are handled. In SaaS, releases can be much more iterative, and they'll apply automatically. Small updates are happening all the time, and when functionality changes, there will still typically be support for the previous iterations (but maybe not creating new ones in the old method).
Nobody needs to spend the time and effort to test and patch systems, and what was working before will still work in most cases. The updates happen automatically.
With the way SaaS file infrastructure works, multiple different machines work together to form your infrastructure. Ones that are in reserve can then be updated, and once updated, they become active, and the previously active machines can then have their turn to update. To the end user, this process is seamless and invisible. Updates are nearly instant as a result, so these exploits through "patched vulnerabilities" are extremely rare in comparison.
Now there are some on-prem systems that claim to have "automatic updates", but a lot of times this is a half-truth. They're automatic in the sense that they might be downloaded on their own, but most of the time they aren't applied automatically. And they realistically can't be, because they often require downtime to apply, and business-critical transfers can't be interrupted unexpectedly.
Think of these other "automatic updates" like OS updates you get for your phone. The phone can download them, but they'll wait to actually apply them until late at night when the phone is on a charger. And when the system never has a "late at night" free time, finding the opportunity to apply the update can be extremely difficult.
SaaS file infrastructure avoids the issue with small, iterative changes. SaaS also has another trick up its sleeve, and this one enhances security as well: containerization.
Containerization
Containerization is running software by combining small individual "containers" of code that run consistently across different devices. With this method, software isn't deployed directly on servers, and these microservices are fast to deploy and easy to update individually.
These containers are scanned for updates and vulnerabilities as part of the service provided by its container registry. And, containers can be updated and deployed frequently with minor changes.
But it has security benefits too.
For simplicity's sake, suppose that there were 100 containers to create a service. Then, a bad actor manages to compromise one of these containers and get full access. Since these containers are monitored, this is likely to trigger an alert. And whether or not it does, once the infiltration is discovered, that one container can be shut off, isolated, and worked on without impacting the other 99 when configured properly. This may result in some lack of functionality briefly, but a lot of times, the service as a whole will continue to operate.
Of course, there's still the potential for containers to be overprivileged, misconfigured, or for bad actors to "break out" into the wider system, but it's much less likely than with on-prem, where they often gain much greater access on a breach.
When combined with automatic updates, containerization helps keep the whole SaaS file transfer infrastructure secure while protecting against evolving threats.
And Couchdrop goes one step further with a unique way of handling secure file transfers.
Unique Couchdrop benefit - No temporary storage layer
One way that Couchdrop is different even in the SaaS infrastructure space is that the platform doesn't store your files (as long as you aren't storing them on Couchdrop's hosted storage). Others in the space will integrate with your storage and allow you to send files between them, with the caveat that they are temporarily stored in their own infrastructure on a temporary layer (typically somewhere like an S3 bucket).
Couchdrop takes a different approach. Instead, you connect your platforms, set up transfers, and Couchdrop "streams" files between endpoints. This means you have full control over your data at all points and get even greater protection than when using other SaaS infrastructure. By default, the support team would be able to access your account for troubleshooting, but admins can also disable this access in security settings if they wish.
All of this and Couchdrop is incredibly simple to use. Setup takes seconds and the modern interface makes setting up transfers easy. You get security that exceeds most on-prem setups with the speed, performance, and compatibility of SaaS.
Ready to see the difference? Give Couchdrop a try by starting a free trial now.