Vulnerability management: Control critical vulnerabilities in firewalls and VPNs

What is vulnerability management?

Vulnerability management is the structural process that allows an organisation to have technical vulnerabilities:

1. detected;
2. assess;
3. prioritizes;
4. dissolves or mitigates;
5. checks;
6. And keep following.

So it's more than just a periodic vulnerability scan.

A scanner could produce hundreds or thousands of findings. The real question of management is:

What vulnerability is the greatest risk to our organisation and who should do something with it?

For this purpose, technical information should be linked to the context of the organisation.

Patch management and vulnerability management are not the same

Patch Management is about checking the installation and management of software and security updates.

Vulnerability management is wider.

A vulnerability can be addressed, for example, by:

• install a security update;
• temporarily disable a function;
• to retrieve an Internet management interface;
• restrict network access;
• adjust a configuration;
• establish additional monitoring;
• to phase out a system more quickly.

So patching is one possible treatment. Vulnerability management determines which vulnerability is first addressed and which measure is appropriate.

Why firewalls and VPN systems deserve extra attention

A workplace with a vulnerable application and an internet-facing VPN gateway with the same CVSS score do not automatically have the same risk.

VPNs, firewalls and other edge systems are interesting for attackers because they often:

• be directly accessible from the Internet;
• handle authentication;
• providing access to internal networks;
• processing network traffic;
• have management rights;
• contain configuration data and sometimes credentials;
• have a central position in the security architecture.

When an attacker can take over the system that must protect access to your network, the impact can be great.

CVSS 10 doesn't automatically mean everything is instantly red

CVSS is useful, but not a complete risk analysis.

When prioritizing, you should at least look at:

• severity of vulnerability;
• available exploit code;
• active abuse;
• simplicity of abuse;
• Internet accessibility;
• presence of the product in its own environment;
• rights or network access to be obtained;
• business impact;
• available mitigations;
• need to check for previous compromise.

A CVSS 10 vulnerabilities in an internal test system may be a different priority than a CVSS 9.8 vulnerabilities in the VPN gateway that allows employees and suppliers to enter the network.

Vulnerability management is risk-driven, not just score-driven.

Active abuse changes priority

When exploitation is actually observed, vulnerability is no longer theoretical.

That usually means:

• shorten patch mines;
• organising emergency changes;
• consider temporary mitigations;
• intensify logging and detection;
• assess whether the system may already be compromised before patching.

A regular monthly patch cycle may then be insufficient.

Patching is sometimes just step one.

In case of vulnerability that is already actively abused, only installing the update is not always sufficient.

The patch prevents future abuse of the vulnerability involved. He does not answer the question whether an attacker has already had access to it.

Therefore, check with relevant systems also:

• authentication and management logs;
• unknown accounts;
• unexpected configuration changes;
• new scripts or files;
• abnormal processes;
• outbound network connections;
• supplier IoCs;
• suspicious management activities;
• changes to firewall and VPN rules.

In case of indications of compromise, incident response should be initiated. Read Also Hacked? What now? First steps after a cyber incident.

Asset management is the basis

You can only assess a vulnerability quickly if you know that the affected product is present.

For critical infrastructure you need to know at least:

• product and type;
• location;
• owner;
• administrator;
• software or firmware version;
• support status;
• Internet exposure;
• function within the network;
• critical business processes;
• responsible for patching;
• monitoring;
• supplier or maintenance partner.

In addition, for internet-facing systems, it should be clear which services are actually accessible from outside.

A CMDB or spreadsheet tells what is present according to the administration. An external technical check tells what is really visible. Those two images are supposed to fit together.

Know what's on your Internet

Many serious vulnerabilities are in:

• VPN gateways;
• firewalls;
• routers;
• mail servers;
• Remote access products;
• management interfaces;
• web applications;
• File transfer solutions.

For months, a forgotten application or old management interface can be excluded from regular patch processes.

Therefore, periodically check:

• public IP addresses;
• DNS records and subdomains;
• Open gates;
• internet-facing services;
• VPN and management interfaces;
• TLS certificates;
• cloud assets;
• old or temporary systems.

The question is not just “What have we recorded?”, but also .

Vulnerability management in seven steps

1. Map Assets

Know which systems, software and network equipment are present.

2. Find Vulnerabilities

Use reliable vendor advisories, NCSC warnings, vulnerability scanning and relevant threat intelligence.

3. Determine the actual exposure

Check that the product is present, which version is used and that the vulnerable function is active and accessible.

4. Prioritize by Risk

Combine technical seriousness with operation, accessibility, company impact and available measures.

5. Treat vulnerability

Patch, change configuration, restrict access, mitigate or phase out the system.

6. Check the solution

Verify that update or configuration change has actually been successfully performed.

7. Check for compromise if necessary

Especially in the case of active abuse or prolonged exposure. Capture what was checked and what the outcome was.

Who's responsible?

This should be clear before an incident.

For example, record:

• who receives advice;
• who decides if you're hit;
• who may approve an emergency patch;
• who is implementing the change;
• who controls successful installation;
• who assesses whether incident investigations are necessary;
• who reports to management or board.

In critical systems, ♪ It's gonna keep that up with ♪ insufficient.

Sold out to an IT supplier?

In case of urgent vulnerability, don't just ask:

♪ Did you patch? ♪

Question also:

• do we use the affected product?
• Which version do we use?
• Was our configuration vulnerable?
• Was the system accessible from the Internet?
• when was the update executed?
• how has successful installation been checked?
• Has anyone looked at any indications of compromise?
• Which logging is available?

A general SLA stating that updates are being performed does not automatically guarantee that a specific critical CVE has been handled in time.

Subcontracting of execution is not the same as outsourcing of responsibility.

Two current examples: Cisco and Check Point

In September 2026, serious vulnerabilities were revealed in systems that are precisely security functions.

With Cisco Secure Firewall Management Center was actively confirmed abuse of critical authentication vulnerabilities.

With Check Point VPN Products warned the NCSC of two critical vulnerabilities that can be executed without authentication code. The NCSC expects rapid attempts at widespread abuse.

Read the current warnings about Cisco FMC and Check Point VPN.

The products differ. The management question is the same:

Do you know if you are using the product, do you know if you are vulnerable and can you act with any certainty?

What should management know about this?

A board member doesn't need to know CVE numbers by heart.

However, he or she may expect the organisation to be able to answer questions such as:

1. Do we know which critical systems are accessible from the Internet?
2. Can we determine within a few hours whether a new serious vulnerability applies to us?
3. Do we have deadlines for critical and actively abused vulnerabilities?
4. Is it clear who can decide on an emergency change?
5. Can we prove that our supplier actually patched?
6. Do we check if we've been hit by active abuse?
7. Do we report on any outstanding critical vulnerabilities?

When those answers are not directly available, the problem is often not in the missing patch. The problem is then in Governance, ownership and insight. The NIS2 obligations and the Dutch Cybersecurity Act make that board-level responsibility extra concrete. One NIS2 workshop on risk management helps management and IT to discuss exposure, scenarios, ownership and decisions openly.

ISO 27001 and vulnerability management

ISO 27001:2022 explicitly addresses the management of technical vulnerabilities in Annex A 8.8 — Management of technical vulnerabilities.

An organisation shall obtain information on technical vulnerabilities, assess its own exposure and take appropriate measures.

This means that vulnerability management is directly linked to asset management, risk management, change management, patch management, supplier management, logging/monitoring and incident management.

A vulnerability scanner alone does not make you demonstrably resilient.

Summary

New vulnerabilities are inevitable. That doesn't mean that every CVE has to cause a crisis.

A grown-up organisation knows:

• which systems are present;
• which of them are accessible from the Internet;
• the vulnerabilities that are relevant;
• which must be resolved first;
• who is responsible;
• and how the measure is checked for effective operation.

Good vulnerability management prevents any critical vulnerability from starting again with the question:

Do you want to have the operation of measures independently evaluated? Look at the Cyber Security Audit.