I've long been of the mindset that doesn't agree with the term "zero-day" exploit or vulnerability. Where the only party to whom it applies seems to be the victim or defender. It's a term of art I think is flawed. Let's go a little deeper so you can understand where I'm coming from on this issue.
Only discovery starts at zero.The InfoBro
Let's talk a bit about vulnerability research. It's a somewhat touchy subject in the community of practitioners right now. Why? Vendors don't like people poking at their products in a way that might reveal a less than secure platform or application. The fact, however, is that scrutiny of application development security like with Solarwinds (see SUNBURST, SUNSPOT) and recently recognized Microsoft flaws with Exchange their email server, obviously, is necessary. Despite seemingly tight Development Security Operations (DevSecOps) or at least claims from companies where they are purporting that they pay close attention to security in the development of their products, there are always vulnerabilities that are present, so there is a need for research.
I can't possibly recount the number of times that I have personally been witness to push back from vendors regarding their representation of attention to security. The fact or revelation of a flaw causes the inevitable hair on fire moment that results in a request to "cease and desist" examination of their product under the color of intellectual property infringement , e.g., reverse engineering or other claims. Well, I'll just leave that right there, because the next bit is key.
Research into a vulnerability begins as a blank slate. The hunt begins when something, such as an unexpected response from an input made to an application, is discovered. When a researcher delves into discovery, that's the beginning. That's the zero day. The rest of the work is centered on understanding what the discovery is and the viability of developing a fruitful and repeatable outcome by exploiting it. This last part is crucial, because the goal is to present the findings to the vendor or other community member and plug the hole.
Researchers who are adherents to responsible disclosure are not interested in throwing people under the bus. The desire is to make everything safer. That's the goal. While I'll admit there is incentive that has been introduced through bug bounty programs. One thing that can be relied upon is this: It's almost never just one researcher who is the only one aware of an exploitable vulnerability for long. Once the examined product or platform is available to be examined publicly, it's usually game on.
Being at zero is ephemeral as it relates to discovery. As has been intimated it's a transient status the problems only arise when the discovery is made actionable. When one can get an idea of damaging consequence from the discovery that s where things get interesting. That status and the acceptable rules for disclosure are where the rubber meets the road.
Traditionally, there is a triad used in cybersecurity and information security which focuses centrally on confidentiality, integrity and availability. This triad is, in my opinion (I'm not alone on this as you can see in Section 10. Definitions, item 17, page 28 of the OMB memo), lacks two other critical elements that must be considered when examining the risks associated within the context of entity to entity relationships. That is to say anytime two things are working together all of the elements matter.
The addition of authorization and non-repudiation to the mix as elements is crucial. These elements are now at play regularly with the introduction of the zero trust architecture. The criticality of any specific element not withstanding, the additional two add an element for after action for the implementation of applications. How does this relate to the vulnerability phenomena? The addition of those two elements provides a starting point that can be leveraged to position prevention of successful exploitation due to enforcing rules about what is allowed to happen at a given time by a specific functionality with additional confidence.
When you hear the term "zero-day" take the full chain of events that bring whatever the issue to light in mind. At some point someone knew about the thing and that was the zero point, every thing after that discovery is zero+n. Any exploit observed for the first time has likely been refined over time to make the execution controlled and predictable. No has ever unleashed a "zero day" attack or is hoarding zero day exploits. it's a misnomer for "we just found out that..." not that it was just discovered. In other words refine the process of engineering, execution policy decisions and implementation and take back discovery from the bad guys.
Stay safe. Look deep and discover things. Subscribe.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.