A Method for Model-Driven Information Flow Security

Introduction

Security incidents occur on a daily basis within many companies. In CSI/FBI Computer Crime and Security Survey for 2005 (CSI/FBI, 2005), 74% of the companies reported security incidents. Despite the importance of security, careful engineering of security into overall design is often neglected and security features are typically built into an application in an ad-hoc manner or are only integrated during the final phases of system development (Lodderstedt et al., 2002).

Model-Driven Security (MDS) (Basin et al., 2006) advocates the opposite. MDS aims to raise the level of abstraction in design and development of secure systems by supporting (1) a model-driven development process in which security is taken into account from start to finish, (2) a clear separation of abstract, platform independent models (PIMs) and refined, platform specific models (PSMs), and (3) adherence preserving transformations between PIMs and PSMs.

The central idea of MDS is that systems can be specified and shown to be in adherence with security requirements at different levels of abstraction. Abstraction is believed to simplify analysis, facilitate reuse of designs and early discovery of design flaws. At each level of abstraction, we distinguish between a system specification and a set of security requirements the system specification must adhere to. When we have established that a system specification adheres to the security requirements at a given level, this relationship should also hold at the next level so that the invested effort to establish adherence is not wasted. Hence, we would like adherence to be preserved under transformation. Adding details to a specification may of course require some additional analysis. However, it should not be necessary to recheck the adherence relationship already established at the more abstract level.

The MDS framework is illustrated in Figure.1. Here a platform independent model together with its security requirements are transformed into several platform specific models with associated security requirements.

Figure 1.

Model-driven security (pictured)

Already published approaches to MDS include (Basin et al., 2003, 2006; Breu et al., 2005; Burt et al., 2003; Fernández-Medina and Piattini, 2004; Heldal and Hultin, 2003; Lodderstedt et al., 2002; Vela et al., 2006). Although interesting, they are in most cases of a rather informal nature; the semantics of the languages used (at abstract or/and concrete levels) are not sufficiently precise to allow for rigorous reasoning at more than one level of abstraction. Moreover, some of the approaches ((Basin et al., 2003, 2006; Burt et al., 2003; Lodderstedt et al., 2002)) consider transformation of security requirements only, and not transformation of system specifications. These approaches allow adherence checking only at the lowest level of abstraction. Others ((Breu et al., 2005; Burt et al., 2003; Fernández-Medina and Piattini, 2004; Vela et al., 2006)) do not clearly characterize what it means for a system to adhere to a security requirement. Instead, security is described in terms of a security mechanism.

Security is often defined as the preservation of confidentiality, integrity, and availability. In this chapter, we, however, focus on security in the more narrow sense of secure information flow properties (see e.g., (Bossi et al., 2004; Goguen and Meseguer, 1982; Mantel, 2000; McCullough, 1987; O’Halloran, 1990; Roscoe, 1995; Sutherland, 1986; Zakinthinos and Lee, 1997)) which provide an elegant way of specifying confidentiality as well as integrity requirements (Mantel, 2001).