Vulnerability management in 2023: Questions and answers

In this article, I will try to answer several important questions related to identifying, classifying, prioritizing, and eliminating vulnerabilities in a timely manner, as well as how to automate the vulnerability management process.

Let me start the article by defining the classic process of finding and eliminating vulnerabilities.

• What is considered the classical approach here?

Many experts believe that vulnerability management covers several stages. First, all possible software assets in the company’s IT infrastructure should be identified. Once you have this list, you can find actual vulnerabilities that are already known and fix them. You should also check whether the discovered vulnerabilities are really fixed.

The most important and, perhaps, the most challenging stage, requiring the most attention, is the stage of removing vulnerabilities.

At the stage of removing vulnerabilities, it is essential to pay attention to the sequence of performed actions. If vulnerabilities are removed in a random order, then the process becomes inefficient and lengthy. This cannot satisfy anyone, neither the customer nor the service provider.

The reason for the delay is that the list of possible vulnerabilities can be close to infinity. Vulnerabilities can be associated with many different features of software and infrastructure. In reality, only a part of the vulnerabilities known to the vendor may appear in companies.

It is necessary not only to identify vulnerabilities but also to assign each of them its own priority and degree of importance. Prioritization can be performed in different directions: by software products, by IT infrastructure assets, and by the degree of threat created.

Adopting vulnerability management

The process of working with vulnerabilities is not just sorting through the list of potential threats. This is a complex process that must be well managed.

Vulnerability management is part of the existing risk management system. As already mentioned, after the asset inventory, we find vulnerabilities and prioritize them. At this stage, signs are already appearing that require special management. It is necessary to immediately specify how the identified risks will be handled.

There are various options here. You can deal with them directly, or you can group them and transfer them to another level for processing, etc. Thus, already at the stage of analyzing assets for vulnerabilities, it is necessary to have a ready-made strategy for dealing with risks.

Effective mitigation of vulnerabilities requires a precise choice of actions

Remediation of vulnerabilities is a well-defined, not a stochastic process. The tactic of its implementation is determined mainly by what tools are used to solve the tasks.

The choice of tactics is essential. If security issues are resolved spontaneously, then the task of eliminating vulnerabilities may lose its boundaries. The company begins to experience a shortage of time, resources, and employees. This should be taken into account in advance.

• Why can’t you take a linear, step-by-step approach, just find and fix vulnerabilities as information comes in?

If you force sysadmins to constantly engage in patching, then they will simply "howl" from excessive workload.

It can be done differently. After prioritizing vulnerabilities, administrators will fix only those that belong to the critical level and ignore medium or low-level vulnerabilities.

We can say that the process of eliminating vulnerabilities is creative. It not only requires the identification of security gaps that may appear in the company’s infrastructure but also must be conducted in a way that saves human resources. The process should not follow the formal principle of the interactive development and control cycle Plan-Do-Check-Act (PDCA).

When a new task flow is created, several questions immediately arise:

• Who will be entrusted with its implementation?
• Should it be given to administrators?

If so, admins will have to deal with thousands or even tens of thousands of hosts. After that, the next question will arise:

• How to ensure that all known vulnerabilities are closed on time and on all hosts?

There is a direct relationship between vulnerability prioritization and work planning. This is again followed by new questions:

• Who should be given the task of assigning priorities?

If you assign priorities to vulnerabilities automatically, for example, following the recommendations of the vendor, then:

• How likely is it that ALL new exploits are registered in the vendor’s patch database?

This stream of tasks that need to be solved runs into another problem: the presence of a competent analyst in the company. The effectiveness of removing vulnerabilities directly depends on the qualifications of employees. So, you will have to answer one more question:

• How many analysts are needed?

Vulnerability prioritization: a task for an analyst or a robot?

The correct choice of the vulnerability significance degree depends on the analyst’s work. In his turn, the cybersecurity analyst bases his assessments on various formal signs that appear in the news and other sources. Security news and bulletins often indicate which issues need to be addressed first. In my opinion, the analyst should highlight the top layer of critical vulnerabilities. All other work with vulnerabilities should be performed while processing incoming patches from vendors.

In practice, the biggest problem is the lack of good analysts who can conduct a competent audit of the most important news sources and prioritize vulnerabilities. Here, it is also important to build proper communication between employees of the IT and information systems (IS) departments as well as inside those departments.

In general, the process in most companies is very similar. The most significant vulnerabilities are identified first. For this, the news is collected from various sources, including the darknet. Vulnerabilities mentioned there are analyzed and checked for the degree of maliciousness for the company’s current infrastructure. As a result, a list of trending vulnerabilities is formed, and a prioritization list is created.

Since there are not enough good analysts to work in all companies, automated patching is required to fix many vulnerabilities. However, at present, it is too early to say that software robots will do all the work. Vendors make the first estimates of the priority of a particular vulnerability. The question of automation appears when analysts in a specific company add or change vendor estimates, taking into account the infrastructure used in their company.

The business model and architecture of each company involve a large number of features. When a new vulnerability appears, based only on its general features, it is impossible to correctly assess its priority without knowing the environment of a particular company. So, at the moment, complete automation and the rejection of the use of human labor are unrealistic.

Vendors that do not look for vulnerabilities in their products should be abandoned

When addressing vulnerabilities, it is necessary to pay attention to how a particular vendor works with them. Here are the crucial questions:

• To what extent are vendors able to detect vulnerabilities in their own products?
• How well do vendors prioritize vulnerabilities?

To answer the above questions, it is necessary to look at specific solutions and cases from the past. If earlier, the vendor was able to "hit the bull’s-eye" and correctly identify what analysts were doing inside commercial companies, then you can try to shift the task of automation when assigning priorities to the vendor. This will allow automation to be introduced into the process of eliminating vulnerabilities within the company.

The best approach is to combine the results provided by analysts from external companies, vendors, and in-house analysts. If all participants manage to work out their part in time, then this is an ideal situation.

If vendors are not keeping up with the pace of the emergence of new vulnerabilities, then companies have to act independently and prioritize on their own.

One unusual but important conclusion can be drawn from this. Regardless of who is developing a particular system, if a company or a group of developers behaves like a vendor, then it must adhere to strict deadlines when releasing patches for its product. If this is not the case, that vendor/product should be abandoned.

A similar approach can be used when looking for new products. The easiest way is to visit the developer’s website and see how often they issue security bulletins. In reality, it is impossible to avoid errors, no matter what kind of vendor is behind the product. MS Windows is a good example. We read about new Windows vulnerabilities every week but Microsoft is doing its job and release patches regularly. If patches are released only once a year or more, then it is better to leave such a vendor immediately.

Difficulties in fixing vulnerabilities

The main problem here is the use of solutions that claim full coverage of the process of eliminating vulnerabilities. None of them actually solve this problem.

In reality, it resembles pseudo-management. Such solutions already use built-in analysis and processing features. This limits the capabilities of the analyst in the company. All-in-one tools make analysts’ decisions less flexible.

This also applies to solutions characterized by a huge number of settings. Redundancy complicates the process of prioritizing vulnerabilities. Moreover, such systems often do not allow you to select an asset or vulnerability that the company wants to recognize as critical.

The usage of ill-conceived solutions creates uncertainty and questions.

• If suddenly some vulnerabilities cannot be fixed, especially if patch management is performed automatically, then who should be held accountable?

Another difficulty is related to certain limitations in these solutions, the existence of which is not initially obvious. Most often, restrictions may appear when the company's infrastructure begins to change. For example, this happens when distributed or remote networks appear in a company. In this case, it becomes necessary to install several security scanners, which increases costs.

Vulnerability detection quality

The problem of quality control in relation to vulnerability detection is becoming acute. The search for vulnerabilities is based on a constantly updated knowledge base.

• But how is it formed?

The vendor usually does not answer this question.

The operating environment used also adds some difficulties. If in Linux many problems are solved "on the fly" due to the system’s transparency, then in Windows, the problems of supporting your actions are superimposed by VM and products. Finding necessary information is often awfully hard, except empirically. It becomes even harder if you have a complex virtual infrastructure with multiple hosts. In this case, you may need a VMware monitoring tool to gain better visibility into the infrastructure's performance and resource distribution. Transparency in vulnerability detection is one of the most critical issues at the current stage.

The next difficult point is the level of detail of the reported security issues. The user often receives information in the vendor’s report containing brief procedures for fixing vulnerabilities. Currently, manufacturers are not tightly integrated into the patching process. Vendors do not want to automate patching immediately because that can lead to compatibility issues. First, you need to prepare a methodology on how the patching process takes place and what it affects. This can be built as an Excel tree, according to which the necessary script will then be prepared.

Script time is running out

At the same time, scripting is a thing of the past. Vulnerability databases are now available. New solutions are built on a different principle. First, the list of installed software is collected from supported nodes. After that, they are parsed and patched. Requests for the need to install a particular patch are performed automatically from known sources. Host scan time went down from 20 - 30 minutes to one minute. At the same time, tools for monitoring the relevance of patches are available.

In practice, however, there are many situations where ideal conditions are not met. For example, when you install third-party software that vendors did not consider. Another issue is the level of expertise used to compile the list of vulnerabilities. Information is not always updated on time. This gives rise to an imaginary sense of security.

Methods for detecting vulnerabilities

Methods for detecting vulnerabilities can be divided into two classes: "black box" and "white box." The former is a kind of penetration test that simulates the actions of an attacker. The latter is more reminiscent of the work of an antivirus, revealing characteristic activity using the existing signature.

Conclusion

The present time is characterized by fast-moving processes in the formation of security architecture. In the new environment, special attention should be paid to vulnerability management.

Image credit: Gorodenkoff/depositphotos.com

Alex Vakulov is a cybersecurity researcher with over 20 years of experience in malware analysis. Alex has strong malware removal skills. He is writing for numerous tech-related publications sharing his security experience.