Critical security vulnerability in your VPN or remote access: the emergency plan for your business

Why remote access software is a particularly critical target

A VPN, a Virtual Private Network, establishes an encrypted tunnel between a device outside the company and the internal network. For that to work, the VPN software must be reachable from the internet. The same applies to other remote access solutions such as remote desktop gateways or remote maintenance tools. This very reachability is the problem: an attacker does not have to deceive anyone or send malware by email. They connect directly to the system, and if a security vulnerability exists there, they are standing in front of an open door.

Then there is its position in the network. Remote access software sits at the boundary between the internet and the company network, where it manages credentials, active sessions, and often the rules governing who may access what. Whoever takes over this system has not captured just any machine but the front door along with the key cabinet. From there, access to servers, file shares, and other systems can usually be extended without much resistance.

The third factor is speed. As soon as a critical vulnerability becomes publicly known, attackers scan the internet automatically for vulnerable systems. These scans do not distinguish by company size, only by whether a system responds. Sometimes very little time passes between the publication of a vulnerability and the first attack attempts. An emergency plan for this scenario is not excessive caution but the logical consequence of the fact that you will have little time when it happens.

How to tell whether you are affected

The most reliable source is the vendor itself. Practically all providers of VPN and remote access software publish security advisories that describe affected versions, severity, and available countermeasures. Many vendors offer an email list or an RSS feed for this, a subscription that delivers new advisories automatically. Subscribe to these channels for every product that is reachable from the internet in your environment. It costs nothing and is the fastest route to solid information.

The second important source is CERT-Bund, the computer emergency response team of the BSI (Germany’s Federal Office for Information Security). CERT-Bund operates a public warning and information service that continuously publishes advisories on vulnerabilities in widely used software and classifies them by severity. There, as everywhere in the industry, vulnerabilities are identified by a CVE number. CVE stands for Common Vulnerabilities and Exposures and is a globally unique identifier for a specific security vulnerability. Severity is usually given as a CVSS score, a scale from 0 to 10 on which values of 9 and above are considered critical.

A third, often underestimated indicator is whether a vulnerability is already being actively exploited. The US cybersecurity agency CISA maintains a public catalog of vulnerabilities known to have been exploited. If your product appears there, the situation is no longer theoretical. Throughout all of this, one small organizational detail has a large effect: define who reads and assesses these advisories. A subscription that lands in an unwatched mailbox warns no one.

Immediate measures in the right order

Step one: establish whether you are affected. Determine which product runs in which version in your environment and compare that with the details in the vendor advisory. For this you need the exact version number, not just the product name, because vulnerabilities almost always affect only specific version levels. Step two: assess the situation. Is an update already available? Is the vulnerability being actively exploited? Does the vendor name a workaround, a provisional countermeasure such as disabling a single feature?

Step three is the most unpleasant one, which is why it should be decided in advance: if a critical vulnerability is being actively exploited and no update exists yet, disconnect the affected service from the internet. A planned outage of remote access for a few hours is annoying and disrupts operations. An attacker inside the company network can paralyze the business for weeks. This trade-off should not be debated for the first time during an incident: decide today who is authorized to order the shutdown so that no one waits for approval in an emergency.

Step four: install the update as soon as it is available. Back up the configuration first so you can roll back if problems occur. Step five is often forgotten: renew credentials. Many vulnerabilities in remote access software allow attackers to read passwords, session keys, or certificates. An update closes the door, but it does not change the locks. After the update, therefore, reset the passwords of the affected accounts, terminate all active sessions, and renew certificates and keys that were stored on the system.

Step six: check whether the attacker has already been there. For critical vulnerabilities, vendors frequently publish Indicators of Compromise, recognizable traces of a successful attack such as specific files, unknown user accounts, or suspicious log entries. Check the system against them or have it checked. If you find something, or if you are unsure, the next section applies from that moment on.

Preserve evidence instead of destroying it

A common mistake after a security incident is well intentioned: the affected system is restarted, reset, or completely reinstalled so that it is clean again. In doing so, you destroy exactly the data that would allow you to determine whether an attacker got in, since when, and how far. Many devices keep logs only in memory, so they are irretrievably lost on a restart.

Therefore, preserve the evidence before any cleanup. Export the logs of the affected system and of the surrounding systems, such as the firewall and the authentication services. If the software runs as a virtual machine, create a snapshot, a frozen copy of the complete system state. For hardware appliances, save at least the configuration and all exportable logs. Also keep a simple incident log: who did what, and when, and what was found. A handwritten note is enough as long as it is complete.

This diligence is not an end in itself. Without preserved evidence, you cannot judge whether personal data is affected. But that is exactly what you need to know: in the event of a personal data breach, the GDPR, the EU’s General Data Protection Regulation, requires notification of the supervisory authority, without undue delay and where feasible within 72 hours of becoming aware of it. An exception applies only if the breach is unlikely to result in a risk to the individuals concerned. A cyber insurer will also want to see evidence. If there is reasonable suspicion of a successful attack, bring in specialists for IT forensics, the forensically sound examination of systems, instead of continuing to work on the affected device.

Prepare for the long term: inventory, update paths, logging

The most effective preparation is an up-to-date inventory: a list of all systems and services reachable from the internet, each with product, version level, responsible person, and the path by which updates are installed. In an emergency, this list determines whether answering the question of whether you are affected takes minutes or hours. Review the inventory at regular intervals and include systems that business departments have procured on their own, known as shadow IT.

Clarify the update paths before you need them. Who is allowed to update, how long does it take, and is there a proven way back to the previous version if the update causes problems? An emergency is the worst possible moment for the first update in years. If you patch regularly, that is, apply vendor fixes promptly, you keep the path short and well practiced.

Also make sure logs are not stored only on the device itself. If logs are continuously copied to a separate, central collection point, the traces survive even if the device is compromised or rebuilt. Retain these logs for several months, because attacks are not always noticed immediately. Add multi-factor authentication to remote access, a login with a second factor in addition to the password. It does not prevent every type of vulnerability, but it makes stolen passwords far less valuable.

Finally, the emergency contact sheet: contact details for vendor support, IT service provider, insurer, and data protection officer, plus the decision on who may order the shutdown of remote access. This sheet should be printed out and kept in a place everyone knows, because once remote access is shut down, a document in the company’s internal system is of little help. Walk through the scenario at the table once a year; one hour is enough.

What you can handle yourself and where help makes sense

Much of this plan can be done without specialist knowledge: subscribing to vendor advisories and CERT-Bund, maintaining the inventory, defining responsibilities and emergency contacts, making the shutdown decision in advance. That takes discipline and a few hours per year, but no in-house security specialists.

The assessment during an incident is more demanding: whether a vulnerability is exploitable in your specific configuration, whether traces point to a successful attack, and what a clean recovery looks like. Honesty about your own capabilities pays off here, because a false all-clear ends up costing more than an hour of external support. If you work with an IT service provider, clarify in advance what is agreed for emergencies: who monitors vendor advisories for your systems, which response times apply, and how is availability outside normal business hours arranged? These three questions can make a difference of hours in an emergency.