May 5, 2009

“Silent updates” vs. “loss of control”

In recent years the Web browser has increasingly become the number one target as an infection vector for vulnerable hosts.
With researchers from Google and IBM Internet Security Systems we analyzed the patch level of the global Web browser population in our “Insecurity Iceberg” study, published at DefCon 16 in 2008. We found that at any day from January 2007 to June 2008 at least 45.2%, or 637 million users, were not using the most secure Web browser version - and these numb
ers (the tip of the iceberg) do not include out-of-date Web browser plug-ins, which are equally accessible for an attacker to compromise the host.
After our study we felt that there is room for improvement to do better - to  protect a larger share of the Internet population - and that the mechanisms used to update Web browsers play a key role to achieve this.With research colleague Thomas Duebendorfer from Google in Zurich I've finally had a chance to look deeper into the performance of Web browser update mechanisms. You can find the research paper describing the effectiveness of the different update techniques of Google Chrome, Mozilla Firefox, Apple Safari, and Opera on my main Web site
Not surprisingly we found that full automation of updates delivery requiring no user interaction (“silent updates”) outperformed the other patching technique found in popular Web browsers. Based on the “Insecurity Iceberg” we see “silent updates” as a desirable path to reduce the risk exposure of a large part of the Internet population.
However, there is this looming “loss of control” argument over mechanisms that silently update an application without any user interaction. Especially “expert users” require control over what is installed on their machines. Let me dig deeper into this “loss of control” argument.
In security as in other areas of real life there is no “one size fits all” solution. With respect to update mechanisms the population of software users of a given application is often treated as a single massive homogenous group of users - deserving one single update technique (and when using a commercial product, the update technique deployed is often tailored to the needs of the best paying group of customers).
However, from a bird’s perspective I can see three main classes of software users:
  • Organizations running business critical applications
  • Power users, experts
  • Ordinary users (home users and companies without professionally managed IT infrastructure)
These classes of users have distinct properties with respect to their ability to secure themselves, their resources, and expertise. But they all share one and the same Internet - where Web
 browser attacks originate - with all of us.

It is clear that “silent updates” is no option to keep business critical databases at the latest patch level in a large organization. However, business critical applications typically benefit of many layers of perimeter protection and are managed by professional staff. Patch management processes in organization typically run through risk assessment, resource scheduling, and compatibility testing to determine when updates are implemented. This class of users has the expertise to manage and parameterize complex update mechanisms in order to fit their need and schedule.

Expert Users
Expert users don’t need to be excessively taken care by taking control over updates out of their hands. They supposedly know what they do and have the expertise to assess their risks in doing so. They either use the applications themselves or manage them for smaller organizations. This group of users also has the expertise to manage and customize update mechanisms.

Ordinary Users
On the other hand, we have more than a billion technically rather unsavvy Web users connected to the Internet with minimal or no perimeter protection. They typically use whatever is installed on their machine and go with the default setting of whatever application they choose to install. There is absolutely no need to confuse this class of users with unnecessary security decisions - which they anyway don’t understand. I consider “silent updates” the best solution for this group of users.

Based on these categories, whom do you want to protect first? Whose failure to apply patches in a timely fashion has the most impact on security at a global scale (say botnet creation)?
Fortunately, with respect to update mechanisms, the answer to the above questions is not an  “either or” option. We have more options and should play this card wisely. As a one liner: give power users the options they need and protect the masses of users through secure default settings with “silent updates”.
For example, roll out Web browsers with integrated “silent updates” enabled by default. The masses of users will not change these settings and are happily surfing the Web without bothering about the technical details regarding updates or security - details they would likely not understand anyway. A large user population enjoys the additional protection through the persistent, automated, and timely installation of the latest patches.
Expert users on the other hand can be given the option to customize  the default settings of the same Web browser - either through specialized UI dialogs or documented settings in configuration files. So this group has the option to customize the software and update mechanisms to their needs.
The same reasoning applies to the software vendors with respect to the when patches are made available. Fixed patch days are good for organizations. It is however hard to understand why more than a billion highly exposed users have to wait for the next Patch Day to get the badly needed protection. From the security perspective I consider it more desirable to release patches for critical applications with a large base of poorly protected users (e.g. Web browser, plug-ins) as soon as possible - while keeping fixed patch days for other applications to meet organizations needs. There is room to choose the right balance.

Content of updates
A word about the content of updates. We showed in our paper that enforced “silent updates” outperform any other update technique. However, “silent updates”  are primarily needed for security patches and updates that do not change existing functionality - and are required not to break existing software dependencies and user experience. There is no need for other types of updates and feature changes to be implemented as timely as critical security patches. However, today all types of software updates are typically rolled out using the same mechanism. Software vendors should distinguish “security updates” and “major feature changes” in their update path and resist the desire to push new applications to the market - thereby abusing a mechanism meant to deliver security updates and undermining the trust in these security update mechanisms. New or changed features that could provoke compatibility issues or major changes in user experience should be indicated as such - and the user should be given the choice to accept/deny the installation of them - making him aware of the changes.

What if it breaks?
What about a security update that unexpectedly breaks badly needed functionality? This would rightly upset any business or private user. Even the best testing and QA processes of the software vendor can not one hundred per cent exclude this from happening. A simple rollback functionality to bring the application to the state before the latest update was installed would suffice to enhance the trust in silent and automatic updates - and mitigate the mess after a failed update. This can be implemented with reasonable effort in almost any application. The fewer and less complex the dependencies on other applications or the operating system,  the easier it is to implement a rollback functionality. Complexity is our worst enemy in security. Anyone who ever locked himself out of a Cisco Firewall while remotely managing it is grateful of the fact that the device restarts with the old configuration - as long as you don’t commit the recent changes.

"Best used before" ..
While organizations and power users with the right level of skills shall be given to option to manually control the update process - this is the perfect place to refresh a major proposition for our “insecurity iceberg” study. It is important to making the users aware of the risk they are exposing themselves and their host to, but without introducing additional complexity. Almost all users are familiar with the concept of ”sell by”, ”expires on”, or ”best before” date stamps on perishable goods. I believe that the establishment of a ”best before” date for all new software releases could prove an invaluable means to educating the user to patch or ”refresh” their software applications. Whether an update is delayed manually or accidently, the user can only take action given the information is easily available.
At the end of the day we have to do a cost/benefit analysis by looking at the whole picture of “silent updates” - focusing only on a specific group of users or risks does not help us to improve security. Security is a tradeoff and I believe that today we have the knowledge, technology, and facts to find better tradeoffs. 

Providing data for facts based decision making was exactly the goal of our recent  research into Web browser security.

May 4, 2009

Welcome to the Dynamics of (In)Security

After several years in IT security and research it is about time for me to provide a better platform for publications and interactivity. My “Dynamics of (In)Security” blog will be 1) a place for the publication of findings that neither justify a whitepaper nor an academic publication, and 2) a platform for feedback on my research.

As I won’t start a new blog without content lined up - wait for another day: Tomorrow I will release a new paper (together with Google who enabled and supported the research) where we compare the update dynamics of Google’s Chrome, Mozillas Firefox, Apple’s Safari, and Opera. Four Web browsers with four different update strategies.

Best regards