The problem is not sophisticated attacks
Most successful attacks do not use advanced techniques or unknown vulnerabilities: they exploit known vulnerabilities, often fixed months earlier by the software vendor, on systems that nobody has updated. Patch management, the process of applying these updates, is one of the least visible and most decisive activities in cyber security.
The life cycle of a vulnerability
When a vulnerability is discovered, it is given a public identifier (CVE) and a severity score. The vendor releases a fix, often quickly for the most serious flaws. From that moment on, however, the fix itself becomes a public clue about where to look: by analysing the patch, it is often possible to work back to the original vulnerability and build an attack that exploits it, sometimes within a few days. Every system still not updated is then a known target, not a theoretical risk.
Setting priorities, not updating everything at once in the same way
Updating every system instantly is not realistic, nor is it the right strategy: an update also needs testing, so that a compatibility problem does not take down a production system. You need a way of setting priorities.
| Situation | Priority |
|---|---|
| Critical vulnerability, system exposed to the internet, known exploit in circulation | Immediate, even outside the regular maintenance window |
| Serious vulnerability, internal but central system (server, domain controller) | High: within a few days, with a quick test |
| Medium vulnerability, non-critical internal system | In the regular maintenance cycle |
| Minor updates, with no known associated vulnerability | Scheduled, according to the standard calendar |
Severity alone is not enough: a critical vulnerability on an isolated system with no internet access can matter less than a medium one on an exposed system. It is the same approach to reading a report described in the guide to vulnerability assessment and penetration testing: here the vulnerability assessment flags what needs updating, and patch management actually fixes it.
A process that works, in practice
- Keep an up-to-date inventory of systems, operating systems and installed versions: you cannot update what you do not know you have.
- Set regular maintenance windows, and a procedure for urgent fixes that cannot wait for the next window.
- Test before rolling out everywhere, even if only on a small group of representative systems, to catch compatibility problems.
- Prepare a rollback plan: what to do if an update causes an unexpected problem in production.
- Check that the update has been successful on all the intended systems, not just that it has been rolled out.
End-of-life systems are a risk that grows on its own
An end-of-life operating system or application no longer receives security fixes: every new vulnerability discovered stays open for ever. It is a risk that needs no mistake to materialise: the passing of time is enough. It must be dealt with as a priority, not left alone "because it has always worked anyway".
Quick checklist
- I have an up-to-date inventory of systems, operating systems and installed versions;
- I know which of my systems are directly exposed to the internet;
- there is a procedure for applying the most critical fixes urgently, outside the regular cycle;
- updates are tested before being rolled out to all systems;
- I know which of the company's systems are end-of-life, and I have a plan to replace or isolate them;
- I check that the updates rolled out have actually been applied, not just sent.
In short
Most attacks exploit known vulnerabilities that have already been fixed: patch management closes them before they become a target. It needs priorities based on severity and exposure, not indiscriminate updating, and constant attention to end-of-life systems, whose risk grows on its own over time.