Vulnerability Management: key challenges and practical advice, Part 2

In the article we continue to describe vulnerability management and challenges companies can face when setting this process, as well as share tips on how to overcome them.

Stage 4. Remediation

Remediation means taking of appropriate measures to neutralize detected vulnerabilities. It consists of installing patches/updates, stopping or disabling certain services and protocols, performing compensating measures or taking risks for non-remediation. Decisions made on detected vulnerabilities are usually indicated by appropriate statuses (e.g., compensatory measures, risk accepted or false positive). This is necessary to evaluate further actions on vulnerabilities and control their remediation.

If users decide to remediate the vulnerability, a task for IT department should be automatically created in a Service Desk system and the patch management (process of managing and applying patches, updates and software fixes) should be started.

Challenges and recommendations:

As mentioned above, vulnerabilities can be fixed using updates and patches or by modifying configuration files, but its installing process is often a complicated procedure. This may be caused by incompatibility with other programs, testing necessity, or missing access to the system for updates.

There are definitely assets, software, and services in any organization’s infrastructure that are difficult to patch. The reason is not the procedure itself, but dependencies that one by one take the system down and stop business processes.

Testing of patch pre-installing can help to reduce risks, but not every organization can afford it. The reason is usually lack of resources: testing updates is labor-intensive and requires non-trivial expertise. Nevertheless, if it’s not possible to deploy a test environment and find resources for testing updates and analyzing them, you can take a number of steps to structure asset information for a more focused tasks distribution. To begin with, you can list all OS and software assets, dividing them into those that can be patched automatically and that can only be updated manually, as well as those that can only be changed after preliminary tests and during maintenance to minimize risks of emergencies during working hours. A separate list of software interdependencies is needed to take them into account for updates planning.

Furthermore, the level of detail in vulnerability remediation solutions in scanner reports is also a major issue. CS specialists receive information from vendor’s reports containing brief procedures for vulnerabilities remediation, but usually this is not enough, and users conduct an additional research, as well as add context for installing required patch version or send a report as it is. If there is no time for additional analysis, IT department usually receives remediation requests with an unstructured list of vulnerabilities and equipment on which they were found. Such information is difficult to analyze and prioritize, it takes IT employees a lot of time to process such requests, which can result in missed remediation deadlines. This is especially critical when remediating vulnerabilities with a public exploit.

To shorten the processing time, each report should contain grouped information about patches/updates, which version has to be installed on a certain asset (and even better – where this version can be found).

At the same time, organizations not always have a clear patch management policy. However, this is the vital process that determines security level of the company’s perimeter, as well as all other systems. Therefore, before working with vulnerabilities, it’s necessary to organize the patch management process, in other words, to organize interaction with the IT department. In a perfect situation, CS and IT departments work closely together and help each other. Specialists from both departments, for example, can check patch management schedules by software segment or OS type, agree on future patches and network changes. We advise CS specialists to be involved in the coordination of network changes and to take them into account when further searching for vulnerabilities. And if it’s impossible to involve CS department in the process’s coordination, the department at least should timely receive information about changes in IT infrastructure.

An important part is the continuous process of patching systems by IT specialists without any external requests. When all possible systems in the protected network are patched on a regular basis, only few vulnerabilities appear. Additionally, scheduled patching is much more convenient and understandable for IT than handling of various tasks from CS department regarding vulnerabilities remediation.

Stage 5. Control

The stage includes verifying that vulnerabilities have been remediated and timelines have been met, as well as continuing infrastructure monitoring to detect new vulnerabilities. Control also includes analyzing deviations reasons, non-fulfillment of remediation requests, and developing process improvement solutions.

After results receiving of subsequent scannings, users can review vulnerabilities quantity: how many have been eliminated, how many new ones have been found, and which vulnerabilities remained unfixed.

Challenges and recommendations:

Many VM systems often can’t be integrated into Service Desk systems, which means that it’s difficult or impossible to automatically monitor and control statuses and timing of vulnerability remediation.  Therefore, many CS specialists don’t check patch management results, but consider results of subsequent scannings: unfixed vulnerabilities will again be converted into remediation tasks. However, statuses of vulnerability processing stages and overall statistics on remediation time remain unknown.

Another issue may be lack of tools to compare scan results. Many scanners store all scan reports separately, that’s why past and future scan results have to be compared manually or automated by CS specialists inside the company.

To solve such challenges, you can use VM solutions with an asset-centric approach that can store a history of vulnerability emergence and remediation on each asset. Afterwards you can track the current status and dynamics using dashboards and reports.

Conclusion

Vulnerability management requires a systematic approach and use of effective tools for vulnerability detection, prioritization and remediation. As you can see, there are many challenges, they occur at each step of VM process. This confirms its complexity and can be explained by non-trivial detection approaches, diversity of systems in companies’ infrastructures, and attackers who are relentless in their attempts to exploit and damage companies.

Moreover, we would like to highlight it one more time, vulnerability management is not a one-time operation, but a continuous, cyclical mechanism to comprehensively protect company’s assets. First of all, two recommendations should be followed for VM process configuration:

  • a company should build a resource-service model of network assets using inventory and keep it up to date by conducting scheduled scannings;
  • a company should approve and establish a regular patch management process with IT department.

As following, companies need to monitor changes in each scanning to analyze deviations and false positives, to adjust scanning profiles and patching time based on their results, sometimes to accept risks, and sometimes, on the contrary, to re-patch and strengthen protection. Only by solving problems on a daily basis and using own experience and experience of colleagues from IT department you will be able to build a powerful strategy to overcome threats.

This process can be simplified and automated with vulnerability management systems aimed at improving the speed, efficiency and integration of Vulnerability Management in organizations. This function has already been taken into account in Defensys’s solution.

Please feel free to ask us and our Partners for the details.