CDM-CYBER-DEFENSE-eMAGAZINE-March-2019

kind. Many of them require some kind of privileged access already and as I alluded to earlier,
remote code execution is exceedingly rare.
This brings us to Schrodinger’s vulnerability, a play on the oft used trope of Schrodinger’s cat,
which to paraphrase implies that until you look in the box, the cat is both alive and dead. A more
contemporary reference would be the response that former Secretary of Defense Donald
Rumsfeld once blurted out in reference to ‘known knowns’, ‘known unknowns’ and ‘unknown
unknowns’ with the latter being the riskiest.
Let’s map this to an information asset today and call-back the alarmist reference I started this
article with on. This information asset that is out of date but might have a vulnerability even there
are none publicly available is going into the region of ‘unknown unknowns’. We know there are
no publicly available vulnerabilities but there may be a vulnerability that exists that we just don’t
know about. So how probable is this. Fortunately there’s no need to speculate since there’s plenty
of research to draw conclusions from. ‘Zero days, Thousands of Nights: The Life and Times of
Zero-Day vulnerabilities and their Exploits’ is a piece of research by Lillian Ablon and Andy Bogart
that focuses on this very issue. They found that if a zero-day existed and was hoarded by an entity
but kept from public view, it would stay that way for an average of 7 years.
What this means for us is that regardless of what version of software you are on, there may be a
zero-day that exist (however improbable) but no one will know about it and it will stay that way for
an average of 7 years. What's worse is that if you update your software to the latest version, then
that version too may also contain this zero-day, even though you are ‘fully patched’, simply
because the code refactoring in the new version has not taken into the account the zero-day by
virtue of the fact that it’s still an unknown. The research does make a distinction for end of life
software, since this will never be patched again, so if a new zero-day is discovered then it
effectively becomes ‘immortal’ since the vendor will never release a new patch to cover this.
Using exploitability for defense
Combining a few approaches can stave off junk risk and avoid you chasing contrived scenarios
that will never materialize:
• Switch from pentesting to crowdsourced security for external assets: Pentesting
methodology is starting to be considered a legacy approach to offensive security testing.
It does not emulate a hacker in any way – it only gives you a frozen snapshot of security
posture at a specific point in time, nothing more. Crucially, crowdsourced also gives you
actionable threats with proof of concept and their methodology maps more realistically to
how attackers behave (for example, no time limit on testing), while pentesting focuses on
theoretical threats.
• Having out of date software doesn’t mean you’re automatically vulnerable! While this may
shock some individuals, if the specific threat vector that your version of software is
vulnerable to isn’t exposed in its current configuration, then you are safe.
• Practically all attacks focus on known vulnerabilities so updating your software to the latest
version to protect against ‘zero-day’ attacks is irrelevant. The new version is as likely to
be vulnerable since no code has been refactored to account for the zero-day, hence its
unknown status. Updating software is for known threats, not unknown ones.