What if Government Regulation Focused on Creating a Realistic Framework to Outline and Enforce Security Standards that Vendors, Manufacturers and Producers Have to Follow?
Do you use an Adobe Product? Then you have a Zero Day on your System right now. I would almost vouch for it. Because there is rarely an Adobe Product that does not have a security flaw in it – in fact, most have several – all the time – ongoing. Check this out for some painful reading. If we take the vulnerabilities from the latest advisory at the date of writing this article, APSB12-08:
These updates resolve an integer overflow in the True Type Font (TTF) handling that could lead to code execution (CVE-2012-0774).
These updates resolve a memory corruption in the JavaScript handling that could lead to code execution (CVE-2012-0775).
These updates resolve a security bypass via the Adobe Reader installer that could lead to code execution (CVE-2012-0776).
These updates resolve a memory corruption in the JavaScript API that could lead to code execution (CVE-2012-0777) (Macintosh and Linux only).
Adobe has been unable to meet the challenge of developing secure software for many years now, and as a consequence has become a perennial favorite target of malware and hackers, contributing 5 of the Top 10 Vulnerabilities in Kasperskys’ 2012 Q1 Threat Evolution Report, consistent with the Q1 2011 Report. The infamous Blackhole Exploit Kit, a web-based drive-by exploitation framework often used to infect victims with the Zeusbot Trojan accounting for almost 40% of exploit toolkits in the wild, also targets Adobe products aggressively.
Predictably, flaws and vulnerabilities in Adobes’ products have been implicated in a large number of high profile breaches, including RSA, Google, and high profile defense and military targets, among others. The situation is exasperated by the factor that Adobe is sluggish with the release of security updates even for known Zero days in the wild. The trend shows no signs of abating.
The risk posed by the seemingly never-ending string of vulnerabilities in Adobes’ products has not gone unnoticed on in the past. But the dependency on the PDF Format and the popularity of Flash on the web has resulted in the topic being swept under the carpet, even though it is the root cause of many security breaches.
It may seem like I have a grudge against Adobe. But, I could just as well have used Oracle and Java, or many others as an example– Adobe is not the only insecurity offender, but its products, namely Acrobat and Flash, are widely installed on endpoints around the world and have had a bad history with regard to security vulnerabilities. A report from Secuina from last summer shows that third-party programs are responsible for 69% of the vulnerabilities on a typical endpoint. Interestingly, Secunia’s report showed that organizations could realize an 80% reduction in risk can by either patching the 12 most critical or the 37 most prevalent programs in a sample portfolio.
I recently read an article from James Turner over at O’Reilly, in a column titled “The overhead of insecure infrastructure”, where the author succinctly states, “In a world where we had made security a must-have in the infrastructure we build on, rather than in the code we develop, think of how much more amazing code could have been written. Instead, we spend endless time in code reviews, following best practices, and otherwise cleaning up after our security-challenged operating systems, languages and platform. Last weekend, we honored (at least in the U.S.) those who have given their life to physically secure our country. Maybe it’s time to demand that those who secure our network and computing infrastructures do as good a job.”
I would like to extend his observation and rant to the Soft- and Hardware Industry in general. Essentially, organizations are forced to spend a vast amount of resources, in assets, manpower and financial form to protect themselves against risks imposed by the tools they require to do business. Antivirus, Antimalware, IDS/IPS, Content-filtering. The cost is staggering, and once a specific threshold in scale is reached, the complexity involved makes it almost an impossible task.
A single vulnerability can be encountered in the wild, utilized in a multitude of different forms, in various viruses, trojans, exploit-kits, or just a single instance of malware mutated or encrypted, each requiring its own signature to be detected. If there is one thing worse than being successfully breached, it is not knowing about it. In the case of a targeted attack, an attacker can create a unique binary of his malware, intended only for his victim, eliminating the possibility of any vendor acquiring a sample to even create a valid signature.
The going wisdom is that all of this can be countered with one single patch. That is of course entirely true, but that wisdom sadly does not account for complexity and scale – Most organizations do not find themselves faced with having to patch one application. They often have to patch thousands of systems with hundreds of applications, many requiring patching most quarters. Patching itself is also not a trivial matter. Some patches require special installation procedures; others cause unintended behavior, making their application to productive environments feel like a round of digital Russian roulette for anyone unfortunate enough to be tasked with the job.
That patch management on a large scale is difficult, and has been a primary driver for many other technologies, such as Intrusion Prevention and Detection, SIEM and Application firewalling. We know that it is challenging if not impossible to reliably patch everything – so we don’t even try. One anecdote I heard was about the Head of Security for a major financial player saying that they had made a “strategic decision” not to patch. A nice way of saying, they gave up. Something else I have heard repeated is that with an IPS, you don’t need to patch. The cognitive dissonance is astonishing. Even if you do manage to patch everything, that still will not protect you against Zero day. No-one really knows for sure how many exploits are hidden away. Considering the rate at which vulnerabilities are publicly disclosed, a good case can be made that there will be a few that no one is talking about.
Whilst all of this may be a huge boon for security vendors, it is a huge overhead for everyone else, resulting in a risk of almost 100%. Considering how widespread the products are used, by the Military, Governments, Intelligence, Manufacturing, Finance essentially everyone. Even among the security community, PDF’s are widely used.
Whilst Adobe should be lauded by all would-be entrepreneurs of the Gordon-Gecko school of business for their skill in externalizing their costs, a simple cost-benefit calculation for everyone else quickly highlights that for the sake of one company gaining a slight competitive advantage in the form of development cost savings or faster release cycles, it is not beneficial for the economy as a whole to have to allocate a large percentage of their operating budget to attempt to compensate for the resulting shortcomings in quality and security. In its simplest form, the analysis is:
Adobe_Savings = X;
Cost_to_World = Y * EVERYONE.
Or to formulate it in a slightly more cynical way: one company saves a few bucks, and everyone else gets to pay for the privilege.
Similar to a single patch mitigating the risk of countless different malware and attacks, one single organization applying a more rigid Software Development Management Lifecycle, employing a few good security analysts and dedicating enough resources to audit the code prerelease would save millions of other people having to protect themselves. Many of the vulnerabilities appear so trivial,that most are found using Blackbox methods, and exploitability, as is made evident by their prevalence in the wild, also appears simple. There is an argument that states that it is impossible to catch every issue, and that may be true. But this argument is also used by many to not even try, leading to vast disparages in the amount and the frequency of discovered vulnerabilities. It can certainly be excused that a flaw can be missed and allowed into production, especially in large or complicated products, but there a reasonable and expected amount of flaws, and then there is what can only be described as bad coding and development practices.
Why can a company like Adobe with a $16 billion market cap not dedicate more care, attention and resources to fix something that is evidently a huge problem and a great concern, posing a great risk with potentially severe implications, including threats to national security?
Due to the importance and widespread use of something like Adobes’ PDF format, should it not count as “Critical Infrastructure” in a way? That is what Government Regulation should focus on– creating a realistic framework to outline and enforce security standards that vendors, manufacturers and producers have to follow and that stipulates minimum security quality requirements. It would be by far the more cost-efficient and manageable solution, and would have a positive impact on security entirely disproportionate to its cost. It would not solve all of our security issues, but it would be a right step in addressing the root cause of many of the risks.
