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.

Read more: https://avleonov.com/2019/04/29/vulnerability-management-vendors-and-vulnerability-remediation-problems/