Vulnerability management: not just for scanning known vulnerabilities
It is springtime!
... and especially here in Finland it is probably the most influencing season of them all with the sun pushing away all the darkness. Perhaps because of that, I also woke up today with new motivation to write something here in ITworld.
So hello again everyone! ;)
Vulnerability management is like a spring clean-up!
Like the melting snow reveals all the trash that it has hidden all winter, vulnerability management processes also aim to reveal things in hiding, so I thought that would be a timely topic to re-start blogging with. But I will do that with a new spin! I will tell you how you can extend your current practises to finally also look for those zero-day vulnerabilities as well!
As you all probably know, vulnerability management is a process (and lot's of techniques and tools) of finding the vulnerabilities in your system, code, network architecture and so on. Conducting it manually is possible, but requires thorough knowledge of the actual traffic, interfaces, attack vectors and protocols. It also requires tedious planning and follow-up so that discovered vulnerabilities eventually get fixed by deploying the latest patches, or kicking those unmaintained legacy boxes forgotten into the network, to where they belong (trash).
But when thinking of vulnerability management, people often limit their focus on finding out if their system has a soft spot for certain known vulnerabilities. Known vulnerabilities have already been found by someone, and reported to the public. The best way to keep up-to-date with the latest vulnerabilities is to subscribe to regular security updates from comprehensive vulnerability databases or email-lists. These sources often leave you to simply determine, which security issues are applicable to you.
But What About Those Zero-Days?
Vulnerability management is, however, or at least should be, much much more than looking at old stuff, the known stuff. Instead of just scanning for the known vulnerabilities, finding the unknown zero-day vulnerabilities is at least equally important. The unknown vulnerabilities are those bugs in software that are not (yet) discovered by the software developer, and which have not been publicly disclosed.
However this does not mean that the details of those vulnerabilities are not known by anyone. When malware writers get their hands on a vulnerability details before the developers do, they create and distribute zero-day exploits targeting that vulnerability. When the first attack takes place, there is no patch available for that vulnerability, and there are no security tools that can detect the attacks. They often happen undetected, time and time again.
The best way to discover unknown vulnerabilities is Fuzzing, a form of attack simulation, in which vulnerabilities are triggered by abnormal inputs. When the abnormal inputs cause an abnormal reaction, a vulnerability is found. It makes no difference if the vulnerability is known or previously unknown, it can be found by fuzz testing. The beauty of it is, that there are no false positives: since the testing is done using the external interfaces, the only bugs found are the one that pose an actual risk. If the bugs are not accessible through external interfaces, they do not represent an actual vulnerability or threat, and fixing them is waste of money and energy.
To sum it up: vulnerability management is important, but never ignore the effect of unknown vulnerabilities. Do not rely only on known vulnerability databases and network scanners to secure systems, as that will leave all zero-day vulnerabilities with no existing patches open to exploit.
Let me know if you have questions regarding the Unknown Vulnerability Management process or how zero-day vulnerabilities can be caught, or come and listen to the guest analyst speaker in the next Fuzzing 101 webinar.