Vulnerability Management Elements

being able to dynamically connect and correlate data to different part of a vulnerability management interface is crucial.

Precise vulnerability management if one for the key to an agile security program.

Among non-technical but crucial elements like methodology, system and workflow behind your VM, there are some technical aspect which can totally change the outcome of VM. these easily turn your VM to a reliable management system.

being able to dynamically connect and correlate data to different part of a vulnerability management interface is crucial.

Interface!

Colorful interfaces for vulnerability management solutions are getting more and more common nowadays. Interfaces could simply distract us from main purpose of vulnerability management, or they could force their potentially lame “understanding of an standard VM process” to us and replace our very customized approach,. But regardless of their positive or negative impact on the process, they are the main element of a VM solution.

Penetration testers or operators of these VM software are solely relying on what is provided via user interface, and seeing what is happening in back-end is either impossible, or very limited. This is so different than first generation of vulnerability management solutions where operator was certainly who set the system up and configure and due to tools and techniques, s/he had to know what exactly is happening in back-end, as there was not any colorful front-end.

What we need to have in a VM interface and how it has to be linked to all aspect of the system are different stories, but for now just remember that interface to a VM is not like a normal user interface. If you cannot dynamically connect and correlate the data there then it is useless. Perhaps next generation has more AI involved but as of today you need to be able to change objects and their correlation, and be able to see what is happening behind the scene. Otherwise you better stick with a fully manual VM system.

Scoring

Everything is about scoring aka Ranking. It is considered ‘blind’ assessment If you do not rank based on a agreed scoring system. But does not mean CVSS is the solution.

Common Vulnerability Scoring System or CVSS has been playing the role of a defacto standard for ranking security vulnerabilities and version 3.0 has significantly better but far from a reasonable scoring methodology.

In practice, vulnerability assessment has to be done with very specific considerations of the target system. This includes the software slash client application, operating system, user privileges, network protocols and services… and dozen of other factors which all together affect the way a system can be exploited with presence of that specific vulnerability.

A CVSS score 10 might be ranked so low or even not needed to deploy! And a CVSS score 2 might be a patch or mitigation your need to deploy right away! It all depends on the description of the vulnerabilities, attack vectors, details of exploit… you need to read and research about a vulnerability in depth before giving it a score. You could utilize CVSS in your own scoring system, but you should never rely solely on CVSS. There are practical ways to assess each individual vulnerability.

Mitigation

This is the hardest part and solutions in current market are either not capable of handling this phase of VM for you, or they are so expensive and not affordable. Most of the tools for VM are not even able to roll a patch and have follow-up scanning and reliable validation, let alone taking care of the workarounds and countermeasures which requires intensive scripting and cross platform API.

The whole purpose of a VM is to mitigate weaknesses so if you focus on this phase you will find your organization having a very smooth system quickly.

Developing an organic scoring system with documentation of logic will let to a smart and meaningful scoring system.

In other words, assess vulnerabilities based on specific situation related to the details of exploitation method. A single particular vulnerability might not be applicable to all layers of an organization, or all similar machines. Develop an organic scoring system and document the logic so you will have solid justification for future similar vulnerabilities. It takes not more than a few months to develop an smart meaningful assessment and scoring system.

Focus on mitigation and not to have same vulnerability repeating again and again, those are considered corrective actions which are preventive also. Remember companies still get hacked after mitigating weaknesses because they do not pay attention to vector and surface of the attack and how exploitation works. Most of the times patching is not enough, even though vendors always release updates and patches.

The interface to a VM is where you should be able to see and understand everything. If you have to ping a node from a different interface, or your VM is not linked to your asset management system, do not waste your time and money, you could utilize free tools with same manner.