Vulnerabilities in digital technology systems are many and varied – some are known, some are unknown and many of them are unclear. But one thing is clear above all doubt and that is that every technology is fundamentally vulnerable. All the systems, the software, the communication devices, the hardware, the applications, etc. – all were designed and designed by human beings who are, as we know, imperfect.
Basically, every product on the market is a “bag of vulnerabilities waiting to be discovered”. Any technology can realize its “potential” and provide many vulnerabilities, since it is already born with several vulnerabilities built into it and “grows” and collects several new vulnerabilities along the way (through changes or maintenance, etc.).
In the first stage, the vulnerabilities are unknown, many of them will remain in this state and others will be discovered. So, in the first stage, every vulnerability is unknown (waiting to be discovered).
In the second stage, the vulnerability is revealed, to a very specific factor (known to an individual/few). This stage begins the moment a person or organization discovers it and has an interest in it. An academic researcher, an organizational researcher, a political/intelligence/intelligence agency or an independent researcher are very different “parents” for the discovery of such a vulnerability, and they affect in a different way the “first steps” it will take in the world.
So, for example, some researchers would prefer not to publish the vulnerabilities they discovered and keep them private while others would prefer to sell them on the dark web (at a stage when they are still not so well known). Some researchers would prefer to disclose the vulnerabilities in an orderly manner to the original component manufacturer, gain fame And an assessment and perhaps even a modest financial reward relative to the replacement value of such a vulnerability in the world of crime, but not every investigator has the same motivation regarding whether and how to reveal what he discovered.
In the third stage, which can occur at a relatively early or late point in time, sometimes even after a few years or decades, the vulnerability becomes the property of the general public, and the manufacturer (not always) will act to fix it, since it already affects the life cycle of the product or the technology at this stage when the vulnerability known to all.
This is where the CISO joins the “official” picture for the first time, since here it is already a known risk, and there is direct responsibility for the fix. There are no excuses in this regard: the risks have been updated and it is time to include them in the list of risks facing the organization.
In the fourth stage, the organization faces the possibility that someone will take advantage of the vulnerability, within the time window that will pass until the patch/update is provided by the manufacturer. Not every vulnerability has a known public exploit code, but if there are, one or more, then this phase stresses organizations since the vulnerability can actually be implemented by any party. It should be noted that even if it is not currently known how to exploit the vulnerability, it does not mean that someone did not discover it and it is possible that it is already being quietly exploited.
The fifth stage focuses on repair. At this point in time, whether the vulnerability is widely known or not (the manufacturer may have discovered it on the dark net in one of the anonymous trading arenas such as Zerodium).
Whether used in practice or not – the expectation is that the provider is already handling it officially through the right channels, especially when it comes to a vulnerability in an active and up-to-date product (fully supported during its product life) or one that has a broad impact on a large customer base (such as WhatsApp, Windows, etc.) B).
Some vendors release fixes quickly, others will take the time to understand more deeply the issue at hand, prevent a “rollback” of the fix or solve the problem from the root. As mentioned, the sixth and optional step is – that some vulnerabilities will not be fixed at all by the provider and this happens more often than you would imagine.
For example, in your home routers (see the D-LINK case, for example, in the model of an ADSL router in which a vulnerability was discovered for unauthorized remote code execution, and has not yet been fixed since it is a model that is not the latest). In these cases, the exposure should be minimized, or the component replaced, or the existing risk accepted – if possible.
A seventh and optional step, but completely muscle, is that some of the fixes will be partial and will not resolve the full extent of the vulnerability. Some will solve it gradually, when after a few months the permanent and complete solution will be delivered. Some of the fixes will “disappoint” you, will cause new errors by the very act of installing them, and may lead to regression (“new” bugs) or, God forbid, even problems of availability and damage to functional continuity.
In some cases, after a certain time and receiving feedback, it will be found that the patch solves the problem only partially or the vendor believed that the patch would solve the problem, or it solves it but not permanently or that another update is needed.
Luckily for us, phenomena of this kind do not happen all the time and many suppliers show good responsibility and professionalism. However, given the many ways in which a vulnerability can develop and be damaging, it’s no wonder that CIOs in organizations struggle to effectively deal with each vulnerability as they weigh risks.
The life of the CISO is one big and continuous ordeal, surrounded by uncertainty and risk management. His professionalism is being put to the test especially at a stage that was supposed to be free of known risks for him.