Since my participation in Friday's roundtable discussion (see previous blog entry) has probably made some wonder about my level of security comprehension, and question whether English is my first language, I thought I would try to clear up some confusion here, by paraphrasing the thoughts of others.
One of the questions posed was: What do you think is the ultimate solution to end the patch/hack/patch cycle, which is the cornerstone of today's enterprise security?
This is an easy one. There is no solution and there never will be one. Yep, sometimes the truth hurts. Since the coding community shoulders some of the blame, I will explain it to them as follows:
10 HACK
20 PATCH
30 GOTO 10
That's been the cycle ever since the first physical patches were applied to Hollerith's tabulating machine punch cards (which I believe came on a Tuesday). It is rumored that these initial patches were issued in response to the first hack, executed by late 19th century tabulating system competitors, Charles F. Pidgin and William C. Hunt.
First off, every protocol, platform and framework of telecommunication networks was initially developed without consideration, or need, for security. Since technological progress does not allow "do-overs", this will always be a core issue. As a result, many have adopted the strategy "if we apply enough band aids, it will stop the bleeding." Using that strategic analogy requires one to think of applications and the internet as a hemophiliac being hacked with heparin. Despite the security vendors' attempts at factor VIII infusion and software companies' protamine injections, the prognosis is poor--far from a cure. (I'm done with the medical analogies)
Prevention is often touted the best form of protection. But how do we always know what we're preventing? In a general sense, the obvious answer: vulnerabilities and exploits. However, without knowing of their specific existence and mechanism of action, we cannot provide protection through prevention. While the security community's vulnerability disclosure is often an informative means of discovery (when not being silenced by a court order), a large portion of discovery comes from analyzing systems post-exploitation. Thus, we are left with the unending process of hack, patch, hack, patch....until perhaps a form of precognitive patch is developed.
An examination of traditional patch processes reveals the cyclical pattern:
- Vulnerability Identification
- Criticality assessment
- Patch development and testing
- Patch distribution
- Public adoption and installation
- Get p0wn3d via new exploit, rinse and repeat
This over simplification assumes that patches are applied immediately upon release and that no problems or conflicts occur with installation and subsequent function...assumptions far from reality.
The chronological complexity of the vulnerability patch process is somewhat self-defeating. The period of time between vulnerability's public disclosure and its corresponding patch availability --the window of exposure-is a critical interval. During this period, systems are theoretically open to exploitation. In addition, variability in the mean-time-to-patch, or patch-latency, can extend the window of exposure, when patch installation lags considerably behind its availability. This can create a race to reverse engineer the patch, where attackers try to produce the exploit prior to systems implementing the patch. The end result often provides adequate time for the creation of malicious programs that enable automated exploitation by the masses.
A relevant variable of this analysis lies in the definition of responsible vulnerability disclosure. Differing disclosure models demonstrate the opposing fundamental beliefs of security researchers to that of many corporate vendors. Exposing the practice of security through obscurity has unfortunately led to organizations pursuing legal prosecution instead of addressing the underlying system insecurities. As long as this issue remains unresolved, with vendors choosing to ignore system vulnerabilities or prevent full disclosures, the time-to-exploit will be shorter than the time-to-patch.
Some companies have made greater efforts in code review and patch availability. Microsoft's two new initiatives, the Exploitability Index and the Microsoft Active Protections Program (MAPP), were developed to address these issues. However, October's patch Tuesday consists of 11 security bulletins, four of which are rated as "critical." This follows the release of a high number of vulnerabilities and flaws by several industry players. Apple's recent Security Update 2008-007, patched 40 documented security flaws, raising this year's total to 250, and Cisco has released a bundle of security patches for IOS vulnerabilities, including a critical flaw in SNMP.
Despite advances in security and patch management, little has changed over time. Rapid progress in information technology has created innovations in access to resources, provided rich platforms for creative development and revolutionized the human computer interactive experience. Unfortunately, the competitive business pressures of release-to-market deadlines produce products deficient in quality assurance and inadequate security testing.
The "defender's dilemma", as discussed in military applications, refers to a difficult tactical measure. As a defender's assets grow larger and more desirable, so will the number of attackers. The defender is faced with the problem of having to protect more, against a greater threat. The attackers only need to find one point of entry to compromise, while defense is required at every potential area of attack. This scenario translates well into information security, however, now it is the "CSO's dilemma."
Once again...there is no solution...but at least there's job security.
Patches can be applied to me at: greyhat@computer.org