Do secure information system design methods ...

Available online at www.sciencedirect.com

Information and Software Technology 50 (2008) 1035–1053 www.elsevier.com/locate/infsof

Do secure information system design methods provide adequate modeling support? Mikko Siponen *, Juhani Heikka University of Oulu, Department of Information Processing Science, Linnanmaa, P.O. Box 3000, FIN-90014 Oulun yliopisto, Oulu, Finland Received 16 February 2004; received in revised form 10 October 2007; accepted 16 October 2007 Available online 25 October 2007

Abstract Information system development (ISD) methods lack security features. To address this problem, various secure information system (SIS) design methods have been proposed. An important feature of these methods is modeling support, which manifests itself through modeling notations. This paper explores the extent to which the alternative SIS design methods offer modeling support. The results suggest that extant SIS design methods provide only limited modeling support. No single SIS design method offers comprehensive modeling support. This result has implications for practice and research. Practitioners may need to combine different SIS design methods for the development of secure information systems (IS). In turn, scholars and SIS design method developers should ensure that future SIS design methods offer comprehensive modeling support. Finally, empirical studies should be conducted to explore the usability of the current conceptual models of secure systems design methods in practice.  2007 Elsevier B.V. All rights reserved. Keywords: Information systems security methods; Information Systems Security; Development of Secure Systems; Security Modeling

1. Introduction The increasing use of computers and the Internet has made security a key concern for more and more organizations. Not only do security breaches cause losses to organizations (e.g., by preventing organizations from trading), but breaches such as the violation of privacy (e.g., the theft of credit card or health information) can also have a huge impact on ordinary computer users’ well-being. Therefore, it is important that ISs are properly secured from the outset against different information security threats, such as unauthorized disclosure or modification of information [4,42]. Commentators have noted that IS and software development methods (e.g., Structured Systems Analysis and Design, XP, Scrum) or modeling languages (e.g. OMT, UML), lack adequate security features [5,8,36,54,60]. To *

Corresponding author. E-mail addresses: mikko.siponen@oulu.fi (M. Siponen), juhani.heikka@oulu.fi (J. Heikka). 0950-5849/$ - see front matter  2007 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2007.10.011

overcome this problem, several SIS design methods, from checklists to object-oriented methods, have been proposed. Like IS and software development methods [28,68, p. 79,61], SIS design methods are ultimately tools for developers. A key feature of such tools is modeling support. This means that IS or SIS methods should provide adequate modeling support, through modeling language or notations, so that developers can model requirements. Objectoriented notations, such as UML [17], OMT and OMT++ [34], are examples of such modeling notations in the area of IS and software development. These notations and conceptual models are found to be useful in understanding the IS or software under a construction. They function as a communication language between various stakeholders such as analyzers, designers, programmers and testers. In addition, modeling languages mediate the system requirements between the developers and the customers (e.g., managers and ordinary users who will use the system, and the system analyzers, who collect the requirements) in an ISD project [71, p. 363].

1036

M. Siponen, J. Heikka / Information and Software Technology 50 (2008) 1035–1053

Although the importance of conceptual modeling was realized as early as the 1960s in IS development and software engineering circles [71], modeling support has gained little attention in the area of SIS design methods. Consequently, little is known about the minimum extent to which any SIS design method should offer modeling support (problem 1); or about the extent to which the various SIS design methods meet this ‘‘minimum requirement’’ (problem 2). The aim of this paper is to contribute towards addressing these two problems. This is achieved first by deriving a meta-model from the IS literature (an attempt to solve problem 1), and then by reviewing the modeling support of the alternative secure information system design methods, in terms of this model (an attempt to solve problem 2). Any effort to solve these two problems is not only a contribution to SIS design research, but is also valuable for IS educators and practitioners. For SIS design researchers and methods developers, addressing both of these problems is important. Only after we have an idea as to the minimum modeling support that any SIS design method should cover, and an understanding of the coverage of the modeling notation of the extant SIS design methods and their limits, are we in a position to improve secure information system design methods. In fact, through addressing problem 2, this study points to these areas where such improvements are most urgently needed. For IS practitioners, it is important to understand the coverage of the modeling notation of the extant SIS design methods. Finally, like review articles in general, this article has an educational value. In university education, it is important that students are aware of different secure information system design methods. Through addressing problem 2, this article offers such information regarding the modeling support of different SIS design methods. The composition of the paper is as follows. In Section 2, the framework of the analysis is drawn from the IS literature in an attempt to present a solution to problem 1. In Section 3, the different secure information system design methods are scrutinized from the viewpoint of this framework. This addresses problem 2. Section 4 discusses the implications raised by the findings of this study. Section 5 summarizes the key findings. 2. Related work and the framework for analysis 2.1. Related work and the research strategy Earlier review studies on secure information system design methods [3,4,12,55,56,65] have analyzed the philosophical underpinnings of SIS design methods. Baskerville [3,4] and Siponen [55,56] present a generational categorization of different SIS design methods, while Dhillon and Backhouse [12] analyze SIS design methods using Burrel and Morgan’s [9] concept of the four paradigms of sociology. In turn, Villarroel et al. [65] derived a framework from the literature and analyzed eight SIS design methods.

While these seminal studies have deepened our understanding of extant secure information system design methods and their limits, they do not evaluate the modeling support of extant secure information system design methods; hence, they do not focus on the two problems pointed out in the introduction. A key concern in a review study is to ensure that all the relevant works are covered without being confining to methods originating in a certain geographical region, and also to make sure that the review study does not concentrate on premier journals only, ignoring articles presented in conferences [72, pp. XV–XVI]. Fortunately, earlier review studies have followed this idea and have distinguished five paradigms of secure information system design methods [55,57]: information modeling methods [15,19,47,51], responsibility methods [2,11,13,42,43,54,63], security-modified ISD methods [3,8,24,35,36,66,67], business process methods [19,20,52,53] and viable system methods [37,26]. We took these secure information system design paradigms, and the methods within these paradigms, as the target of the analysis. These are briefly discussed next. 2.2. Five paradigms of secure information system design methods The security-modified ISD paradigm includes SIS design methods that are influenced by IS or software development methods. These methods include the logical control method [3], the spiral model for secure information system design [8], virtual methodology [24,25], the soft method for the planning of secure information systems [35], meta-notation [58], secure information system planning methodology [62] and UMLsec [36], security design patterns [6] and integrated security and systems engineering approach by Mouratidis et al. [44,45]. The logical control method [3] focuses on logical design and processes in particular to add the necessary controls into them. The cross-references of these controls are added into a data dictionary, which lists threat classes and respective controls. The spiral model for secure information system design [8] uses Boehm’s [7] spiral model to integrate secure information system design activities into the IS and software development process. This goal is achieved by following the secure information system design spiral, paralleling that of Boehm. Virtual methodology [24,25] adopts a soft view, influenced by the soft systems methodology [10], emphasizing organizational, cultural and human issues in secure information system design and development. The soft method for the planning of secure ISs [35] is also based on the soft system methodology. This method stresses the role of user participation in secure information system design and development to (1) utilize the user’s knowledge of the activities of the organization and (2) to increase users’ awareness and commitment to the designed IS security solutions.

M. Siponen, J. Heikka / Information and Software Technology 50 (2008) 1035–1053

Meta-notation [58,60], like the logical control method [3] and the secure information system design spiral [8], aims to integrate secure information system design into IS and software development methods. Siponen and Baskerville [58] provide six security elements, which, they argue, can be integrated into IS and software development methods. Secure information system planning methodology [62] consists of three elements: a security risk planning model, an awareness program and a countermeasure matrix. The five stages of the secure information system planning model – (1) recognition of security problems, (2) risk analysis, (3) generation of alternatives, (4) decisions and (5) implementation – constitute the overall process to be followed [62, pp. 450–454]. The awareness program and countermeasure matrix are integrated into these stages. UMLsec by Ju¨rjens [36] provides new security elements, such as {tags} and , to UML. Villarroel et al. [66,67] and Ferna´ndez-Medina et al. [16] based their UML security extensions on the same idea of use stereotypes, tags and constraints. By using these elements, the systems security goals and features can be emphasized during the modeling and designing of the system. UMLsec and the methods presented by Villarroel et al. [66,67] and Ferna´ndez-Medina et al. [16] can be integrated to ISD approaches that apply use cases or UML notation. Blakley et al. [6] adopted the idea of design patterns in the context of security by developing 13 security design patterns. Modeling of the patterns is carried out by using textual examples and UML specifications that can be integrated to those ISD methods that use UML notation. The integrated security and systems engineering approach by Mouratidis et al. [44,45] provide security extensions to the Tropos method. By using these elements, the method aims at modeling the IS security features. The method only integrates into approaches utilizing Tropos methods and its modeling concepts. The responsibility modeling paradigm includes secure information system design methods, representing the view that IS security requirements can be found by scrutinizing the job responsibilities in organizations. The methods within this paradigm include a method by Strens and Dobson [63], the semantic responsibility analysis method suggested by Backhouse and Dhillon [2], the abuse case method suggested by McDermott and Fox [42], McDermott [43] and Sindre and Opdahl [54], the task-based authorization method suggested by Thomas and Sandhu [64] and MAPS, as proposed by Pottas and Solms [50]. Strens and Dobson [63] state that the context in which IS security requirements arise is poorly understood, and that recognition of work responsibilities is the way to solve this problem. According to Strens and Dobson [63, p. 146], IS security requirements, such as need-to-do and need-toknow, can be drawn from the job responsibilities. The semantic responsibility analysis method [2] also holds that IS security requirements can be inferred from job responsibilities. By analyzing responsibilities in organizations, Backhouse and Dhillon [2] attempt to identify the

1037

relevant agents and the patterns of behavior and communication that subsist between these agents [2, p. 5]. An agent is any party that can have a responsibility, including humans, organizations and groups. The abuse [42,43] or misuse [54] case methods are derived from use cases (used in ISD methods to capture system requirements). In the same way that use cases model authorized use scenarios (e.g., a clerk querying a database), abuse cases describe unauthorized scenarios (such as a hacker breaking into the database) against which the data in the system should be protected. The Model for Automated Profile Specification (MAPS) [50] aims to model security profiles and to employ these in access control. Like other secure information system design methods within the responsibility paradigm, MAPS [50, p. 477] considers an exploration of users’ job descriptions and organizational policies to be helpful in creating security profiles and, furthermore, in ensuring that the security requirements are enforced. The task-based authorization method [64] stems from the limitations of extant computer security access control models which represent a centralized notion of computing – an inadequate view from an overall organizational viewpoint. To address this problem, they propose that a better authorization model can be achieved by analyzing the responsibility and authorization structures in an organization. The business process paradigm consists of a secure information system design method suggested by Herrmann and Pernul [19], and the fair and secure electronic markets method proposed by Ro¨hm and Pernul [53]. Common to these methods is an attempt to construct a modeling notation for describing security constraints in business process models. Herrmann and Pernul [20] suggest a high-level modeling notation for describing the security requirements (mainly confidentiality and integrity requirements) for business processes. The fair and secure electronic markets method [52,53] presents an overall infrastructure for ensuring the security and fairness of market transactions. The information modeling paradigm encompasses methods motivated by the desire to build security notations, particularly for developing secure databases, with the aim of extending the existing research on database security. Methods within the information modeling paradigm include the security constraints modeling [47], object-oriented security semantics [15], data and security semantics [48], the data flow diagrams (DFD) and entity-relationship (ER) modeling [49] and secure data warehouse design [51] methods. The viable and survivable IS paradigm consists of the survivable IS method put forward by Karyda et al. [37] and the viable system model suggested by Hutchinson and Warren [26]. While the viable system model [26] investigates security attacks, the survivable IS method [37] offers a complete secure information system design method. Another difference between these methods is that the survivable IS method [37] acknowledges the recently proposed

1038

M. Siponen, J. Heikka / Information and Software Technology 50 (2008) 1035–1053

research agenda on survivable systems [14,40], and the thesis of survivability (we must build systems that can cope with future as well as present events), while the viable system model [26] does not stress this idea of survivability. 2.3. The framework for analysis To explore the extent to which various secure information system design methods offer modeling support (problem 2 in the introduction), the first task is to clarify what modeling support secure information system design methods should cover (problem 1). To avoid reinventing the wheel when solving problem 1, we explored possible solutions in the IS literature. Dhillon and Backhouse [12], Hirschheim and Klein [21], Hirschheim et al. [22,23] and Iivari et al. [33] have analyzed existing methods in the light of Burrell and Morgan [9], Iivari and Kerola [27] have carried out a feature analysis, Iivari [28,30] has scrutinized ISD methods from the viewpoint of a metamodel for IS, Wand and Weber [68–70] have performed an ontological analysis of the key entities, while Iivari [29], Iivari and Hirschheim [31], and Iivari et al. [32] have analyzed ISD methods in the light of research methods, the organizational role of IS, schools of IS, and research objectives. Of these possible frameworks, we selected (1) the metamodel for IS [28] and (2) key entities for secure IS development. The metamodel for IS [28] helps us to compare how comprehensive the modeling support provided by the various secure information system design methods is. According to this metamodel, an IS is divided into three levels [28,41,31,23]: (1) the organizational level, which defines the organizational role and context of the IS, (2) the conceptual level, which defines an implementation-independent specification for the IS, and (3) the technical level, which defines the technical implementation of the IS. The levels are arranged in order of abstraction. Since the meta-

Structure Abstraction

C O N C E P T U A L

model is based on the commonly agreed levels of IS, it shows which aspects of IS are covered by different methods. Since SIS design methods are aimed at making IS secure, we see that SIS design methods should provide modeling support at all levels of IS. The aim of IS analysis is to model perceived reality (e.g., [22,68–70]. Hence, the question of what entities exist and are seen as relevant for secure IS development is crucial for an evaluation of the relevance and scope of different secure information system design methods. 3. Analysis of modeling support 3.1. Security-modified ISD methods 3.1.1. Logical control method In this method, processes are scrutinized at a conceptual level in order to build the necessary security controls into them (Fig. 1). Thus, security controls are forms of processes. The cross-references are added into a Data Dictionary, which lists threat classes and their respective controls (Fig. 1A). The logical control method consists of five phases: (1) identify entities; (2) identify risks; (3) identify controls; (4) evaluate; and (5) implement [3]. The first phase is accomplished through following the process of Structured Analysis. The second and third stages are not found in structural IS development methods, and should thus be added into those methods [3, p. 93]. There are three classes of logical risks: destruction, modification and disclosure [3, p. 94]. The processes are examined (functional abstraction) in Fig. 1C. The relevant processes are then described in terms of a transform description (Fig. 1B). In Fig. 1B, Process 1 is described as a transform description (organizational abstraction). The control processes for destruction, modification and

Functional Abstraction

1A Data Dictionary

Behavioral Abstraction

1C

Data flow diagram Data flow (arrow) Process (circle) Internal/External Data Source

Data Flow Name: Process 1 Composition:

SORTED TIMECARDS

Modification control: Process X Disclosure control: Process Y Destruction control: Processes Z Aliases: none - Created by Process V

1B Transform description VERIFIED TIMECARDS

Description of Process 1

PAYCHECKS

2.1 Sort TIMECARDS 2.3 Review reports

2.2 Print PAYCHECKS

1D

Print paychecks PAYROLL MASTER FILE

Read input files

Compute regular pay

PAYROLLEXECPTION REPORT PAYROLL-RUNFILE

Fig. 1. Baskerville’s [3] logical control method.

Disclosure control: process X Modification control: process Y Destruction control: process Z

M. Siponen, J. Heikka / Information and Software Technology 50 (2008) 1035–1053

disclosure, which are part of the transform description diagram (cf., Fig. 1B), come under behavioral abstraction (Fig. 1D). The logical control method does not explicitly support the use of security levels in which subjects, i.e., users and objects, are categorized into security levels according to their sensitivity. The logical control method recognizes the entities, from humans to software and processes, as the entities for secure IS development. 3.1.2. Virtual methodology Virtual methodology contains three different models: the organizational (Fig. 2A), IS (Fig. 2B) and risk (Fig. 2C) models. All the modeling is at the organizational level. In Fig. 2A, phase one – ‘‘analysis of the organization’’ – the organization model is described. In the virtual methodology notation, relations that should not have occurred (unauthorized relations) are illustrated by thick lines (e.g., the relation between hackers and the organization in Fig. 2). Authorized relationships (those that should occur) between the components of the organization and environmental factors (e.g., legislation) are described using thin lines. Broken lines are used to describe relations that should occur only in special circumstances (e.g., in Fig. 2B, the relation between user group C and the IS). The arrow indicates the direction of flow. The virtual methodology does not provide any guidance on how to find out what the components of the organizational or environmental factors are. The models should

1039

be reviewed and agreed upon by the different interest groups, such as users and managers. The IS model is depicted in the following Fig. 2B. The components of the systems and the components that interact with the systems are described in the IS model. According to Fig. 2A, only personnel involved with the systems (IS users) interact directly with those systems. Therefore, only ‘‘IS users’’ (user groups A, B and C) should be visible in Fig. 2B. According to the virtual methodology, users can be divided into user groups (this is not clearly stated, but can be inferred from the example of the virtual methodology given in Hitchings [25, p. 378]. This is done in Fig. 2B (user groups A, B, C). In Fig. 2C, the different types of access to the systems are depicted. These two models are combined to produce the virtual methodology risk model (phase three). The risk model is structured using the same notation as the organization and IS models. The risk model differs from what is shown in Figs. 2A and B in the sense that only possible sources of risk are described. In phase four, the risk areas are identified using the model. For example, according to the virtual methodology, ‘‘unauthorized users’’ is a potential risk area. By identifying the risk areas, the necessary security controls can be determined and implemented. The first four phases, which are modeling supported, are at the organizational level. The virtual methodology recognizes humans (users, competitors, clients) as the relevant entities in relation to software and processes.

Structure Abstraction and Functional Abstraction O R G A N I Z A T I O N A L

Design context

O R G A N I Z A T I O N A L

Design context

Competitors

Clients

Other people Legislation Hackers Social engineering Applicati on concept

ORGANIZATION

Other employees

Other systems

SYSTEM

2A Personnel involved with the systems (IS users)

Structure Abstraction

Behavioral Abstraction

2B

2C User type 1

ORGANIZATION Applicati on concept

Read access, i.e., user can request system outputs

SYSTEM User group A

User group B

User group C

User type 2 Read and write access under certain controlled situations

SYSTEM

Fig. 2. (A) Hitchings’ [24] virtual methodology: organization model. (B) Virtual methodology: the IS model. (C) Access to the system.

1040

M. Siponen, J. Heikka / Information and Software Technology 50 (2008) 1035–1053

3.1.4. The soft method for the planning and management of secure IS The soft method for the planning of secure IS [35] offers modeling support at the organizational level through rich pictures. Security-relevant entities are typical of ISD methods stressing social-organizational dimensions; the method does not mention computer-oriented low-level entities, as opposed to the spiral model for secure information system design and the methods under the information modeling paradigm.

3.1.3. The spiral model for secure information system design The secure information system design spiral is divided into four quadrants [8, p. 259]: (1) determine objectives, alternatives and constraints; (2) evaluate alternatives; identify and resolve risks; (3) develop and verify the next-level product; and (4) plan the next phases. The spiral model for secure information system design incorporates the use of security levels. In Fig. 3, P refers to processes (1, 2, . . . , N) and the letters TS, S, and C stand for security levels (Top Secret, Secret, and Confidential, respectively). Fig. 3B illustrates the ‘‘compound information flow’’ which is carried out in the 9th phase, called ‘‘information flow analysis’’. Regarding information flow analysis, the spiral model prefers the ‘‘Take-Grant’’ mode for determining the flow type of compound objects. The compound flow denotes indirect flows that occur through certain intermediate objects. In Fig. 3, such a flow may proceed from Object 1 to Object 2 via Process I (intermediate object). In the upper part (A), the information flow analysis is used to check that the security levels (e.g., TS, S, C) are correct and that the chosen policy is not violated. The spiral model for secure information system design [8] uses the Bell–LaPadula (BLP) policy as an example (other policies are possible as well). For example, according to BLP, an action (Fig. 3A) between Process X (at the Top Secret level) and Object B (at the Secret level) would be unacceptable since BLP prohibits writing to lower levels – in other words, information flow from high level security objects to low security level objects is prohibited. The spiral model for secure information system design requires all users with different clearances to be expressed by different unique objects; namely, the models within this method require that each object has a single clearance. According to the spiral model, the relevant entities are processes, data stores and flows [8, p. 261]) and humans [8, p. 266]).

3.1.5. Meta-notation Meta-notation proposes six optional security dimensions: security subjects, security objects, security classifications, security constraints, abuse scenarios and security policy [58,59]. Siponen and Baskerville [58] and Siponen et al. [60] show how meta-notation can be applied to UML-notations, in particular use cases [58], and to an agile software development method, called Feature Driven Development [60]. Fig. 4A describes how these security dimensions can be added to textual use cases and abuse cases [60]. These security-enriched use cases are at the organizational level. In Fig. 4C, the security sensitivity of classes is added to the class diagrams of feature-driven development. In Fig. 4C, the user (a security subject) and the document (a security object) both have a clearance of confidential. This is at the conceptual level. Siponen et al. [60] also show that these security dimensions of security subjects and objects can be presented as attributes within classes (this is at the technical level). The relevant entities of meta-notation range from human actors to computer-oriented processes. 3.1.6. The secure information system planning methodology The secure IS planning methodology [62] consists of four stages: (1) recognition of security problems, (2) risk

Functional Abstraction and Behavioral Abstraction

C Universe O of Discourse N C E P T U A L

3A

P1 (TS)

Object A Read

Process X Write P2 (S) Object B

Process Y

(S)

3B Object 1 Read

Process I

Object 2 Read

Data Flow Diagram Data flow (arrow) Process (circle) Data file (here, Object B) External entity (e.g., user; here, Object A)

Fig. 3. Booysen and Eloff’s [8] spiral model for secure information system design.

M. Siponen, J. Heikka / Information and Software Technology 50 (2008) 1035–1053

1041

Functional Abstraction and Behavioral Abstraction

O R G A N I Z A T I O N A L

C O N C E P T U A L

Abuse case: Hacker Version: 1.0 Possible abuse scenario: A hacker breaks in to the system and gains access to the customer file. Frequency: several times a day 4A Abuse subject: a hacker Security objects/target of abuse: customer file Total costs of recovering: N USD Countermeasures: firewalls (only certain IP-addresses are allowed), encryption of passwords (at least 128-bit encryption), limit of login attempts per login name (three maximum attempts). Number of the version/iteration where this abuse case is prevented: version 1.0 Priority 1-10: 10 - must be avoided!

Primary actor/security subject: User Version: 1.0 4B Main success scenario: User access document X Security classification: confidential Security objects: document X Priority 1-10: 5

Document

Access

User - Confidential

- Confidential

4C Asecurity object (document)

Security classification

Asecurity subject (user)

Fig. 4. The Meta-notation [58,60].

analysis, (3) generation of alternatives, (4) decisions and implementation. In terms of the metamodel, the method is at the organizational level. Countermeasures matrixes and IS security awareness programs are all within the organizational context. However, this method does not include modeling techniques in the sense of IS and software development methods, which would be at the conceptual and technical levels. 3.1.7. UMLsec and UML security extensions UMLsec [36] and the approaches suggested by Villarroel et al. [66,67] and Ferna´ndez-Medina [16] are based on UML, providing security extensions (e.g., and {tags}) to UML diagrams. The extensions are used to highlight security requirements during the designing of IS. These approaches suggest the use of use cases at the organizational level. The security requirements are modeled with use cases and the security requirements are expressed through stereotypes, for example in Fig. 5 (Functional abstraction). The stereotype expresses that in the development of a system it is important to pay attention to the system features related to secure shopping through the system. In this case, can be interpreted as meaning that the customer can feel sure that his/her personal information (e.g., credit card information, address) is handled so that it respects customer privacy. It also means that the customer gets the product on time and the seller receives the

money. In other words, this stereotype represents a security requirement that all transactions in the system must be performed in a way that prevents both parties from cheating [36, p. 53]. In this phase, it is not decided how the will be implemented and security requirements relating to this are refined in later phases of the design process. At the conceptual level (structural abstraction), the security requirements are modeled with UML diagrams applying and {tags}, for example , , {secrecy} and {integrity}. At this phase of designing, the stereotypes are refined to more concrete system features, for example in this case has been refined into encryption of network traffic between the stakeholders. By applying encryption, the system provides a feature. To refine the design and forming a technical implementation of , a class diagram with the needed and {tags} is formed at a technical level. In Fig. 5, expresses the critical security classification of classes (in encryption of traffic – this means that the key generator must be functioning flawlessly and the encryption key must be kept secret). The tag {secrecy} means that the piece of data, for example ‘‘attribute d’’ in Fig. 5, is kept secret, and the system never sends out any information from which the data could be derived by an outsider [36, p. 41]. In terms of the metamodel, the approaches by Ju¨rjens [36], Villarroel et al. [66,67] and Ferna´ndez-Medina [16] are at the organizational, conceptual and technical level.

M. Siponen, J. Heikka / Information and Software Technology 50 (2008) 1035–1053

OR GA NI ZA TI ON AL

Functional abstraction eStore Application

< < fair exhange