Zero-day vulnerability
|
The JC’s amateur guide to systems theory™
|
Zero-day vulnerability
/ˈzɪərəʊ-deɪ ˌvʌlnərəˈbɪlɪti/ (n.)
A vulnerability in code that hackers find before the software vendor does. Because the vendor is none-the-wiser, there is no patch for the bug, meaning until the vendor (a) twigs that there’s a problem, (b) works out how to fix it and (c) rolls the patch out to its customers, hackers who know about it can have a field-day. They can have catastrophic consequences: the “Stuxnet” virus, which basically rooted Iran’s nuclear energy sector in a weekend, was introduced through a zero-day vulnerability in a seemingly harmless Siemens programmable logic controller.
The complexity of modern-day computer code and interconnectivity is such that zero-day vulnerabilities are pretty much impossible to prevent. There is no end to the number of Russian troll farms, idle romanian Coders who haven’t got anything on from UpWork and oily Matthew Broderick-type teens who know more than they should about coding, would think nothing of precipitating World War III and have time on their hands to search for unexploited vulnerabilities in public-facing code. It is not a question of if, but when. The harder you are looking at sector A, the more you can be sure hackers are targeting sector Q.
Therefore — as well as writing excellent, bug-free code — target firms need rapid response experts who can quickly identify the exploit, shut it down and patch it.
The zero-day vulnerability is an excellent metaphor for the vulnerabilities that financial services institutions and markets have to unexpected frauds, snafus and market crashes. These also have a habit of appearing exactly where your pre-formulated compliance, legal and risk defences are at their joins, seams and weak spots because that is where mendacious players will go: where you are not looking.