The 7 stages of Vulnerability - what they don't teach at CISO school (yet)…

The 7 stages of Vulnerability - what they don't teach at CISO school (yet)…

Here is something I found myself explaining too many times lately, so I figured I could take some minutes & share insights on how I comprehend Vulnerabilities, and more precisely, the stages of a vulnerability in our world - from Unknown to known, and sometimes, well... back to not so known and clear :-)

Let's hop in:

1. Potential Vulnerabilities -> Unknown

First stage is, that all technology is vulnerable, inheritably. All systems, software, communication devices, hardware, applications etc. - designed by people, built by people. those imperfect creations.

Essentially - any product out there is "A bag of vulnerabilities waiting to be discovered". At least, this is how I see it. Every technology can live up to "its potential" and produce many vulnerabilities, as it is born with more than few potential ones, and "grows" some new ones on the way (through changes/maintenance etc'). This is stage 1, it is in every technology, and it is, in large, unknown (all the yet undisclosed Vulnerabilities are, of course, Unknown to all).?

2. Undisclosed in public / 0Days -> Known to few

A vulnerability starts its life in the world with the person/organization that discovered it, and that party's interests. An academy researcher, a commercial company's researcher, a nation-state or a lone wolf, all are very different "parents" to this freshly born Vulnerability, impacting the first steps it will make. Here it is important to mention, that some undisclosed vulnerabilities are kept private, while others are sold through the dark web (not that unknown, at that time), and some are discovered by attacked entities, the targets of that 0day (!), which can in turn - disclose it (to vendor and the world), or perhaps, provide detection rules for it and "pass it forward", use it on others :) again, it really depends on the parents ;-)

3. Disclosed/Leaked/CVE published -> Known to all

At some point, whether early or after decades(!) - yeah, we've seen those, the 0day will become publicly known. a CVE will be published, and the vendor will, hopefully (not always!) work on a patch. that really depends on the lifecycle of that technology or version of it, the impact (CVSS score) etc. Yet - at this stage - it is KNOWN. no more excuses, CISOs. You can play around with "0day detection tools" and TTPs until tomorrow, but now the responsibility is on the table, the risks map has been updated, and time to include this at your organization's risk management to do list.

4. Public Exploitation (Optional) -> Known to all

This optional step, publicly known exploit (or exploitations, multiple ones), means tool/code published that allows active exploitation of the vulnerability, whether already patched or not. This obviously puts different levels of pressure on organizations, as it is, again, like the vulnerability itself - KNOWN and clear to all.

Yet why should automatically score "exploit-proof" Vulnerabilities higher than "non-publicly exploited" ones? Just because there is NO KNOWN EXPLOITATION right now, it doesn't mean that some party(ies) didn't reverse engineer the thing, understood how it works to produce a functioning PoC (especially becomes easier AFTER the patch, ironically, to do so! just diff the files/code), and it might be that it is being quietly exploited...

5. Patch/Fix Released vs. No-Fix / no patch -> Known to all

At this point, publicly exploited or not, known to be exploited or not,- we hope for the vendor to patch the vulnerability and fix the issue in streamline, official, supported channels. Especially when we are dealing with a product in its active life cycle updates, or a mass impact with huge install base, even if legacy.

Some vendors will release quickly. some will take the time to deeply understand the issue, to prevent a "recall" and/or solve the vulnerable component's further potential "from the root" of the issue. Some won't be fixed. This happens more often that you'd think. On your home ADSL routers, for example, if you'd care to check :) whatever happens at this stage - you have to either apply the patch -- or apply virtual patching (when no fix, and where applicable) -- or workaround/circumvent the risk in your environment (again, when no fix) -- or work to block/minimize exposure/replace that component, when no fix -- or accept the risk.?

6. Applying patch/fix; gradual/staged patch, issues with patch

Patching is not more of the favorable parts in a security person's life. Some do it better, some less, all struggle at this point or another with patching effectively, to all environments, with proper update slots and checks. Some patches are partial (don't solve the entire Vulnerability, or set of discovered vulnerability), some apply a gradual patch -- meaning, today you get a "workaround" (close this port, modify this registry setting) and in X months you will get the more "permeant" mitigation/fix, when foundations have been properly laid by the initial patch(es). Some fixes "blow" in our faces, causing errors, connectivity problems, regression bugs, and god forbid - availability issues (crashing upon patching - a vendor's worst nightmare).?

7. Patch partly fixes/not fixed after patch/subsequent patches (Optional)

On some occasions, it will be discovered, after some time and feedback, that the patch only "partly" fixes the issue -- or the issue was believed to be fixed, yet is Not really fixed (see Benjamin delpi's romance with Microsoft) -- or that subsequent patching is required.

Gladly, not all fixes go down this road, and it is an optional mishap.?

Given the multiple options each potential vulnerability can go through, it is no wonder that CISOs struggle to properly address vulnerabilities in their risk management processes (Threat meets Vulnerability meets asset).

Uncertainty is inherently embedded into Cyber Security.?

Hopefully these stages shed some light on the diversity of the life cycle and open up further discussion and insights as for YOUR organization's approach on dealing with yesterday, today's and tomorrow's vulnerabilities, just lurking to be discovered. by whom? that remains to be seen :-)

So what do you think?

Would you add a stage / modify one?

Or do you see it differently?

Comments welcome!

Nachshon Pincu

ICS/OT Cybersecurity Evangelist | OT Cyber consultant & Architect | Podcaster ICS Cyber Talks | Lecturer

2 年

This is a great

Noam Friedmann, CISO, CISM, MBA

Cyber Security and Compliance consultant at ActSecure

2 年

Thanks for sharing Yossi

Itzik Tzadaka ????

Sr. Technical Specialist at Microsoft

2 年

?????! ??? ' ???? ??? ?????? ??? ?? ????. ???? ???? ?? ???? ????.

Moshé M. Vered

CEO, Co-Founder, Provallo | Product | GTM | Cybersecurity | IOT| Cloud | R&D Executive Leader and Innovator |Ex-Samsung

2 年

I think the flow should look at the problem from a perceived risk vs. real risk . Being known or not known does not call for action is the perceived risk...

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了