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/