The Most Important Patch You’ll Never Have to Deploy

September 1, 2020

Applying patches to software in networking devices is so common that most enterprises have a structured procedure on how to do it. The procedure details things like how to monitor for the availability of necessary patches, how often to apply fixes to devices, how to test patches before applying them, and when to apply the new software to minimize possible disruption.

Patching has become so common that we just assume that’s the way it has to be. “Patch Tuesday” has us expecting fixes to problems every week. In reality, patching is an artifact of the way all appliances are built. If we eliminate the appliance architecture, we can eliminate the overhead and risk of patches.

VPN Vulnerabilities Jeopardize Remote Access

Of course, some patches are more important than others. Anything pertaining to security should be considered a priority in order to shut down the vulnerability as soon as possible.

Last year CERT issued a warning about security vulnerabilities in various VPN devices that were storing session cookies improperly. One vendor after another issued a report of this and other problems they found in their own products:

Since then, there has been no shortage of reports of weaponization and use of these vulnerabilities by state actors:

Available Patches Might Not Get Applied

Admirably, the vendors all responded quickly to create patches and put them out for the public to apply. Their assumption was that users of the gear would acquire the patches and apply them right away to secure the remote access appliances. However, that’s not always the case.

Many enterprises have change control processes that add time to the patching schedule. Maybe they want to test the patch in a lab first, or wait until the next scheduled patch day. Taking a VPN offline – even for a short time – in 2020 is problematic, as so many people are now working from home. VPNs have gone from being ancillary devices to being business-critical as the entire staff must use remote access for a while.

Existing devices aren’t the only ones affected by vulnerabilities. Sometimes new devices just unpacked from the box have been shipped with a vulnerability or two, and the customer must patch the software to make it more secure. The challenge for many network managers is that patching isn’t the first thing – or even the tenth thing – to do when deploying new hardware. That VPN could easily be deployed and up and running for a while before anyone thinks to see if it needs a patch.

The alternative is to set up the device in a staging area and tend to the configuration before it’s ever placed into service. Many organizations don’t have the time or facilities for staging new equipment like that.

Whatever the reason for not immediately applying a software patch, there’s a window of opportunity for attackers who can strike while the vulnerability is still there. Cato security researcher Avidan Avraham recently wrote about the pervasiveness of cyberattacks and how all businesses are becoming targets when they are connected to the Internet. It’s more critical than ever to shut those windows of opportunity before any harm can be done.

Cato Relieves Customers of the Patching Process

From time to time, Cato also has to push patches out. The difference is, we don’t expect the customer to deploy the patch—our engineers do it.

As a SASE platform, most of Cato’s technology resides in the cloud, so there’s less for customers to take care of themselves. Although we do have an on-premise appliance called a Cato Socket, it arrives at the customer location completely hardened. It’s much more difficult for an external actor to detect the device, let alone compromise it. As soon as the Cato Socket is plugged in, it automatically downloads and applies any patches it may need.

Thus, we do the patching on behalf of our customers, reducing their administrative overhead to stay on top of patches.

Patch Tuesday for Cato customers? Nope, and not any other day of the week.

Peter Lee

Peter Lee

Peter is a Security Engineer for Cato Networks. He brings 25+ years of security and networking experience to bear while helping our UK customers design, deploy and operate their next-gen Cato SASE/SDWAN infrastructure, and has a global role as a subject matter expert for APIs and Analytics.