Vulnerability Management vendors and Vulnerability Remediation problems. It’s not a secret, that Vulnerability Management vendors don’t pay much attention to the actual process of fixing vulnerabilities, that they detect in the infrastructure (Vulnerability Remediation). Although it seems to be the main goal of VM products: to make vulnerabilities fixed and whole IT infrastructure more secure, right?

In fact, most of VM vendors see their job in finding a potential problem and providing a link to the Software Vendor’s website page with the remediation description. How exactly the remediation will be done is not their business.

The reason is clear. Remediation is a painful topic and it’s difficult to sell it as a ready-made solution. And even when Vulnerability Vendors try to sell it this way, it turns out pretty ugly and does not really work. Mainly because the Remediation feature is sold to the Security Team, and the IT Team will have to use it.

Evolution of Vulnerability Remediation features

Let’s see how Vulnerability Remediation features were developing in Vulnerability Management products and why they don’t work properly:

1. Scan reports. This is the most basic way. You scan the infrastructure, detect 100500 vulnerabilities on over 9000 hosts, make 300 pages report and, with a sense of accomplishment, send it to IT team for remediation. Of course, nobody will fix these vulnerabilities or even look in the report. And even if IT administrators will take it in work, after some stimulation, they will just figure out that report is significantly outdated.
2. Give IT administrators access to the scanner. Why not to do this if VM vendor already made dashboards and role-based access model in the scanner? Let the IT administrators see the detected vulnerabilities, or even let them run some vulnerability scans by themselves. For example, to check that the vulnerability was patched correctly. The only thing is that IT guys don’t need it, because scanning and vulnerability analysis is not theirs job. And without specific tasks nothing will be actually fixed (surprise-surprise).
3. Create a built-in task tracker for IT administrators in the scanner and generate Vulnerability Remediation tasks. It’s closer to the truth, but the IT teams already have their own trackers, for example JIRA, where their KPIs are counted, and they most probably will refuse to use another task tracker only for vulnerability-related issues.
4. Map Vulnerability Remediation tasks in the built-in task tracker to the tasks in external task tracker or use the external task tracker directly. That would be it , but the questions arise how to create the tasks: by hosts or by vulnerabilities, or by types of hosts, or by types of vulnerabilities. And to whom these tasks would be assigned. The default method used in scanner will be most likely unsuitable for some teams of IT administrators or DevOps. In order to please everyone, you will need the flexibility of a python script.

We can conclude that for effective Vulnerability Remediation process there won’t be enough features existing in ready-made Vulnerability Management solution. For real life infrastructure you will need a custom process tied closely with the Asset Management (we should know hosts types, owners, scopes, etc.) and with the patching methods used in a particular organization, that are often not documented.

Can we reduce Vulnerability Remediation problems somehow?

Of course, there are ways to reduce the number of vulnerabilities that need to be fixed and it’s also possible to simplify the patching process. Vulnerability Management vendors, most likely, will tell you about it.

1. You can try to reduce the number of vulnerabilities that need to be patched: patch only the most critical vulnerabilities or patch vulnerabilities on the most critical servers (kind of prioritization). This is all well and good if we can guarantee that we are doing this prioritization correctly and have not forgotten something important, otherwise problems can be extremely unpleasant.
2. You can use automated vulnerability patching (it is another topic how efficient it is). Here’s a video from Tanium, for example. Not that I have something against this vendor, but the demonstration is typical. The video shows the fix of Windows MS vulnerability. 😉 Third-party software for Windows does not fit so well (it’s necessary to maintain the list of actual patches for each software!). Linux-software that is NOT installed from the repository (it happens!) also will fail. Only the installation process of KB file is shown, and other additional activity, like Windows registry configuration is not taken into account. Responsibility for installing the patch (which in theory can break something) is on the IT administrator. And we just recommend rolling the patch on the production server and don’t even bother if something will go wrong. Another example is Trend Micro Deep Security virtual patches. Fighting potentially exploited vulnerabilities with virtual patches, that should potentially fix vulnerabilities is a quite weird… But it’s better than nothing.
3. You can blame the infrastructure of a particular organization. That it is not as ideal as you would like it to be. It consist of various types of hosts, and weird legacy, IT administrators are lazy and rude. And, in theory, everything should be patched constantly and by itself (the topic for a separate post). But it is not constructive. In an ideal infrastructure, Vulnerability Management is not needed, as well as Security Team in general. 😉 But it’s simply too expensive to build and maintain such infrastructure.

Fundamental Vulnerability Remediation problems

You can try to reduce the number of vulnerabilities that should be fixed and try new methods of patching, but it doesn’t solve the fundamental problems of Vulnerability Remediation:

1. Updates can break the systems (host OS and Applications). This means that in order to patch any more or less important host, you will need to receive approve from the owner, conduct a testing procedure, update the host only within the selected time window.
2. Updates are NOT made in one click in many cases. Often it is necessary to configure something (for example, change entries in the registry). Such work is difficult for automation. Someone must do it all the time. Even in conditions where the exploitation of each specific vulnerability is not obvious.

In conclusion

Making the vulnerabilities fixed on a regular basis in a real environment is a quite difficult and ungrateful job. The problems related to this process are usually silenced by Vulnerability Management vendors and largely fall on the IT departments.

My opinion is that this is unfair and the Vulnerability Management team in the organization should be involved in the patching process and do everything to make the life of IT more convenient. Unfortunately, this can’t be done by using only standard and ready-made Vulnerability Management solutions, you need to build a custom process, taking into account all the features of a particular organization.

Alexander Leonov

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.