A zero-day is a vulnerability being exploited before a patch exists. Defending against one cannot rely on recognizing the exploit, because nothing has been catalogued yet. It can rely on the fact that exploitation still has to change something on the target system to produce impact, and that change can be evaluated against what the system is authorized to do.
What a zero-day actually is
The term gets used loosely. Precisely, a zero-day vulnerability is one the vendor has had zero days to fix. A zero-day exploit is working code that takes advantage of it. A zero-day attack is that code used against a real target.
Two things follow that matter for defense. There is no patch, so patch management has nothing to deploy. And there is no signature, because signatures are written after somebody analyzes an attack that has already happened somewhere.
What an exploit has to accomplish
It is worth being specific about the sequence, because the defensive opportunity is in the last step rather than the first.
- Reach the vulnerable code. Get input to the component that mishandles it, through a network service, a file, a document or an interface.
- Corrupt execution. Use the flaw to gain control of what the process does, through memory corruption, injection, a logic flaw or a deserialization bug.
- Establish control. Execute code in the context of the compromised process.
- Produce impact. And this is the part that matters: write a file, create a service, modify a registry key, alter configuration, encrypt data, or move to another system.
The first three steps are where the novelty lives, and they are the steps a defender cannot anticipate. The fourth step is not novel. It looks the same as it did ten years ago, because the set of things an attacker can usefully do to a system has not expanded nearly as fast as the set of ways to get in.
Why patch-dependent and signature-dependent defense struggle
Neither of these is a bad control. Both are structurally constrained here.
Patching needs a patch. By definition a zero-day has none. Once one ships, enterprise patch cycles run on testing and change management for good reasons, and available data puts real-world remediation times well beyond a month for critical vulnerabilities and considerably longer for complex applications. Meanwhile median time from disclosure to exploitation is now measured in days.
Signatures need prior analysis. A signature describes an attack somebody has already seen. For a genuinely novel exploit there is nothing to describe, and the window between first use and first signature is the exposure.
Network-layer virtual patching needs a rule per vulnerability. IPS and WAF rules that block exploitation of a specific CVE are effective and widely deployed. They require the vulnerability to be known well enough to write the rule, which puts them on the same timeline as signatures for anything genuinely novel.
Behavioral detection needs the behavior to look wrong. It catches many exploits, particularly ones producing unusual process behavior. It is the strongest of these four against novelty and it still operates after execution has begun.
The step that is never novel
An exploit that gains code execution and then does nothing has cost the attacker a valuable capability for no return. Impact requires change.
That is the asymmetry worth building on. The exploitation technique can be entirely unprecedented. The change it needs to make afterward is drawn from a small and stable set: files, processes, services, registry, configuration. It is the same set of changes that decides how attackers move laterally once they are inside.
A control that evaluates whether a change falls inside a system’s authorized operating state does not care which vulnerability produced the attempt. It resolves the same way for a CVE published this morning and one nobody has found yet.
Mimic profiles each protected system in its authorized state and evaluates changes at the kernel before they execute, which means enforcement holds for vulnerabilities with no CVE, no signature and no vendor fix, including on end-of-life systems where a fix is never coming. The vulnerability remains. Its exploitability does not.
This does not make patching optional. Patching removes the flaw and remains the correct long-term answer. What enforcement does is make the exposure window survivable while patching runs, and cover the systems patching will never reach.
Zero-day defense, answered.
What is a zero-day exploit?
+A zero-day exploit is working code that takes advantage of a vulnerability before the vendor has released a fix. The name refers to the vendor having had zero days to patch. Because the vulnerability is not publicly known or not yet fixed, neither patch management nor signature-based detection has anything to deploy against it.
Can you defend against a zero-day if there is no patch?
+Yes, though not by preventing the vulnerability from being exploited. An exploit that gains code execution still has to change something on the target to produce impact: write a file, create a service, modify the registry or alter configuration. Evaluating that change against the system’s authorized state does not require knowing anything about the exploit.
How long is a system exposed to a zero-day?
+From first exploitation until a patch is developed, released, tested and deployed. Published data puts median time from disclosure to exploitation at days, while real-world remediation for critical vulnerabilities commonly exceeds sixty days and runs to months for complex enterprise applications. For end-of-life software the exposure does not close at all.
Why do signatures not stop zero-day attacks?
+A signature describes an attack that has already been observed and analyzed. For a genuinely novel exploit there is nothing to describe until somebody encounters it and writes the rule. That gap between first use and first signature is the exposure, and it has widened as the interval from disclosure to working exploit has compressed.
Is virtual patching the same as defending against zero-days?
+Related but not identical. Network-layer virtual patching deploys an IPS or WAF rule that blocks exploitation of a specific known vulnerability, which requires the vulnerability to be understood well enough to write the rule. It is effective for known CVEs awaiting a patch. For a genuinely unknown vulnerability there is no rule to write.
What protects systems that will never be patched?
+End-of-life software and third-party components with no vendor support carry permanent exposure under any patch-dependent model. Controls that do not depend on patch availability are the remaining option: restricting what those systems can reach, and evaluating changes to them against a known-good baseline so exploitation cannot produce its intended effect.
Does zero-day defense replace patch management?
+No. Patching removes the flaw and is the correct long-term resolution. Enforcement makes the exposure window survivable while patch management runs on its normal timeline, and covers systems that will never receive a fix. The two operate on different timescales toward the same outcome.
