О важности due diligence в жизни ИБешника.
Рекомендую оценить свои риски в случае использования серверов supermicro.
#supermicro #china #bug
https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
Рекомендую оценить свои риски в случае использования серверов supermicro.
#supermicro #china #bug
https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
Bloomberg.com
China Used a Tiny Chip in a Hack That Infiltrated U.S. Companies
The attack by Chinese spies reached almost 30 U.S. companies by compromising America's technology supply chain.
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/