AM Live Vulnerability Management Conference Part 2: What was I talking about there. Hello all! It is the second part about AM Live Vulnerability Management conference. In the first part I made the timecodes for the 2 hours video in Russian. Here I have combined all my lines into one text.
What is Vulnerability Management?
Vulnerability Management process is the opposite of the admin’s saying “If it works – don’t touch it!”. The main idea of this process is to somehow fix the vulnerabilities. How do you achieve this is not so important. Maybe you will have a nice Plan-Do-Check-Act process and strict policies. Maybe not. The main thing is that you fix vulnerabilities! And the main problem is to negotiate this regular patching with system administrators and service owners.
Choosing a Vulnerability Management Solution
The same goes for tools. Of course VM vendors will tell you about the big difference between Vulnerability Management solutions and ordinary Vulnerability Scanners. They will tell you that you definitely need additional features that is only available in the VM.
But honestly, sometimes a basic vulnerability scanner and Jira is already a Vulnerability Management solution. In one famous Russian film, there was a good phrase, “in our restaurant we call rusks “croutons”, because a rusk cannot cost $8, but crouton can“.
However, do not go to the other extreme. Of course, commercial Vulnerability Management solutions are expensive, especially when licensed per host. But it’s not just because vendors are just greedy. It’s really expensive to make a product like this. Could there be a full-functional and free vulnerability scanner comparable to commercial products. In theory, yes, but it is not clear how the vendor/developer will finance the maintenance of the knowledge base of this scanner. In practice, we see how such stories collapse. So, when you use a free scanner (such as OpenVAS), you need to understand the limitations of the product. Including the completeness of the scan results.
It is useful to take several solutions for a PoC and compare their knowledge bases and scan results. For example, you can compare knowledge bases using VulnKBdiff (one of my pet projects). Thus, you can determine the solution that is required for your needs.
You may even decide to take several VM solutions. For example one specifically for local products used only in your country. Usually, global VM vendors do not support such solutions well. Or a scanner for a specific class of software (ERP, SCADA, etc.).
If you decide to use several VM products, you will need another solution for storing and prioritizing vulnerabilities from different sources and doing custom prioritization. Or, it should be possible to add a third-party vulnerability feed to the commercial ready-made solution that you chose. Keep this in mind too.
Perimeter scanning, Internal scanning, Agent-based assessment
It is necessary to separate external and internal scanning. Agent-based assessment is also a controversial topic.
- External perimeter scanning is very useful for detecting unauthorized publication of services. The normal frequency of such a scan is a couple of times a week or often. External perimeter scanning is not very reliable for detecting vulnerabilities (banner-based detections) It’s better to assess hosts accessible from the Internet with internal authenticated scans. Of course, the vulnerabilities of hosts accessible via the Internet should be considered the most critical. And generally speaking, сriticality of the network is an important element of scoring.
- Active internal scanning depends on agreements with the system owners. If you can say “we scan everything – if you are not ready, your problems” is good, but it does not work everywhere and not always.
- Installing additional agents is usually annoying for both users and system administrators. But if the agents are lightweight and simple, this can be a good alternative. As an example, you can collect the list of packages and OS versions and get vulnerabilities using the Vulners Linux API. This is less scary from a sysadmin’s point of view than a complete black box with root privileges.
Additional features: Asset Management, Automated Patching, Vulnerability Prioritization and Intelligence
- Asset Management is important, it does not have to be part of the VM, it can be implemented by IT. It is also necessary to manage the accounts for scanning and network access.
- Automated Patching is possible, but a system that allows automatic patching is much more expensive to develop and maintain. I would like to have an automated Patch Management, but subtlety who will be responsible if something breaks? Scanning can break the hosts too.
- Vulristics – an open source framework for prioritizing vulnerabilities
- Telegram cybernews aggregation channels @avleonovnews for news in English and @novostipoib for news in Russian
VM Trends
I think that VM systems will evolve towards VMDR and automated patching, they will provide better information on exploitability, right up to the actual exploitation of vulnerabilities on a test host. The entry of large vendors like Microsoft with their Defender for Endpoint narrows the space for traditional vendors.
Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.
А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.
Do you think given to proliferation of Unix-based systems (K8S, Docker, MacOS) we might end using whitelisting software and golden images instead of continuously patching all the staff?
> Do you think given to proliferation of Unix-based systems (K8S, Docker, MacOS) we might end using whitelisting software and golden images instead of continuously patching all the staff?
I don’t think so. Previously, a typical problem was: we cannot update this vulnerable Linux host, because it will break our application. Now the problem: we cannot stop using this vulnerable Docker image, because it will break our application. So what’s the difference? Just slightly different entities. 🙂 And, of course, a lot of Windows stuff, various network devices, virtualization, etc. are still here and will remain here for a long-long time.
Pingback: AM Live Vulnerability Management Conference 2022: my impressions and position | Alexander V. Leonov