Forwarded from Vulnerability Management and more
Vulnerability Life Cycle and Vulnerability Disclosures
Vulnerability Life Cycle diagram shows possible states of the #vulnerability. In a previous post I suggested to treat vulnerabilities as bugs. Every known #vulnerability, as same as every #bug, was implemented by some software developer at some moment of time and was fixed at some moment of time later. What happens between this two events?
Right after the #vulnerability was implemented in the code by some developer ( creation ) nobody knows about it. Well, of course, if it was done unintentionally. By the way, making backdoors look like an ordinary vulnerabilities it’s a smart way to do such things. 😉 But let’s say it #WAS done unintentionally.
Time passed and some researcher found ( discovery ) this #vulnerability and described it somehow. What’s next? It depends on who was that researcher.
#vulnerability #Stuxnet #PoC #malware #exploit #EternalBlue #bughunter #backdoor #0day #VulnerabilityManagement #VulnerabilityDatabase #Concept
Read more: https://avleonov.com/2019/01/30/vulnerability-life-cycle-and-vulnerability-disclosures/
Vulnerability Life Cycle diagram shows possible states of the #vulnerability. In a previous post I suggested to treat vulnerabilities as bugs. Every known #vulnerability, as same as every #bug, was implemented by some software developer at some moment of time and was fixed at some moment of time later. What happens between this two events?
Right after the #vulnerability was implemented in the code by some developer ( creation ) nobody knows about it. Well, of course, if it was done unintentionally. By the way, making backdoors look like an ordinary vulnerabilities it’s a smart way to do such things. 😉 But let’s say it #WAS done unintentionally.
Time passed and some researcher found ( discovery ) this #vulnerability and described it somehow. What’s next? It depends on who was that researcher.
#vulnerability #Stuxnet #PoC #malware #exploit #EternalBlue #bughunter #backdoor #0day #VulnerabilityManagement #VulnerabilityDatabase #Concept
Read more: https://avleonov.com/2019/01/30/vulnerability-life-cycle-and-vulnerability-disclosures/
Forwarded from Vulnerability Management and more
No left boundary for Vulnerability Detection
It’s another common problem in nearly all #VulnerabilityManagement products. In the post “What’s wrong with patch-based #VulnerabilityManagement checks?” I wrote about the issues in plugin descriptions, now let’s see what can go wrong with the #detection logic.
The problem is that #VulnerabilityManagement vendors, in many cases, have no idea which versions of the Software were actually vulnerable.
OMG?! How this can be true? 🙂 Let’s take an example.
Each #vulnerability at some points in time:
* was implemented in the program code as a result of some mistake (intentional or not)
* existed in some versions of the program
* was detected and fixed
Read more about this in “Vulnerability Life Cycle and Vulnerability Disclosures“.
Let’s suppose that we have some Software A with released versions 1, 2 … 20.
Just before the release of #version 10, some programmer made a mistake (bug) in the code and since the #version 10 Software A has become critically vulnerable. Before the release of #version 20, Software Vendor was informed about this #vulnerability and some programmer fixed it in #version 20. Then Software Vendor released a security bulletin: “Critical vulnerabilities in the Software A. You are not vulnerable if you have installed the latest #version 20.”
And what does #VulnerabilityManagement vendor? This vendor only sees this #securitybulletin. It is logical for him to decide that all versions of Software A starting from 1 are vulnerable. So, it will mark installed versions 1 … 9 of the Software A as vulnerable, even so actually they are NOT.
#version #Ubuntu #securitybulletin #bug #VulnerabilityManagement #Concept
Read more: https://avleonov.com/2019/02/11/no-left-boundary-for-vulnerability-detection/
It’s another common problem in nearly all #VulnerabilityManagement products. In the post “What’s wrong with patch-based #VulnerabilityManagement checks?” I wrote about the issues in plugin descriptions, now let’s see what can go wrong with the #detection logic.
The problem is that #VulnerabilityManagement vendors, in many cases, have no idea which versions of the Software were actually vulnerable.
OMG?! How this can be true? 🙂 Let’s take an example.
Each #vulnerability at some points in time:
* was implemented in the program code as a result of some mistake (intentional or not)
* existed in some versions of the program
* was detected and fixed
Read more about this in “Vulnerability Life Cycle and Vulnerability Disclosures“.
Let’s suppose that we have some Software A with released versions 1, 2 … 20.
Just before the release of #version 10, some programmer made a mistake (bug) in the code and since the #version 10 Software A has become critically vulnerable. Before the release of #version 20, Software Vendor was informed about this #vulnerability and some programmer fixed it in #version 20. Then Software Vendor released a security bulletin: “Critical vulnerabilities in the Software A. You are not vulnerable if you have installed the latest #version 20.”
And what does #VulnerabilityManagement vendor? This vendor only sees this #securitybulletin. It is logical for him to decide that all versions of Software A starting from 1 are vulnerable. So, it will mark installed versions 1 … 9 of the Software A as vulnerable, even so actually they are NOT.
#version #Ubuntu #securitybulletin #bug #VulnerabilityManagement #Concept
Read more: https://avleonov.com/2019/02/11/no-left-boundary-for-vulnerability-detection/
Forwarded from Vulnerability Management and more
Vulnerability Management vendors and Vulnerability Remediation problems
It’s not a secret, that #VulnerabilityManagement vendors don’t pay much attention to the actual process of fixing vulnerabilities, that they detect in the infrastructure (Vulnerability Remediation).
In fact, most of VM vendors see their job in finding a potential problem and providing a link to the Software Vendor’s website page with the #remediation description. How exactly the #remediation will be done is not their business.
Remediation is a painful topic and it’s difficult to sell it as a ready-made solution. And even when Vulnerability Vendors try to sell it this way, it turns out pretty ugly and does not really work. Mainly because the Remediation feature is sold to the Security Team, and the IT Team will have to use it.
#Windows #remediation #patch #Linux #VulnerabilityManagement
Read more: https://avleonov.com/2019/04/29/vulnerability-management-vendors-and-vulnerability-remediation-problems/
It’s not a secret, that #VulnerabilityManagement vendors don’t pay much attention to the actual process of fixing vulnerabilities, that they detect in the infrastructure (Vulnerability Remediation).
In fact, most of VM vendors see their job in finding a potential problem and providing a link to the Software Vendor’s website page with the #remediation description. How exactly the #remediation will be done is not their business.
Remediation is a painful topic and it’s difficult to sell it as a ready-made solution. And even when Vulnerability Vendors try to sell it this way, it turns out pretty ugly and does not really work. Mainly because the Remediation feature is sold to the Security Team, and the IT Team will have to use it.
#Windows #remediation #patch #Linux #VulnerabilityManagement
Read more: https://avleonov.com/2019/04/29/vulnerability-management-vendors-and-vulnerability-remediation-problems/
Forwarded from Vulnerability Management and more
The news that Rostelecom (Solar) will begin to provide Qualys Vulnerability Management services (rus) probably doesn't mean much on a global scale, but it's quite interesting for Russian market and for markets of other "countries with strict data sovereignty rules".
What problems we have with global cloud-based security solutions, including Vulnerability Management solutions? When the data about vulnerabilities of Russian organizations is stored and processed somewhere abroad and it is not clear how and by whom, (even if we are not even talking about the real threats) it's is a red flag for government regulators, like FSTEC. And they can easily make the usage of such services VERY complicated, at least among the customers that are somehow related to the government. The same restrictions stimulate the development of local security products, that's why we have local players on Russian #VulnerabilityManagement market, like Positive Technologies, Altx-Soft, NPO Echelon, etc.
What problems we have with global cloud-based security solutions, including Vulnerability Management solutions? When the data about vulnerabilities of Russian organizations is stored and processed somewhere abroad and it is not clear how and by whom, (even if we are not even talking about the real threats) it's is a red flag for government regulators, like FSTEC. And they can easily make the usage of such services VERY complicated, at least among the customers that are somehow related to the government. The same restrictions stimulate the development of local security products, that's why we have local players on Russian #VulnerabilityManagement market, like Positive Technologies, Altx-Soft, NPO Echelon, etc.
Forwarded from Vulnerability Management and more
I just read the 14-page report, "Comparing vulnerability and security configuration assessment coverage of leading VM vendors" by Principled Technologies. Tenable marketing team actively shared it last week.
The main idea of the report: Tenable covers more CVEs and CIS benchmarks than Qualys and Rapid7.
So, my impressions:
1. Hallelujah! Finally, a comparison of Vulnerability Management products based on something measurable - on their Knowledge Bases. And at least one VM vendor is not afraid to use it in marketing and mentions the competitors directly. This is a huge step forward and I hope that this is the beginning of something more serious. We really need to start talking more about the core functionality of VM products.
2. However, this particular report is just a Tenable advertisement. This is not even hidden. I really like Nessus and Tenable, and believe that they have a very good Knowledge Base, but reading on every page how great Tenable's products are is just ridiculous. It would be much better to read it in more neutral form.
3. Using only the CVE IDs for comparing Vulnerability Knowledge Bases is NOT correct (strictly speaking), because for many software products most of vulnerabilities do not have CVEs, only the patch IDs. CVE-based comparison also doesn't distinguish types of vulnerability checks: remote banner-based, remote exploit-based and local. To make a reliable comparison, it's necessary to map all existing vulnerability detection plugins of VM products, but this is MUCH more difficult.
4. CVE-based comparison in this report is not really informative. They only compare absolute numbers of IDs grouping them by year, software product (cpe) and cvss v2 score. Why is this wrong? If VM vendor A covers 1000 CVEs and vendor B covers 1000 CVEs, this does not mean that they have the same database and it is quite complete. The real intersection between the KBs may be only 500 IDs, so these vendors would be able to detect only a half of each other's vulnerabilities. It matters, right? In my old express comparison of Nessus and OpenVAS Knowledge Bases I demonstrated this and tried to suggest reasons why some vulnerabilities are covered by some vendor and others are not. If you compare CVEs as sets of objects, it turns out that each VM product has own advantages and disadvantages.
5. CIS-based comparison in this report uses only information about certificated implementations from the CIS website without regard to versions and levels. CIS Certification is an expensive and complicated procedure, that is NOT mandatory and does not affect anything. I once implemented many CIS standards for Linux/Unix in PT Maxpatrol. Well, yes, they are not certified and you won't see them on the CIS website, but does this mean that they are not supported in the VM/CM product? Of course not! So, it's a very strange way of comparing Compliance Management capabilities.
In conclusion, the idea behind this report is good, but the implementation is rather disappointing. If one of the VM vendors, researchers or customers wants to make similar comparison, public or private, but in a much more reliable and fair way - contact me, I will be glad to take part in this. 😉
#PrincipledTechnologies #Tenable #Rapid7 #Qualys #CVE #CIS #VulnerabilityManagement #ComplianceManagement #CPE #CVSS #PositiveTechnologies #MaxPatrol #OpenVAS #Nessus
The main idea of the report: Tenable covers more CVEs and CIS benchmarks than Qualys and Rapid7.
So, my impressions:
1. Hallelujah! Finally, a comparison of Vulnerability Management products based on something measurable - on their Knowledge Bases. And at least one VM vendor is not afraid to use it in marketing and mentions the competitors directly. This is a huge step forward and I hope that this is the beginning of something more serious. We really need to start talking more about the core functionality of VM products.
2. However, this particular report is just a Tenable advertisement. This is not even hidden. I really like Nessus and Tenable, and believe that they have a very good Knowledge Base, but reading on every page how great Tenable's products are is just ridiculous. It would be much better to read it in more neutral form.
3. Using only the CVE IDs for comparing Vulnerability Knowledge Bases is NOT correct (strictly speaking), because for many software products most of vulnerabilities do not have CVEs, only the patch IDs. CVE-based comparison also doesn't distinguish types of vulnerability checks: remote banner-based, remote exploit-based and local. To make a reliable comparison, it's necessary to map all existing vulnerability detection plugins of VM products, but this is MUCH more difficult.
4. CVE-based comparison in this report is not really informative. They only compare absolute numbers of IDs grouping them by year, software product (cpe) and cvss v2 score. Why is this wrong? If VM vendor A covers 1000 CVEs and vendor B covers 1000 CVEs, this does not mean that they have the same database and it is quite complete. The real intersection between the KBs may be only 500 IDs, so these vendors would be able to detect only a half of each other's vulnerabilities. It matters, right? In my old express comparison of Nessus and OpenVAS Knowledge Bases I demonstrated this and tried to suggest reasons why some vulnerabilities are covered by some vendor and others are not. If you compare CVEs as sets of objects, it turns out that each VM product has own advantages and disadvantages.
5. CIS-based comparison in this report uses only information about certificated implementations from the CIS website without regard to versions and levels. CIS Certification is an expensive and complicated procedure, that is NOT mandatory and does not affect anything. I once implemented many CIS standards for Linux/Unix in PT Maxpatrol. Well, yes, they are not certified and you won't see them on the CIS website, but does this mean that they are not supported in the VM/CM product? Of course not! So, it's a very strange way of comparing Compliance Management capabilities.
In conclusion, the idea behind this report is good, but the implementation is rather disappointing. If one of the VM vendors, researchers or customers wants to make similar comparison, public or private, but in a much more reliable and fair way - contact me, I will be glad to take part in this. 😉
#PrincipledTechnologies #Tenable #Rapid7 #Qualys #CVE #CIS #VulnerabilityManagement #ComplianceManagement #CPE #CVSS #PositiveTechnologies #MaxPatrol #OpenVAS #Nessus
Tenable®
Comparing Vulnerability and Security Configuration Assessment
A new study demonstrates that Tenable stands high above Qualys and Rapid7 in vulnerability assessment (VA) and security configuration assessment (SCA) coverage. Read now.
Forwarded from VMconf 22
From idea to implementation. We will host an independent Vulnerability Management conference. CFP launch in a week. https://vmconf.pw/
#vmconf #vmconf22 #vulnerabilitymanagement
#vmconf #vmconf22 #vulnerabilitymanagement
Forwarded from Vulnerability Management and more
Hello everyone! This episode will be about the VMconf22 Vulnerability Management conference. CFP started on November 1, which will last a month and a half. So please submit your talk or share this video with someone who might be interested.
Video: https://www.youtube.com/watch?v=8ht_DYfH6Vc
Blogpost: https://avleonov.com/2021/11/01/vmconf-22-vulnerability-management-conference-call-for-papers-started/
CFP: https://vmconf.pw/#cfp
VMconf channel: @VMconf
VMconf chat: @VMconfchat
Video: https://www.youtube.com/watch?v=8ht_DYfH6Vc
Blogpost: https://avleonov.com/2021/11/01/vmconf-22-vulnerability-management-conference-call-for-papers-started/
CFP: https://vmconf.pw/#cfp
VMconf channel: @VMconf
VMconf chat: @VMconfchat
YouTube
VMconf 22 Vulnerability Management conference: Call For Papers started
Hello everyone! This episode will be about the VMconf 22 Vulnerability Management conference. CFP started on November 1, which will last a month and a half. So please submit your talk or share this video with someone who might be interested. Text: https:…