Remote Spectre exploits demonstrated [LWN.net]
https://lwn.net/Articles/761100/ #ISACA #spectre #vulnerability

Обещанная видео запись прошедшего круглого стола.
#isaca #vulnerability_management

https://youtu.be/ZTMImuu2rKM

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/

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/