Vulnerability Management module on the Security Vision platform

Danila Luciv, Ruslan Rakhmetov, Security Vision

While covering our previous Asset Management module, we have already touched upon the process of accounting and analysing detected vulnerabilities. In this article, we will cover the functionality of the Vulnerability Management Module in more detail.

Fig.1. Vulnerability object card

Why are existing tools not enough?

At first glance, the process of managing vulnerabilities, at least those detected by scanners, seems simple enough: find, fix, test. However, even in a small infrastructure with a few hundred devices, the number of flaws detected by a scanner easily exceeds tens of thousands. What to speak about huge infrastructures, when even the very process of processing gigabyte reports causes a problem for most solutions, let alone building an effective remediation process based on them.

Analysing the results of reports is certainly important, but not the main problem for information security specialists whose area of responsibility includes vulnerability management. Roughly half of customers cite communication with the IT department as the main problem. How to agree on scanning windows, how to generate remediation requests, how to prove the need for patching and the relevance of the vulnerability to a particular environment, how to account for compensating measures and verify that the vulnerability has been remediated? In the Vulnerability Management Module we have tried to think through all the bottlenecks and blind spots that IS specialists face, so that the process of analysis, enrichment and communication with other departments would be transparent, convenient and as automated as possible.

How to avoid making enemies from the IT department and business units?

The vulnerability discovery process in most organisations starts with an active scan. How often should you perform scans? In terms of completeness of detection, the answer is of course ‘the more often the better’. However, it is clear that a vulnerability scanner has an impact on the system that can unpredictably affect both performance and functionality. This situation is further aggravated by the fact that careless IT professionals often speculate in explaining failures in information systems with reasons related to vulnerability scanning. ‘Who broke everything?’ - ‘Well, of course the scanner. Let's switch it off, it's only doing us harm.’ The cyber defence division must be prepared for these types of questions and ‘suggestions’. In the Security Vision platform, as part of the asset classification process, the business owner of the systems and the technical administrator set the allowable scan ranges for the system within which the vulnerability detection process should be performed. Each scanning task for each server is available for later analysis, in case a negative effect on the systems is detected. An engineer will be able to tell in minutes exactly when, with what policy and with what errors a scan task started and ended on a particular hardware or workstation. If the scanner used in the company supports policy generation and scanning start via API, Security Vision can, in a fully automated mode, monitor the start of the corresponding policies in the specified time interval, informing the responsible persons about the start of the scanning, its completion in the specified or unspecified period, its errors and results.

Fig 2. API - Start a scan, create a policy, stop a scan

How to get the most out of sources?

API is an extremely convenient source, but not all scanners implement the full range of functions through it, and some do not have an automation interface at all. In this case, report processing is used to obtain information. Regardless of the departure from the Russian market of certain scanner manufacturers, we continue to follow the changes in formats and methods of the leading manufacturers of this software, providing our customers with the most accessible information about the supported sources. At the moment the product supports such sources as:

• MaxPatrol 8\10
  
• RedCheck
  
• Tenable Nessus\Security Centre
  
• Qualys
  
• Rapid7
  
• SkyBox
  
• Penterra

In the article about the Asset Management Module we have already touched upon the unique functionality of processing structured XML and JSON reports. Its application in the Vulnerability Management Module allows you to process all available information from multi-gigabyte reports in minutes. It is limited only by the amount of RAM available on the server, the requirement for which is one to one according to the size of the report.

Figure 3. Supported scanners

How not to lose what you need?

Most vulnerability management solutions for deduplication, asset referencing and incremental reporting use a single, always-available property - the IP address. This is an understandable solution, but not without its drawbacks: a single asset may have multiple network interfaces, IP addresses may change, and one device may be replaced by another. In the case of an unauthenticated scan, Security Vison does the same thing, but if the credentials are correct and additional information such as BIOS UUID and MAC address of the network interface can be obtained from the report, the combination of these properties acts as a deduplication key, uniquely identifying the detected asset regardless of changes in network parameters and naming.

This grouping and linking logic allows you to generate a list of related assets, bulletins, and updates in the vulnerability card right when downloading information from scan reports

Figure 4. Grouping rules

Fig. 5. Rules for creating links

Which is in charge - the vulnerability or the update?

Once the vulnerabilities have been loaded and the system has identified the linked assets and updates, then comes the actual management process, i.e. making organisational decisions aimed at the most effective remediation.

From the perspective of the information security unit, the governance process revolves around the vulnerability itself and its characteristics such as:

• the criticality parameters of the vulnerability, which can be:
  
• general and immutable, such as the type of vulnerability, its vector, the consequences of exploitation, etc.
  
• temporal, describing the current state of the vulnerability, such as the presence and maturity of working exploits
  

• parameters of the significance of the vulnerable asset and other factors specific to the particular infrastructure and business processes of the protected organisation.

All of these are referred to in the CVSS methodology as Base, Temporal and Environmental metrics, respectively.

From the point of view of the IT departments that will be working to remediate the vulnerability, all of the characteristics described above are of little importance other than the overall priority of work and an agreed SLA (if any). For IT, it is the update itself that is at the top of the agenda, and its characteristics become the status of its testing, the need for additional settings and the ability to restore operation in case of abnormal situations, as well as the interaction of working groups to formulate decisions on the acceptance of vulnerabilities, due to the impossibility of closing them, and the development of compensating measures.

Thus, to be successful, it is necessary to separate approaches into those focused on cybersecurity professionals and those focused on IT implementers.

Figure 6. Technical Asset object card (Vulnerability Management module)

How to find external and internal context?

The very principle of work of scanners is often also very IT-specific. A typical scenario of interaction with scanner reports is as follows:

• ‘No update detected - so the asset being scanned is vulnerable’
  
• "What vulnerabilities have been discovered? All the ones in the bulletin. Here's a comma-delimited list of them."
  
• "And how do we understand the specific characteristics of each of these vulnerabilities, since they are all unique and have their own CVSS vectors? - Well, we will insert one of the vectors to our liking, you can find the rest on the internet if you wish"

Clearly, this approach has a number of limitations in terms of the ability to potentially analyse the vulnerability context. As a unit of account it was accepted to take the universal vulnerability identifier CVE or FSTEC BDU as the unit of account, and only in their absence the scanner's own identifiers. The main reason for this kind of information decomposition was the need to analyse each specific vulnerability. Thanks to the inbuilt knowledge base and external analytical services, each vulnerability not only has specific permanent and temporary CVSS characteristics belonging to it, but also constantly updated information from external sources about the presence of exploits, references in known computer attacks and hacker frameworks, as well as remediation methods and compensating measures.

An additional positive effect of this kind of grouping is that regardless of the number of scanners used by the client, analytics is performed by unique CVE identifiers. This makes it possible to group information from different sources and to identify relevant information about the most vulnerable hosts regardless of the number of sources.

The most important from the point of view of the internal context of the vulnerability can be considered the achievability of exploitation of the vulnerability from the external (most critical) and user (second priority) network segment. This kind of information can be analysed on the tab with related vulnerable assets, where systems are characterised not only based on their criticality but also, if available, based on network topology.

Figure 7. Analytical services (directory)

How to set up the work with IT?

In contrast to the previous direction of analysis and categorisation, the process of eliminating vulnerabilities and interaction with IT departments as the main object operates with the actual technical task of elimination, i.e. updating or compensating measure. Formation of such requests is performed automatically on the basis of the Remediation Policy. The input parameters for such policies are the characteristics of the detected vulnerability, as well as the type and characteristics of the vulnerable asset. As a result, remediation requests are generated, prioritised and with an agreed remediation SLA, if any. Requests matching the specified policy can be automatically broadcast to an external IT request system. Security Vision supports two-way communication with many modern ticketing systems, so integration is easy, and statuses updated in one system will automatically be updated in the other. With these policies in place, cybersecurity professionals can create criteria that will shape not only the regular remediation process, but also the emergency remediation process if updates are required for critical assets that are accessed by a large number of users in terms of network topology. In a similar way, test requests can also be aligned by prioritising for installation first on those technical assets whose groups correspond to test environments. In this way, the process of analysing the potentially negative impacts of an upgrade can be managed.

Figure 8. Remediation application

Much to the dismay of cyber defenders, not all vulnerabilities can be remediated. Sometimes it cannot be done in a timely manner because vendor or integrator involvement is required, and sometimes it is not possible at all when outdated software and operating systems are used in critical business processes. In such situations, compensating measures and harmonised adoption are essential. Decisions made are recorded so that vulnerabilities discovered in the future do not create new remediation requests. Decisions made may have expiry dates after which they must be revisited, and may create additional tasks within the platform and in external systems related to the implementation of compensating measures. To simplify the handling of large numbers of applications, decisions and compensating measures can be automatically copied to similar remediation applications.

How not to forget about the decisions made?

After the vulnerability has been remediated by IT specialists, if forced scanning is activated in the policy and this functionality is available in the vulnerability scanner, a vulnerability check will be performed within the agreed scanning window. The vulnerability will only be closed based on the same set of physical and logical accesses that were used in the discovery process. That is, if a vulnerability was identified using an authenticated scan, then its absence can only be identified based on a later authenticated scan of that host. The fact that a device in operation requires a reboot is also taken as a validation criterion. How the problem of dynamic naming and network settings is handled - we have touched on this earlier.

How do I work with security bulletins?

Subscription to security bulletins is even included in a number of industry standards, but very few information security solutions manage to make working with them convenient and automated. Many have already implemented work with NCSCI bulletins, but no less important and useful information is contained in the bulletins of software and hardware vendors. The Security Vision platform supports major vendor bulletin formats such as CVRF and OVAL. The bulletins contain not only lists of vulnerabilities and updates, but also specific technical recommendations for additional configuration and mitigations of vulnerabilities, both in the area of advanced logging and direct measures to reduce or eliminate the attack surface without applying updates.

Figure 9. Reference Guide - Available Bulletin Sources

How do I create a custom showcase for each participant?

The role model in the Security Vision platform not only allows you to restrict viewing and editing access to specific objects. It creates for each participant in the process, depending on their role, their own unique view of information, their own showcase, where only the necessary information is available and the focus is on those aspects that are necessary within the function and competence of the employee.

How to analyse progress and discover blind spots?

The management process could not have computable success criteria without the presence of an analytics module. Built-in reports and dashboards allow you to identify the most vulnerable assets, assess the pace of the remediation process, and, thanks to information from the Asset Management module, identify items that, for whatever reason, were not covered by the scan. As with all other elements of the platform, the analytical tools are easily upgraded right in the GUI without the need for search queries or other programming code. Reports can be sent to stakeholders on a regular basis, and all analytical information is available to external BI services via API, with the need to consolidate figures into a single reporting system.

Figure 10. Dashboards and reports

All of the features described above allow you to build an effective vulnerability management process in your organisation, without losing the external and internal context of vulnerabilities, help you talk to IT representatives in a language they understand and as a result have a transparent vulnerability handling and remediation process that requires minimal effort in terms of its internal processing, eliminating routine operations and allowing you to focus on the important tasks.