Using Model-Driven Risk Analysis in Component-Based Development

Introduction

When your computer crashes just as you are about to take a last print out on your way home it is annoying. But when software glitches cause erratic behaviour of critical functions in your car it may be serious. Products such as cars, laptops, smart phones and mobile devices in general are not sold as finished products, but rely more and more on software components that may be upgraded several times during their lifetime. The problems faced by Toyota in explaining what caused the problem with the sticky accelerators (Ahrens, 2010) illustrate how upgrades may interact with the rest of the system in unforeseen ways. The flexibility offered by modular development facilitates rapid development and deployment, but causes challenges for risk analysis that are not addressed by current methods. By risk we mean the combination of the consequence and likelihood of an unwanted event. By risk analysis we mean the process to understand the nature of risk and determining the level of risk (ISO, 2009b).

A widely adopted requirement to components is that they need to be distinguished from their environment and other components, in order to be independently deployable. This distinction is provided by a clear specification of the component interfaces and by encapsulating the component implementation (Crnkovic and Larsson, 2002). The same principles of modularity and composition should apply to risk analysis methods targeting component-based systems. A modular understanding of risks is a prerequisite for robust component-based development and for maintaining the trustworthiness of component-based systems. Ultimately, one cannot have component-based development without a modular understanding of risks.

To understand the risks related to deploying a new component or upgrading an existing one is challenging: It requires an understanding not only of the risks of the component itself, but also of how its interactions with the system affect the risk level of the system as a whole and how they affect the risk level of each other. An example is the known buffer overflow vulnerability of previous versions of the media player Winamp, which may allow an unauthenticated attacker using a crafted file to execute arbitrary code on a vulnerable system. By default Internet Explorer opens crafted files without prompting the user (Secunia, 2006). Hence, the probability of a successful attack is much higher if a user utilises both Internet Explorer and Winamp, than only one of them.

The likelihood of an unwanted event depends partly on external factors, such as the likelihood that a threat occurs. In conventional risk analyses the parts of the environment that are relevant for estimating the risk-level are therefore often included in the analysis. Furthermore, in existing risk analysis methods (Alberts et al., 1999; Farquhar, 1991; Swiderski and Snyder, 2004), the environment and the time-frame are viewed as constants. These features of existing risk analysis methods make them poorly suited to analyse modular systems whose threats varies with the environment in which the systems exist (Verdon and McGraw, 2004).