ࡱ > '` % bjbj q( d , C l ! $ 0! R R R P HS \U 0! v U : 6V " XV XV XV W " \ | C^ $ h | E ( n W " W n n " XV XV + > n XV XV n 6 XV U vN R b ٢ . H v 8 š _ d g qj 5 _ _ _ v _ _ _ v n n n n 0! 0! 0! ( I 0! 0! 0! I 0! 0! 0! 10
Secure Tropos: Extending i* and Tropos to Model Security Throughout the Development Process
Haralambos Mouratidis and Paolo Giorgini
10.1 Introduction
Developers face many challenges in the development of modern information systems. These challenges are mainly associated with characteristics that modern information systems need to demonstrate, such as openness, variety, adaptability, interoperability, and security. Although many new techniques and technologies are being developed on a regular basis, to enable developers to deal with most of these challenges, security engineering has not yet received the attention it deserves.
Security engineering of information systems is mainly concerned mainly with methods providing cost-effective and operationally effective protection of information systems from undesirable events (Lane, 1985). Usually the goal when developing an information system is to provide as much security as possible, sometimes trading security requirements off against other functional and nonfunctional requirements. To help developers to perform such trade-offs and develop, as much as possible, secure information systems, methods, techniques, and tools are needed. Thus, it has been extensively argued (Devanbu & Stubblebine, 2000; McDermott & Fox, 1999; Tryfonas, Kiountouzis, & Poulymenakou, 2001) in the literature, especially during the last few years, that it is necessarythe necessity to integrate security issues into software engineering and introduce methods and languages that will consider security as an integral part of the whole information systems development process.
However, up to now, the literature has failedfails to provide evidence of such methods and languages. In other words, we lack a complete methodology thatwhich will provide methods and processes to guide developers when considering security during the development of information systems. This gap provides the motivation of our work.
To be considered complete, such a methodology should provide methods to assist in capturing security requirements early in the development process, as well asand also support the development of a design that satisfies these requirements. Moreover, it should provide methods and techniques to assist developers in validating the design of the system against its security requirements. Additionally, it should be based on an ontology that will allow an analysis not only of technical issues related to security but also of the social issues related to security.
However, the development and the definition of such a methodology is a demanding and difficult task (Chung & Nixon, 1995; McDermott & Fox, 1999; Mouratidis, Giorgini, Schumacher, & Manson, 2003). This is because, among other reasons, it is difficult to define together security and functional components together and at the same time provide a clear distinction between the two. For instance, which components are parts of the security architecture and which ones are parts of the functional specification? Moreover, due to the nature of security, it is difficult to get empirical evidence of security issues during the design stages. This makes the process of analyzing security during the design stage more difficult. To make things worse, developers, who are not security specialists, usually need to develop information systems that require knowledge of security.
i* and Tropos do not include concepts and processes to adequately support analysis and design of the security properties of an information system. This chapter discusses some of the limitations of i*/Tropos with respect to security analysis and modeling and presents the Secure Tropos methodology, which aims to extend the concepts and the processes of i*/Tropos to allow adequate modeling of security throughoutduring the whole the development process of an information system. Secure Tropos introduces new concepts, such as security constraint, and it extends existing concepts with security in mind, such as secure goal and secure plan. Moreover, methods such as the security reference diagram and the security attack scenarios, and a security pattern language have been integrated into the Secure Tropos development process to assist developers in eliciting and analyzing security requirements and developing a design that satisfies those requirements.
In this chapter we summarize the research results obtained during the last several years in the Secure Tropos project. In particular, section 10.2 provides an overview of i*/Tropos concepts and modeling activities as well as a discussion of the shortcomings of i*/Tropos with respect to security modeling. Moreover, it provides an introduction to the concepts and modeling activities of the Secure Tropos methodology. Section 10.3 illustrates the applicability of Secure Tropos with the aid of a case study from the health-care sector, and section 10.4 introduces the security reference diagram. Security attack scenarios are introduced in section 10.5, and a secure pattern language is described in section 10.6. We present related work in section 10.7, and conclude the paper and provide some directions for future work in section 10.8.
10.2 Secure Tropos
Secure Tropos extends the Tropos methodology in two ways. First, by extending the i*/Tropos concepts and second by extending the Tropos development process. These extensions aim to introduce a security-enhanced ontology and a structured and well-defined process that will enable the modeling of security issues as part of the Tropos development process. The following three subsections provide a very brief overview of the i*/Tropos concepts and processes, and discuss the limitations of these concepts and processes with regard to security modeling.
10.2.1 i* and Tropos Concepts and Notations and Tropos Process
Tropos is a development methodology based on the i* modeling framework (chapter 2; Yu, 1995). Models in Tropos are acquired as instances of a conceptual metamodel resting on basic concepts and relationships, shown graphically in figure 10.1, which derive from i* (Bresciani, Giorgini, Giunchiglia, Mylopoulos, & Perini, 2004; chapter 11 of this book). (See section 17.2 for a comparison of constructs used in i*, Tropos, and some of their variants.)
[Figure 10.1 here]
An actor models an entity (agent, position, or role) that has strategic goals and intentionality within the system or the organizational setting. Hard goals and softgoals represents actors strategic interests. The concept of a hard goal (simply called goal hereafter) is differentiated from the concept of softgoal. A softgoal is used to capture nonfunctional requirements of the system, and unlike a (hard) goal, it does not have clear criteria for deciding whether it is satisfied or not and therefore is subject to interpretation. A task represents, at an abstract level, a way of doing something. Task is an i* concept that is replaced in Tropos by the concept of plan. The execution of a plan can be a means for satisfying a goal or for contributing toward the partial satisfaction of a softgoal. A resource represents a physical or an informational entity; and a dependency between two actors indicates that one actor depends, for some reason, on another in order to attain some goal or softgoal, execute some plan, or deliver a resource. The depending actor is called the depender and the actor who is depended upon is called the dependee. The type of the dependency describes the nature of an agreement (called dependum) between dependee and depender. A concept introduced in Tropos that is not part of i* is that of capability. A capability represents the ability of an actor to define, choose, and execute a plan for the fulfillment of a goal, given certain world conditions and in the presence of a specific event.
To assist developers in the development of information systems, Tropos covers four main software development phases:
Early requirements, concerned with the understanding of a problem by studying an existing organizational setting. The output of this phase is an organizational model that which includes relevant actors, their respective dependencies, and the security constraints imposed on those actors.
Late requirements, in whichwhere the system-to-be is described within its operational environment along with relevant functions; this description models the system as a (small) number of actors whowhich have a number of dependencies. These dependencies define the systems functional requirements.
Architectural design, in whichwhere the systems global architecture is defined in terms of subsystems interconnected through data and control flows. Within the framework, subsystems are represented as actors, and data/control interconnections are represented as (system) actor dependencies.
Detailed design, in whichwhere each architectural component is defined in further detail in terms of inputs, outputs, and control. For this stage Tropos uses elements of Agent UML (Bauer, Mller, & Odell, 2001) to complement the features of i*.
To complement the above development stages, the original Tropos methodology proposes actor modeling, which consists of identifying and analyzing both the actors of the environment and the systems actors and agents; and dependency modeling, which consists of identifying actors that depend on one another for goals to be achieved, plans to be executed, and resources to be furnished. A graphical representation of a model obtained following these modeling activities is given through actor diagrams, which describe the actors (depicted as circles), their goals (depicted as ovals), their softgoals (depicted as spongelike shapes) (see figure 10.1) and the network of dependency relationships among actors (two arrowed lines connected by a graphical symbol that variesvarying according to the dependum: a goal, softgoal, plan, or resource).
Moreover, Tropos supports goal and plan modeling that rests on the analysis of an actors goals, conducted from the point of view of the actor by using three basic reasoning techniques: means-end analysis, contribution analysis, and AND/OR decomposition. A graphical representation of goal and plan modeling is given through goal diagrams, which appear as a balloon within which goals of a specific actor are analyzed and dependencies with other actors are established. Goals are decomposed into subgoals and positive/negative contributions of subgoals to goals are specified. Goal decomposition can be closed through a means-end analysis aimed at identifying plans, resources, and softgoals that provide means for achieving the goal.
10.2.2 Shortcomings of Tropos for Security Modeling
Our research (Mouratidis, Giorgini, & Manson, 2003a) has identified two main categories of limitations that Tropos demonstrates with respect to security modeling: (a) limitations on the concepts of the methodology and (b) limitations on the process of the methodology.
10.2.2.1 Limitations on the Concepts
Tropos concepts partially tackle security modeling by allowing developers to capture security requirements, as well as any other nonfunctional requirements, as softgoals. The concept of softgoal is used to model quality attributes for which there are no a priori, clear criteria for satisfaction, but are judged by actors as being sufficiently met (Yu & Liu, 2001, p. 175). However, security requirements relate to system quality attributes, or alternatively may define constraints on the system. Qualities are properties or characteristics of the system that its stakeholders care about, whereas constraints are restrictions, rules, or conditions imposed on the system and, unlike qualities, are (theoretically) nonnegotiable. Therefore, although the concept of a softgoal captures qualities, it fails to adequately capture constraints. However, possible constraints might be imposed on the system representing restrictions (global or for each individual agent). For example, security constraints might be imposed on the system representing restrictions related to its security. Such constraints might affect the analysis and design of the system by restricting some alternative design solutions, by conflicting with some of the requirements of the system, and by refining some of the goals of the system or introducing new ones that help the system to satisfy towards the satisfaction of its requirements.
To further illustrate the lack of adequate security modeling using only the original i*/Tropos concepts, consider the actor diagram presented in figure 10.2.
[Figure 10.2 here]
We observe that Although the dependencies between the actors are clearly shown, some possible security-related constraints that might be imposed on some of the actors are not present. For example, the Older Person depends on the Benefits Agency to Receive Financial Support, but the Older Person most likely introduces a security-related constraint on the Benefits Agency to keep his or hertheir financial information private. On the other hand, the R&D Agency actor depends on the Professional actor to Obtain Clinical Information, but the Professional might be restricted (for example, by the Department of Health or the Older Person) to providingprovide only anonymous clinical information. In addition, the Older Person might restrict the Professional by imposing a constraint to share medical information only if the older persons consent is obtained. Therefore, the above-mentioned actors have to achieve their goals while having to satisfy different security constraints imposed on them.
However, the original Tropos methodology fails to adequately model such constraints, and therefore the modeling of security issues during the development of a multiagent system is restricted. A limited way of modeling the above scenario using the original Tropos concepts is to use the concept of goal to directly model security-related goals of the actors. For instance, in the above example, a goal such as Obtain Older Person Consent could be introduced for the Professional actor without analyzing any constraints that could be imposed upon this actor. This approach would assist to some extent with the analysis and modeling of security considerations, but it has some important disadvantages. First of all, it would represent the obtaining of consent from the older person as an ad hoc process, which would make it difficult to track possible security solutions to appropriate security requirements (i.e., track the hows back to the whys e.g., why the goals were assigned in the first place and why to that actor). Second, it would make it extremely hard to distinguish between security and other system requirements.
Similarly, someone might argue that security-related constraints could be captured as goals. However, the concept of constraint is different from the concept of goal. A goal represents a desired state of the world, whereaswhile a constraint represents a condition, rule, or restriction toward the achievement of a goal. Although a goal can be achieved in various ways, a constraint defines a set of restrictions on how the goal will be achieved. For example, the Benefits Agency could have a goal to keep financial information private, buthowever this is not a goal of the Benefits Agency, whosethe goal is to provide financial support; but rather, it is a restriction imposed on achieving the goal. Therefore, using the current i* andTropos concepts will result in a restricted model. We believe that the ontology of the i*/Tropos methodology should be extended to include the concept of constraint (and also that the concept should be defined with security in mind). With respect to security, by analyzing the constraints that actors might impose on each other, developers are able to identify security goals that can be used later in the development process and that help identify security requirements of the system.
In addition, the usage of only softgoals to model general nonfunctional requirements, although it allows developers to define together security and other functional and nonfunctional requirements together, it does not help in providing a clear distinction between security and the other requirements of the system. Such a distinction is made even harder by the lack of security-focused definitions of the Tropos concepts, such as goals, plans, and dependencies.
10.2.2.2 Limitations on the Process
In addition to the above limitations, there are limitations regarding the process of modeling of security issues. The current process of modeling and reasoning about security issues throughout the whole range of the development stages of information systems is quite ad hoc. Developers are allowed to capture security requirements with the aid of softgoals, and then propagate them throughout the development stages. Also, the methodology allows developers to (partially) identify conflicts between security and other requirements. However, this process is neither clear nor well guided. It is unclear how developers can capture security requirements and how they can develop a design that successfully meets these requirements in a systematic way. In addition, the methodology does not provide any processFor example, the methodology does not define by the methodology how softgoals related to security and identified during the analysis process can be transformed into security goals of the system during the design phase, norand how these softgoals can be traced back to the early requirements-analysis stage.
In addition, the methodologydoes not provide any process to allow developers to reason about the consequences of the application of particular designs to their system and also fails to provide a process that allows developers to evaluate the developed security solution. How can developers know that the proposed design actually meets the security requirements? Moreover, the methodology assumes that developers demonstrate in-depth security knowledge. To express security requirements as softgoals, developers have to identify these security requirements. However, currently, the introduction of security related softgoals currently lacks a sytematic approach and depends entirely on the security knowledge of the developers. For novice developers who lack knowledge of security, this can be prove to be a very demanding and difficult task. In addition, the methodology fails to integrate security modeling into the early requirements-analysis stage. In the current process, security is only considered only as part of the late requirements stage; however, all the actors play an important role with respect to the security of the system and all of them should be analyzed with security in mind.
10.2.3 Secure Tropos Concepts and Modeling Activities
Secure Tropos proposes extensions to the ontology as well as to the development process. Ontological extensions involve the introduction of the concept of constraint and the definition of the current i*/Tropos concepts with security in mind. Toward this end, extra concepts were introduced into the methodology to enable it to model security requirements during the software development process. The new concepts are as follows (Mouratidis, 2004).
A security constraint represents, generally speaking, constraints that are related to the security of the system. A security constraint is defined "as a restriction related to security issues, such as privacy, integrity and availability, which can influence the analysis and design of the system under development by restricting some alternative design solutions, by conflicting with some of the requirements of the system, or by refining some of the systems objectives" (Mouratidis, 2004, p. 75). Secure entities represent secure goals, plans, or resources of the system. A secure goal represents the strategic interests of an actor with respect to security. Secure goals are mainly introduced mainly in order to achieve possible security constraints that are imposed on an actor or exist in the system. However, a secure goal does not define how the security constraints can be achieved, since alternatives can be considered. The precise definition of how the secure goal can be achieved is given by a secure plan. A secure plan is defined as a plan that represents a particular way for satisfying a secure goal. A secure resource can be defined as an informational entity that is related to the security of an information system. The graphical representation of the Tropos entities has been extended to enable it to model the secure entities. Secure entities are indicated by the presence of an S within brackets before the description of the entity, as shown in figure 10.3.
[Figure 10.3 here]
Secure dependencies represent a dependency between two actors that involves the introduction of a security constraint that must be satisfied either by the depender, the dependee, or both for the dependency to be valid. Secure dependencies are categorized into depender secure dependency, in which the depender introduces security constraints for the dependency and the dependee must satisfy the security constraints for the dependency to be valid; dependee secure dependency, in which the dependee introduces security constraints and the depender must satisfy them; and double secure dependency, in which both the depender and the dependee introduce security constraints for the dependency that both must satisfy for the dependency to be valid. A graphical representation of the different types of secure dependencies is shown in figure 10.4.
[Figure 10.4 here]
Secure capabilities which represent capabilities that the actors (agents) of the system must have in order to help toward the satisfaction of the security requirements of the system.
In addition to the ontological extension, we introduce extensions to the development process that aim to create a structured security-oriented approach in the development of information systems. The security-oriented process in Secure Tropos involves identifying the security requirements of the system, transforming these requirements into a design that satisfies them, and validating the system developed with respect to security. The security requirements are identified with the aid of security constraints and they are transformed with the aid of secure entities. In particular, the following activities are employed to model security issues during the development of a system.
Security constraint modeling, which consists of modeling security constraints imposed on the actors and the system, thus allowing developers to perform an analysis by introducing relationships between the security constraints or a security constraint and its context. Security-constraint modeling is divided into a number of smaller modeling activities, such as security constraint delegation (delegation of security constraints from one actor to another), security constraint assignment (assignment of a security constraint to a goal), and security constraint analysis (decomposition of security constraints and identification of secure goals).
Secure entities modeling, which consists of identifying secure plans and resources that provide means for achieving a secure goal; identifying secure goals that contribute positively or negatively to the secure goal being analyzed; and decomposing secure goals and/or plans into subgoals and/or subplans, respectively. Secure entities modeling is considered complementary to security constraints modeling and follows the same reasoning techniques, such as means-end, contribution, and decomposition analysis, that Tropos employs for goal and plan analysis.
A graphical representation of these modeling activities is given through actor and goal diagrams. Essentially, the security-related modeling activities are combined with Troposs other modeling activities. It is depends on the designer who must to decide which activity must be employed at which stage of the system development, since the main aim of these activities is not to restrict the designer to a step-by-step development of the system-to-be, but rather to provide a framework that allows the developer to go from a high-level design to a more precise and defined version of the system.
10.3 The eSAP System
To illustrate our approach, we use the electronic single assessment process (eSAP) system case study. This case study was first introduced by Mouratidis, Philp, and Manson (2003), and various parts of it have been previously presented in the literature (Mouratidis et al., 2003a, 2003b; Mouratidis et al., in press). However, in this chapterpaper we present an extended version of it that emphasizes aspects of our approach that have not been presented previously.
The eSAP case study involves the development of a health- and social-care information system for the effective care of older people in England (Mouratidis, 2004). Such a case study provides an ideal examplecase for validating a security-oriented methodology becausesince it is complex enough and because security is a very important factor in the development of the system. Security of personal health information is considered a priority by many health-care unions, in different countries of the world including those in England. Health professionals and patients are worried that usage of an electronic system introduces risks for the privacy. Therefore, the privacy of health- and social-care information, such as the health- and social-care plans used in the electronic single assessment process, is the number-one security concern when developing the system. Other important concerns are integrity and availability. Integrity assures that information is not corrupted, and availability ensures that the information is always available to authorized health- and social-care professionals. If assessment information is corrupted or is not available, the care provided to the patient by the health- and social-care professionals will not be efficient and/or accurate. Therefore, it is necessary to find ways to help toward the privacy, the integrity, and the availability of personal health- and social-care information.
10.3.1 Early-Requirements Analysis
During the early-requirements stage, the goals, dependencies, and security constraints between the stakeholders (actors) are modeled with the aid of an actors diagram (Bresciani, Giorgini, Giunchiglia, et al., 2004). Such a diagram involves different actors, represented as nodes, and dependencies, represented as links between the different actors that indicate a secure dependency of one actor to another. For the eSAP case study, we consider the following actors. Older Person: the Older Person actor represents patients aged sixty-five or above, assessed for their health- and social-care needs. Nurse: The Nurse performs the overview assessment of the older person. General Practitioner: The General Practitioner performs the contact assessment, provides referrals to the Nurse to perform an overview (or any otherdifferent kind she/he thinks is appropriate) assessment, and provides the older persons contact information. Social Worker: The Social Worker receives referrals (indicating the problems occurred) and the actions to be performed, as well asand also information about the older person such as contact information and a copy of the care plan. Secondary Care Professional: Secondary care professionals (or specialists) undertake assessment and care following referral by primary care professionals. Some secondary care professionals, such as community psychiatric nurses, work at the interface between primary and secondary care. During the single assessment process, secondary care professionals usually do specialist and comprehensive assessments. Care Assistant: The main aim of the Care Assistant is to help the older person with everyday needs. Informal Carer: Informal carers include unpaid family members, friends, and neighbors who help meet older persons' needs for care and support, including meeting emotional (visiting and support), financial (help with managing bills), domestic (help with shopping), and personal (help with dressing) care needs. Care Manager: A Care Manager, usually a social worker or a nurse, coordinates the delivery of care to the older person and plans the work of the care assistants. Benefits Agency: The Benefits Agency actor represents a financial agency that helps older persons financially. The dependencies, goals, and security constraints of these actors are modeled in figure 10.5.
[Figure 10.5 here]
For instance, the Older Person depends on the General Practitioner to Receive Appropriate Care and on the Informal Carer to Receive Support.. On the other hand, The Nurse depends on the Secondary Care Professional to Manage Specialist Needs, on the Care Manager to Coordinate Care Delivery, on the Social Worker to Manage Social Needs, and on the Older Person to Obtain Overview Assessment Information. However, one of the most important and delicate matters for the older person is the privacy of their personal medical information and the sharing of it. Therefore, the Older Person imposes a security constraint (Share Information Only if Consent is Obtained) on the Nurse for the Obtain Overview Assessment Information dependency to be valid. In addition, the Social Worker imposes a security constraint (Keep Financial Information Private) on the Benefits Agency for the Provide Benefits dependency to be valid.
Modeling the security constraints of the individual actors allows developers to model the security requirements of the system according to the real security needs of its stakeholders. In the example, the failure to identify security constraints between the Nurse and the Older Person, or the Social Worker and the Benefits Agency, would result in a design that would be missingmiss important information regarding the security of the system. Even if experienced, security-aware developers would have identified these issues during the late-requirements stage of the development process, such an approach would have been based solely dependable on their expertise and it would not be possible to trace the development back to the stakeholders needs.
When the security constraints have been identified, the next step (from the security point of view) involves further analysis of each of the actors to identify any additionalmore possible security constraints that are considered internal for each of the actors. For instance, the Social Worker actor has nois not imposed any security constraints imposed during the early stages of early- requirements analysis. However, an internal analysis of this actor, performed with the aid of goal diagrams in Secure Tropos, indicates that the Social Worker actor does haveis imposed some security constraints imposed. The analysis of the security constraints starts by identifying which goals of the actor they restrict. The assignment of a security constraint to a goal is indicated by using a constraint link (a link that has the restricts tag). For example, as shown in figure 10.6, the analysis of the Social Worker has indicated that in order for the Social Worker to satisfy the Manage Social Needs goal, she/he must provide information about the older person (Provide Older Person Information). However, a security constraint is imposed on this goal: to share the information only if the older persons consent has been obtained (Share Information Only if Consent Obtained). To satisfy this security constraint, a secure goal is introduced on the actor.
[Figure 10.6 here]
Furthermore, the analysis indicates that the uUse of eSAP will enable the Social Worker actor to work more efficiently, with less effort, greater convenience, and greater speedfaster. However, our analysis (Mouratidis, 2004) indicated that Authorization is required for the eSAP system (in order to help towards the Privacy security feature). Therefore, the security constraint Allow Access Only to Authorized Users, which restricts the Use eSAP plan, is imposed on the Social Worker actor. To help intowards the satisfaction of the imposed security constraint, the secure goal Provide Authorization Details is introduced for the Social Worker.
Modeling security constraints when analyzing the actors internally leads to a more precise definition of the why of the system security, and this subsequently helps to verify how the final security implementation of the system matches the stakeholders real needs. When all the actors have been further analyzed, the actor diagram is refined, as shown in figure 10.7, and any possible new dependencies identified during the internal actors analysis are modeled. The figure represents only part of the analysis; it has been truncated due to space limitations.
[Figure 10.7 here]
This is important because during the actors internal analysis it is possible that new goals are discovered that actors might not be able to achievesatisfy by themselves. Therefore, new dependencies are introduced to enable an actor to delegate to another actor the goals she/hewho cannot accomplish on her/histheir own. From the security point of view, refining an actors goals and dependencies could result in the redefinition of the security constraints imposed onto particular dependencies or the addition of new security constraints. As an example, consider the security constraint Share Information Only if Consent Obtained. This security constraint was imposed on the Nurse, as shown in figure 10.5, by the Older Person as part of the Obtain Overview Assessment Information dependency. However, the internal analysis (Mouratidis, 2004) of the Nurse indicated that this security constraint in fact restricts in fact the Obtain Older Person Information goal of the Nurse. Therefore, in the refined actor diagram (figure 10.7), the security constraint has been imposed on all the newly discovered (after the internal analysis of the actors) dependencies that involve the Obtain Older Person Information goal.
10.3.2 Late-Requirements Analysis
In the late-requirements stage, the functional, security, and other nonfunctional requirements for the system-to-be are described. The system-to-be is introduced as one or more actors who have a number of dependencies with the other actors of the organization (defined during the early-requirements stage), and it (the system) contributes to the goals of the stakeholders.
Therefore, the eSAP system has been introduced as another actor that receives the responsibility for the fulfillment of some of the goals identified during the early-requirements analysis for the systems actors. of the system. In other words, some goals that the systems actors of the system cannot fulfill or are better fulfilled by the eSAP system are delegated to it. BecauseSince dependencies are delegated from the actors to the eSAP system, possible security constraints regarding those dependencies are also delegated. For example, before the introduction of the eSAP system, the Social Worker depended on the Nurse to Obtain Older Person Information. However, this secure dependency involves the security constraint (restricting the Nurse) Share Information Only if Consent Obtained. With the introduction of the eSAP system, the Social Worker actor depends on the eSAP to Obtain Older Person Information. Therefore the eSAP becomes responsible for satisfying the Share Information Only if Consent Obtained security constraint that is delegated together with the secure dependency.
To satisfy all the delegated dependencies, the main goal of the eSAP system has been identified as Automate Care. By performing a means-end analysis it was foundidentified that for the eSAP system to fulfill the Automate Care goal, the following subgoals must be accomplished: Assist with Assessment Procedures, Provide Older Person Information, Manage Care Plans, and Schedule Meetings. Each of those subgoals can be furthered analyzed by employing means-end analysis, as shown in figure 10.8.
[Figure 10.8 here]
An important issue at this point is to check whether the goals assigned to the eSAP system satisfy all the goals and security constraints delegated to the system by the other actors. Our analysis (Mouratidis, 2004) indicated that this is the case. Each of the secure constraints can be satisfied with the aid of one or more secure goals that the late- requirements analysis produced. In addition, to satisfy the security of the system, different security constraints are imposed on the system (according to the security policy defined in the previous section). Due to lack of space, Iin our case study, due to lack of space, we only consider only the Keep System Data Private security constraint that is imposed in order to contribute to the privacy of the system. To satisfy this constraint, a secure goal Ensure System Privacy is introduced into the system. This goal can be achieved either through the subgoal Block Access to the System, which blocks any access to the system (obviously not desirable); or through providing partial access, partially, which allows access only from a central computer (Central Computer Access); or through performing privacy controls (Ensure System Privacy). The lastlatter subgoal is achieved by the subgoal Perform Cryptographic Procedures or the subgoal Perform Authorization Checks, which in turn is fulfilled by the plans Check Access Control, Check Information Flow, and Check Authentication. Each of those plans can be executed by considering different alternatives. For example, in order to check authentication, different alternatives can be considered such as Check Password, Check Biometrics, or Check Digital Signatures can be considered. An approach to evaluate the different alternatives could be based on the use of the measures of complexity and criticality (Bresciani, Giorgini, Mouratidis, & Manson, 2004). Complexity represents the effort required from an actor to achieve a (security) plan, whereaswhile criticality represents how the (security) goals of the actor will be affected if a (security) plan is not executed. Thus, by knowing how complex and how critical the different alternatives are, we can decide which alternative is the best solution.
10.3.3 Architectural Design
The architectural design phase defines the systems global architecture. During architectural design the first step is to identify the overall architectural organization by selecting among alternative architectural styles, using as criteria the nonfunctional requirements of the system identified in the previous stage.
However, quality characteristics (nonfunctional requirements) are difficult to measure becausesince it is difficult to obtain get empirical evidence during the design stages. For this reason, we employ an analysis process based on an independent probabilistic model that uses the measure of satisfiability proposed by Giorgini, Nicchiarelli, Mylopoulous, and Sebastiani (2004), in whichwhere satisfiability represents the probability that the nonfunctional requirement will be satisfied. This method is selected over other similar methods mainly because its concepts and process are well fitted to the concepts and processes of the Secure Tropos approach.
The analysis involves the identification of more specific nonfunctional requirements by refining the ones identified during the late-requirements stage, and by the evaluation of different architectural styles against those requirements. From the security point of view, the alternative architectural styles are evaluated against the secure goals and plans identified during the late-requirements analysis.
In particular, the evaluation results in contribution relationships from the architectural styles to the probability of satisfying the security requirements of the system. We use a weight to express the contribution of each style to the satisfiability of the security requirements (Mouratidis et al., in press). Weights take a value between 0 (the style is not suitable for satisfying the requirement) and 1 (the style is suitable for satisfying the requirement), and they are assigned after reviewing different studies (Bass, Clements, & Kazman, 1998; Bosch, 2000), evaluations (Fielding, 2000), and comparisons (Puliafito, Riccobene, & Scarpa, 2001) involving the architectural styles.
Due to lack of space we briefly illustrate the above approach for the eSAP case study by considering two architectural styles: a hierarchical style, Client/Server, and a mobile code style, Mobile Agents, with privacy as our security requirement. As shown in figure 10.9, each of the two styles satisfies differently each of the nonfunctional requirements of the system differently.
[Figure 10.9 here]
Regarding security, the Mobile Agents style offers a greater opportunity for abuse and misuse by broadening the scale of security issues significantly (Kotz & Mattern, 2000). This is due to the fact that mobility is involved. Thus, although protection of a server from mobile agents, or generally mobile code, is an evolution of security mechanisms applied in other architectural styles, such as Client/Server, the mechanisms focused on the protection against the Mobile Agents byfrom the server cannot, so far, prevent malicious behavior from occurring but may be able to detect it (Kotz & Mattern, 2000). For example, the use of mobile agents is more likely to lead to damaging the information flow property (Check Information Flow, weight 0.4) becausesince possible platforms that a mobile agent can visit may expose sensitive information from the agent (Kotz & Mattern, 2000). In the case of the Client/Server style (weight 0.8), sensitive information is stored in the server, and existing security measures can satisfy the information flow attribute.
As mentioned by Castro, Kolp, and Mylopoulos (2001), an interesting decision that comes up during architectural design is whether fulfillment of an actors obligations will be accomplished through assistance from other actors, through delegation, or through decomposition of the actor into component actors. Thus, when various architectural styles have been evaluated, and one has been chosen, the next step of the architectural design stage involves the introduction of new actors and their dependencies, as well as the decomposition of existing actors into subactors and the delegation of some (security) responsibilities from the existing actors to the introduced subactors.
Figure 10.10 shows a partial decomposition of the eSAP system. In this example, focused on privacy, the eSAP system delegates responsibility for the Ensure System Privacy secure goal to the Privacy Manager. The Privacy Manager, in order to efficiently fulfill the Ensure System Privacy secure goal, delegates responsibility to the Authorization Manager (to fulfill the Check Authorization secure subgoal), to the Access Control Manager (to fulfill the Check Access Control secure subgoal), to the Information Flow Manager (to fulfill the Check Information Flow secure subgoal), and to the Cryptography Manager (to fulfill the Use Cryptography secure goal).
[Figure 10.10 here]
The last step of the architectural design is to identify capabilities for each of the actors by taking into account their dependency relationships. of the actors. A capability represents the ability of an actor to define, choose, and execute a plan for the fulfillment of a goal, given certain world conditions and in the presence of a specific event (Perini, Bresciani, Giorgini, Giunchiglia, & Mylopoulos, 2001, September). For example, the Authorization Manager should have capabilities such as obtaining authorization details and providing authorization clearance. However, tThe process of identifying capabilities for each actor has been extensively described in the literature (Mouratidis, Giorgini, Manson, & Philp, 2002; Perini et al., 2001, September); and thus it is not described here.
10.4 Security Reference Diagram
As presented in the previous section, the Secure Tropos concepts enable the methodology to model security requirements during the software development process. However, the identification of security requirements in the very early phase of software development is still a problematic activity. In order to help developers in their work, we introduce the security reference diagram.
The security reference diagram represents the relationships between security features, threats, protection objectives, and security mechanisms; its main purpose is to provide security novices with a valuable reference point when considering security issues during the development of information systems. Moreover, the security reference diagram aims to allow flexibility during the development stages of an information system and also to save time and effort. Many systems under development are similar to systems already in existence. Therefore the security reference diagram can be used as a reference point that can be modified or extended according to specific needs of particular systems.
The process of constructing the security reference diagram can be seen as a graph transformation process (Andries et al., 1999; Bresciani & Giorgini, 2002) that allows the progressive derivation of the final diagram through more and more precise versions, according to the application of a set of rules to the diagram. For the construction process of the security reference diagram, the developer considers the security features of the system-to-be, the protection objectives of the system, the security mechanisms, and also the threats to the systems security features. Security features (also protection properties) represent features associated with security that the system-to-be must have. Examples of security features are privacy, availability, and integrity. Protection objectives represent a set of principles or rules that contribute to the achievement of the security features. Examples of protection objectives are authorization, cryptography, and accountability. Security mechanisms represent standard security methods for helping in the satisfaction of the protection objectives. It must be noticed that fFurther analysis of some security mechanisms is required to allow developers to identify possible security submechanisms. A security submechanism represents a specific way of achieving a security mechanism. For instance, authentication isdenotes a security mechanism for the fulfillment of a protection objective such as authorization. However, authentication can be achieved by submechanisms such as passwords, digital signatures, and biometrics. Threats represent circumstances that have the potential to cause loss or problems that can endanger the security features of the system. Examples of threats are social engineering, password sniffing, and eavesdropping attacks.
The notation of the security reference diagram can be adapted to reflect the notation of the methodology into whichthat the diagram is integrated into. This is very useful becausesince it allows developers to work with well-known concepts and enables them to use the same concepts throughout the development process. In our work, to better integrate the security reference diagram with the Secure Tropos development process, the Tropos concepts softgoal, goal, and plan are used to model the security features, protection objectives, and security mechanisms, respectively. The standard graphical notation is used for these concepts. In addition, threats are shown as pentagons.
In a security reference diagram each of the aforementioned nodes is associated with the aid of two types of links (similar to the contribution links that can be found in the Tropos methodology): positive and negative contribution links. A positive contribution link associates two nodes when one node helps in the fulfillment of the other. Consider, for instance, a protection objective that contributes positively to the satisfaction of a security feature. A negative contribution link, on the other hand, indicates that a node contributes to the denial of another node. As a result, in every security reference diagram, each security feature identified receives positive contributions from different protection objectives and negative contributions from different threats. Graphically, a positive contribution link is modeled as an arrow that points toward the node that is satisfied with a plus (+), whereas a negative contribution link is represented as an arrow with a minus ().
Figure 10.11 presents a partial security reference diagram for the eSAP case study in whichwhere Privacy, Integrity, and Availability are the main security features.
[Figure 10.11 here]
Each of these features receives a number of negative and a number of positive contributions. For instance, the size of the electronic single assessment process system and the large number of health- and social-care professionals that might be involved introduce the problem of data aggregation and increase the risk of social engineering or unauthorized access. On the other hand, Privacy receives positive contributions from Authoriszation and Cryptography.
10.5 Security Attack Scenarios
An important issue in security engineering is to test how the system under development copes with any possible security attacks. Testing is widely considered an important activity that helps to identify errors in a system, and techniques such as control and data flow testing, formal specifications, special testing languages, and test tools have been used for many years in testing systems, and they are considered valuable solutions for many projects. However, most of these approaches are difficult to apply, they require special training and skills, and they employ their own concepts and notations (Ryser & Glinz 1999). November). On the other hand, scenarios are perceived by stakeholders as a natural way to express their ideas about the system and by the developers as helpful and valuable tools, which can be represented in various ways (Ryser & Glinz, 2000). The latter point allows developers flexibility in their analysis and design. Therefore, a technique that is based on the use of scenarios and uses the same concepts and notations has been developed and integrated into the Tropos security-oriented process to enable developers to test the system under development. Scenarios are represented as enhanced Tropos diagrams and are used to test how the system copes with different kinds of security attacks.
Therefore a scenario should include enough information about the system and its environment to allow validation of the security requirements. Thus,As such, we define a security attack scenario (SAS) as "an attack situation describing the actors of a software system and their secure capabilities as well as possible attackers and their goals, and it identifies how the secure capabilities of the system prevent (if they prevent) the satisfaction of the attackers goals" (Mouratidis, 2004, p. 115).
With the aid of security attack scenarios, developers can identify the goals and the intentions of possible attackers, and through these, identify a set of possible attacks to the system (test cases). Then these attacks are applied to check whether the system is compromised or not. By analyzing the goals and the intentions of the attackers, developers obtain valuable information that helps them to understand not only how the attacker might attack the system, but also why an attacker wants to attack the system. This leads to a better understanding of how possible attacks can be prevented. In addition, the application of a set of identified attacks to the system contributes to the identification of attacks with which the system might not be able to cope (failed test cases), and this leads to the redefinition of the actors of the system and the addition of new secure capabilities to enable them to protect against those attacks.
A security attack scenario involves a possible attacker, possible attack(s), the resources that are attacked, and the actors of the system related to the attack together with their secure capabilities. An attacker is depicted as an actor who aims to break the security of the system. The attackers intentions are modeled as goals and plans, and their analysis follows the same reasoning techniques that the Tropos methodology employs for goal and plan analysis. Attacks are depicted as dash-lined links (called attack links) that contain an attacks tag that starts from one of the attackers goals and ends at the attacked resource (see, for example, figure 10.12).
[Figure 10.12 here]
For the purpose of a security attack scenario, a differentiation is made between actors internal to and external to the system. Internal actors represent the core actors of the system, whereas external actors represent actors that interact with the system. This differentiation is essential becausesince it allows developers to identify different attacks on resources of the system that are exchanged between external and internal actors. of the system.
The process is divided into three main stages (Mouratidis, Giorgini, & Manson, in press): creation of the scenario, validation of the scenario, and testing and redefinition of the system according to the scenario.
During scenario creation the attackers intentions are identified together with possible attacks to the system. Moreover, possible countermeasures of the system against the indicated attacks are also identified. Regarding the eSAP case study, it was concluded that the main security features of the system are privacy, integrity, and availability. According to Stallings (1999), the following categories of attacks can be identified that can endanger these security features.
Interception, in which an unauthorized party, such as a person, a program, or a computer, gains access to an asset. This is an attack on privacy.
Modification, in which an unauthorized party not only gains access to, but also tampers with, an asset. This is an attack on integrity.
Interruption, in which an asset of the system is destroyed or becomes unavailable or unusable. This is an attack on availability.
Due to lack of space, we only present only a security attack scenario related to a modification attack. The modification scenario involves an Attacker that wishes to attack the integrity of the eSAP system. As identified in the analysis of the security reference diagram, three main threats are involved in this kind of attack: cryptographic attacks, care-plan changing, and viruses.
Therefore, the Attackers main goal, Attack eSAP Integrity, can be decomposed to modify content of messages, change values in data files, and alter programs to perform differently (figure 10.12).
The first subgoal involves the Attacker trying to Modify the Content of any Messages transmitted over the network. To fulfill this goal, the Attacker might try to employ cryptographic attacks against any resource transmitted between any external actors and the eSAP system. The second subgoal indicates the attacker is trying to Change the Values in Data Files of the system. The fulfillment of this goal can be satisfied by means of changing the data of resources stored in the eSAP system. The third subgoal indicates the attempt of the Attacker to alter a program so it performs differently. Mainly This can be achieved mainly by using viruses that can alter the behavior of specific programs in order to enable the attacker to gain access to the system or to itssystems information.
As an example, consider the scenario in which a social worker wishes to obtain an assessment evaluation (Mouratidis, 2004). Three main test cases are identified: Cryptographic Attacks, Data Changing Attacks, and Virus Attacks. An example of the virus test case is shown below.
Test Case 3: Viruses
Precondition The Attacker tries to change the system behavior by using some kind of virus.
System expected security reaction The system should be able to prevent viruses.
Discussion Viruses areconsist one of the most sophisticated threats to computer systems. It is quite common for attackers to send viruses to computer systems they want to attack in order to exploit vulnerabilities and change the behavior of the system. Although many effective countermeasures have been developed for existing types of viruses, many new types of viruses are also developed frequently.
An ideal measuremeasurement against viruses is prevention. In other words, viruses should not get into the system. However, this is almost impossible to achieve. Therefore, the best approach is to be able to detect, identify, and remove a virus. Auditing helps in the detection of the virus. However, apart from this, the eSAP system is not protected against viruses.
Test case results The eSAP system needs to be integrated with an antivirus program to enable it to effectively detect, identify, and remove any possible viruses. Such a program, which could be an internal actor of the eSAP system, should be able to monitor the system and take effective measuresmeasurements against any possible viruses.
The test cases are applied and a decision is madeformed as to whether the system can prevent the identified attacks or not. The decision whether an attack can be prevented (and in what degree) or not is the responsibilitylies of on the developer. However, as an indication of the decision it must be taken into consideration that at least one secure capability must help against an attack in order for the developer to decide the attack can be prevented. Attacks that cannot be prevented are notated as solid attack links (as opposed to dashed attack links).
For each attack that it has been decided it cannot be prevented, extra capabilities must be assigned to the system to help totowards the prevent prevention of that attack. In general, the assignment of extra secure capabilities is not a unique process and depends on the perception of the developer regarding the attack dangers. However, a suitable approach is to analyze the capabilities the attacker used to perform the attack and assign the system with capabilities that can counteractrevoke the attackers capabilities.
10.6 Patterns
One of the most challenging issues when developing a methodology for designing secure information systems is allowing developers with minimum security knowledge to consider security issues during the development process. To this end,Towards this direction we propose to complement Secure Tropos with the use of security patterns. Security patterns capture existing proven experience about how to deal with security problems during software development and they help to promote best design practices.
10.6.1 The Pattern Language
Patterns are only point solutions that need to be organized into pattern languages. A pattern language is a set of closely related patterns that guide the developer through the process of designing a system (Alexander, Ishikawa, & Silverstein, 1977). As the patterns from a pattern language are applied, each pattern suggests new patterns to be applied that further refine the design, continuing until no more patterns can be applied.
BecauseSince we integrate security patterns into an agent-oriented software engineering methodology, our pattern language employs agent-oriented concepts, such as intentionality, autonomy, sociality, and identity. Therefore, the structure of a pattern is described not only in terms of collaborations and message exchanges between the agents involved in the patterns, but also in terms of their social dependencies and intentional attributes, such as goals and plans. This allows for a complete understanding of the pattern's social and intentional dimensions.
Our pattern language contains four patterns and it describes the relationship of these patterns towith other existing patterns. In particular the language contains the AGENCY GUARD pattern, which provides a single, nonbypassable point of access to an agency, the AGENT AUTHENTICATOR, which provides authentication services to an agency, the SANDBOX. Thiswhich allows an agency to execute nonauthorized agents in a secure manner, and the ACCESS CONTROLLER, which allows an agency to provide access to its resources according to its security policy.
Figure 10.13 provides a road map of our pattern language. The directed links in the road map show dependencies between patterns; they alsoand point from a pattern to the patterns that developers may want to consult next, once the first pattern has been applied. It is worth mentioning that the patterns of the language have been identified from real implementations of agent-based systems and that their (patterns) initial versions have been presented in pattern-related events (Mouratidis, Giorgini, & Weiss, 2003) in order to validate them and improve them.
[Figure 10.13 here]
We use the so-called Alexandrian format for organizing each pattern (Alexander et al., 1977). The sections of a pattern are context, problem, forces, solution, and rationale, with each section set off from the next by a set of stars. The rationale section is organized into benefits, liabilities, and related patterns. To provide an indication of how our pattern language organizes each of the patterns, we present the details of the Agency Guard pattern. For a complete description of the language, see Mouratidis, Weiss, and Giorgini (2005).
Agency Guard
Context
... a number of agencies exist in a network. Agents from different agencies must communicate with each other or exchange information. This involves the movement of some agents from one agency to another, or requests from agents belonging to one agency for resources belonging to another agency.
(((
Problem
A malicious agent that gains unauthorized access to the agency can disclose, alter, or generally destroy data residing in the agency.
(((
Forces
Many malicious agents will try to gain access to agencies that they are not allowed to access. Depending on the level of access the malicious agent gains, it may be able to completely shut down the agency, or exhaust the agency's computational resources and thus deny services to authorized agents. The problem becomes the more severe the more back doors there are to an agency, enabling potential malicious agents to attack the agency from many places. On the other hand, not all agents trying to gain access to the agency must be treated as malicious; but rather, access should be granted based on the security policy of the agency.
(((
Solution
Ensure that there is only a single point of access to the agency.
When a Requester Agent wishes to gain access to an Agency (either to access resources or to move to this agency), its requests must be directed to an Agency Guard that is responsible for granting or denying access requests according to the security policy of the agency. The Agency Guard is the only point of access to the Agency and cannot be bypassed, meaning that all access requests must go through it. In traditional terms, the concept of an Agency Guard is referred to as a monitor (Amoroso, 1994).
The structure of the pattern in terms of the actors involved and their social dependencies is shown in figure 10.14, using the Tropos notation, where each node represents an actor and each dependency link between two actors indicates that one actor depends on the other for some goal, plan, or resource to be retained. Moreover, actors are analyzed internally (internal analysis indicated within the dashed-line circles) with the aid of means-end links, which are used to indicate means (goals/plans) for reaching a goal. For example, the Agency depends on the Agency Guard to grant or deny access to the Agency. The Agency Guard will grant or deny access according to the security policy of the Agency, and depends on the Agency to obtain this security policy.
(((
Rationale
Benefits
It is easier to secure a single point of access rather than many back doors.
Only the Agency Guard needs to be aware of the security policy, and it is the only entity that must be notified if the security policy changes.
Being the single point of access, only the Agency Guard must be tested for correct enforcement of the agency's security policy.
Liabilities
Requester Agents need to present all credentials, even though they may only be required for only some operations on the agency. The credentialsThis must include their identity.
A malicious Requester Agent may maskmasquerade its identity.
A single point of access to the agency can degrade the performance of the agency (that is, its response time for handling access requests).
The Agency Guard is a single point of failure. If itthe Agency Guard fails, the security of the agency as a whole is at risk.
We cannot prevent Requester Agents from attempting to circumvent the Agency Guard. We therefore also need to log access requests.
Related patterns
Agent Authenticatorensures the identity of the Requester Agent.
[Figure 10.14 here]
10.6.2 Formalizing the Pattern Properties Using Formal Tropos
An important consideration in the development of a pattern language is to assess its completeness. For this reason, in addition to the graphical representation we have developed a formalization of the language. Patterns are formalized in terms of the problems they address and the solutions they offer. We consider a pattern language to be complete if the solutions proposed by the patterns contained in the language address all the problems raised. It is important to note that completeness can only be assessed only with regard to a stated set of problems. As new security problems are identified, the pattern language needs to be extended.
Our formalization of patterns is only partial. formalization. A full formalization may not even be desirable, considering that patterns are meant to be human-readable artifacts, and applying a pattern often requires adapting itthe pattern to the specific needs of a given context. We therefore focus on the following sections of a pattern: problem (addressed by this pattern), solution (how the problem is addressed), and consequences (new problems raised). The solution is included in the formalization becausesince the application of a pattern results in elements being added to the model that other problem statements may refer to. BecauseAs Tropos is used to describe the solutions, we represent problems and solutions using Formal Tropos (FT) (Fuxman, 2001).
In passing, it should be noted that a solution that establishes security isdoes not necessarily imply that it is the best solution in terms of other system qualities. Not included in our formalization are nonsecurity softgoals such as complexity. The contributions to nonsecurity softgoals could be used to compare alternative selections of patterns in terms of the quality of the overall solution (i.e., the combined result of applying the patterns). We will incorporate the formalization of nonsecurity softgoals in our future work.
For reasons of space, we present only the formalization of the Agency Guard pattern. We present the problem addressed, the solution, and new problems introduced by the pattern. The formalization of problems appears where they are first raised, and are referenced in later patterns. Such an approach also proves helpful in ensuring that the description of problems does not make use of any of the new model elements that are introduced by the solution but which were not part of the model before the pattern was applied.
10.6.2.1 Agency Guard Formalization
This pattern states that requester agents can access the agency from multiple places via the GainAccessToAgency goal dependency. The formalization of the problem (P1) specifies that there is a way for a RequesterAgent to gain access to the agency by exploiting multiple GainAccessToAgency dependencies in which it participates. Solution S1 resolves this problem, as specified in the last clause of the assertion. Problem P2 also introduces the notion of an owner to be associated with a RequesterAgent. In essence, the formalization of P2 indicates that just ensuring that agents can only access the agency through only a single point does not ensure that the agents are who they claim to be. This problem needs to be addressed separately.
Problem: /* P1: A malicious agent can gain unauthorized access to the agency from multiple places, not all of which provide the same level of security. */
( ra : RequesterAgent (( ga1, ga2 : GainAccessToAgency
(ga1.depender = ra ( ga2.depender = ra ( ga1.dependee `" g a 2 . d e p e n d e e ) ) <