A Zero Day Vulnerability is a security flaw that is unknown to the software vendor or the business it is found in and there isn’t a patch released yet for the vulnerability. The term “zero day” refers to the fact that the developers have had zero days to fix the security flaw that has been recently found in their software or hardware. A “Zero Day Attack” occurs when a vulnerability that isn’t yet patched (possibly not even known) by developers of hardware or software is exploited by hackers. This exploit allows hackers to breach a system through the software or hardware “zero-day” vulnerability.
In July of 2014, Google started the “Zero Day Initiative”, which was the creation of a program that consisted of security analysts from Google tasked with finding Zero Day Vulnerabilities; this team is called “Project Zero”. Project Zero researchers find vulnerabilities in hardware and software solutions and reports these findings to the manufacturer of the product. They work together to fix the security flaw and publicly release patches once the hole has been filled.
Project Zero is similar to Bug Bounty Programs, which is a deal that is offered by many websites, organizations, and software developers where individuals can receive recognition and monetary payment for reporting bugs or vulnerabilities in a vendors product offerings
Related Terms: Bug Bounty Programs, Responsible Disclosure, Vulnerability
Related Readings:
Hackers Exploit Zero-Day in WordPress Plugin to Create Rogue Admin Accounts
Data Breach at Mitsubishi Electric Caused by Zero-Day Vulnerability in Antivirus Software
Sources:
“Meet ‘Project Zero,’ Google’s Secret Team of Bug-Hunting Hackers”
How does this relate to SMBs?
How you respond to Zero-Day Vulnerabilities as an SMB depends on whether you develop hardware (HW) or software (SW) yourself, or whether you consume other companies hardware and software.
My SMB does not develop Hardware or Software – what should I Do?
For SMB’s that do not develop HW or SW, then you simply need to have a Vulnerability Alert Management Policy and process in place to deal with the security vulnerabilities that get announced for the HW and SW you consume. This process defines how quickly you have to patch your equipment with respect to the criticality or size of the risk you face. For risks that represent a total breach of your networks, where exploit code is available, and you have Internet enabled ports and protocols for the services being attacked, your policy will state – stop everything else and patch now. Lower risk vulnerabilities will allow you to take more time and plan as defined within your VAMP process. CyberHoot has a fully vetted VAMP template for you to adopt within your company.
My SMB does develop Hardware or Software (or both) – What do I need to do?
For SMB’s that develop HW or SW, you should build a Bug Bounty and responsible disclosure program or process into your development processes. On your website, list how to report critical bugs in your software and the appropriate way to report them. If you’re large enough to offer financial incentives for reporting bugs under a Bug Bounty program, publish those with instructions on how to submit the bugs and what information you’re seeking in the reports. Secondly, outline the timeline within which you will respond with confirmation of a bug and the timelines you’ll follow for developing a fix. The goal here is to avoid a situation where a security research feels spurned or ignored by you and instead of waiting for you to develop a patch, releases their findings to the Internet community in spite of “responsible disclosure” best practices.