The security industry and trade press have directed a lot of attention toward the "zero-day attack," promoting it as the threat to guard against. According to the marketing hype, the zero-day attack is the one to most fear, so measures must be put in place (i.e., buy stuff) to defend the organization.
The zero-day threat is born the moment a vulnerability is publicly announced or acknowledged. The period of time in which the threat existed before being announced is known as the "less-than-zero" threat. This article examines the less-than-zero threat, compares it to the zero-day threat, and discusses ways to protect the organization from less-than-zero attacks and vulnerabilities for which patches and signatures do not yet exist.
Zero Day vs. Less Than Zero
Once a vulnerability is publicly announced, the zero-day clock starts ticking. The announcement is typically followed by some period of time before a patch is made available. This is the zero-day period. According to accepted wisdom, organizations face the greatest danger when an attack or exploit targeting the vulnerability is verified in the "wild."
Some believe this is a flawed argument. As evidence, they point to "underground" vulnerabilities and exploits that are equally dangerous and much more difficult to detect and protect against because they are "unknown." This category is called the less-than-zero threat. Figure 1 shows the relationship between the less-than-zero threat and the zero-day threat, and the level of risk they pose to the organization. It also takes into account such factors as responsible disclosure and patch deployment.
Typically, less-than-zero threats have a different genesis from zero-day threats. Most zero-day threats are discovered through the standard bug testing process, and the vulnerability is known prior to an exploit for it being identified. Less-thanzero attacks, on the other hand, are first detected through evidence of attacks that have exploited them.
Where many zero-day vulnerabilities are discovered by white hats, most less-than-zero attacks are true black hat attacks. However, it is possible for an underground threat to evolve into a zero-day attack. This is a natural evolution of less-than-zero vulnerabilities and threats. Often a less-than-zero attack becomes widely known, and a patch is issued. It becomes a zero-day type of attack at that point.
The point of this comparison is that while a less-than-zero threat does not get a lot of media attention, it still presents a real danger, and true security-conscious organizations will take steps to protect themselves from it.
Now that the definition of "less than zero" is set, this article will examine the individual stages of this threat, the applicable defenses, and how to shorten and reduce the time of highest risk.
The Less-than-zero Threat
The first stage in the evolution of a threat is the "underground" stage. This is the less-than-zero attack. In this stage, the vulnerability and a corresponding exploit are loose in the wild. The less-than-zero vulnerability is discovered only when evidence of an unattributable attack is identified. Therefore, a less-than-zero vulnerability is not typically seen without an existing exploit.
The less-than-zero attack is usually discovered using forensic tools that re-create an attack or incident after the fact. There are no patches, intrusion detection system (IDS) signatures or other types of tools to prevent these attacks. The only possible type of defense is a heuristic or behavior-based defense, if the organization believes in this class of technology—the use of which is not the subject of this article. The best defense is conforming to best practices within the layered security model. Whether layered security technologies are combined in a single, all-in-one integrated device or in separate silos is up for debate.
Vigilant analysis to identify the attack vector is one of the best tactics to minimize the time period for this type of attack. Other factors are whether the weakness is being used for attacks against a narrow range of targets or a mass-market type of attack. Obviously, if the attack quickly becomes "known," it soon moves into the conventional zero-day stage. Therefore, mass-market less-than-zero threats quickly become zero-day threats.
Once the vulnerability and/or its exploit are known, the questions are:
- Who knows about it?
- How is the vendor of the targeted system alerted to it?
The concept of responsible disclosure is hotly debated. One camp believes that telling the vendor before releasing information to the general public gives the vendor time to make a fix available. The other camp believes that vendors do not react quickly enough. The second camp would argue that the bad guys already know about the vulnerability/exploit anyway, so it does not do any good to withhold general disclosure, and announcing the threat is the quickest way to enable organizations to protect themselves as best they can until a patch is available.
The Zero-day Threat
Once publicly known, a whole new crop of black hats can try to use zero-day threats. This author does not subscribe to the vast hacker conspiracy theory that has all black hats sharing information. There is no doubt that some sharing occurs, but there are exponentially more bad guys to worry about after the threat is made public. That is the top of the curve in figure 1. To be clear, the less-than-zero risk is a significant one. Organizations should not let the zero-day threat defense come at the expense of less-than-zero defenses.
Another important point about a zero-day attack is that if its genesis is from a less-than-zero attack, its exploit is already out there—so it is already experiencing the period of peak threat. This makes the "publicly known exploit" argument discussed previously a bit of a red herring.
Until a patch comes out, there are a few things that can be done to mitigate risk. Machines that are vulnerable to the attack need to be identified. A signature or some other behavior-based approach, such as IDS or intrusion prevention system (IPS), can detect and block it. Also, it is important to disable the services or port that serve as the attack vector and enforce this via network access control (NAC) and vulnerability scanning. Third-party patches or other types of workarounds are also possible.
"Patching" typically means the official patch put out by the vendor of the vulnerable software. Just because a patch is available does not mean that the threat goes away. With the constant vulnerability/patch process, the time from when a patch is available until it is actually applied can range from hours to weeks, depending on the size of the company and the patching process. As a result, the period of risk is extended.
While vendor and media attention has been focused primarily on the zero-day attack, the less-than-zero threat also warrants attention and resources. The reason this type of attack is not often discussed is that the majority of vendors do not have a silver-bullet solution they can sell to solve the problem. There is still no substitute for good, old-fashioned best practices in security.
is cofounder and chief strategy officer at StillSecure. He is responsible for helping to shape and develop the company's business and technology strategy and direction. In this role, he serves as a primary interface and evangelist with partners, customers and peers, as well as the press and analyst communities. He can be reached at email@example.com or via his blog at www.stillsecureafteralltheseyears.com.
©2007 StillSecure. All rights reserved.
Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the ISACA. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.
Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.