Integrating security and software engineering: advances and future visions [illustrated edition] 9781599041476, 1-59904-147-2, 1599041480, 1599041499

Citation preview

Integrating security and software engineering: advances and Future Visions Haralambos Mouratidis, University of East London, UK Paolo Giorgini, University of Trento, Italy

Idea Group publIshInG Hershey • London • Melbourne • Singapore

Acquisitions Editor: Senior Managing Editor: Managing Editor: Development Editor: Copy Editor: Typesetter: Cover Design: Printed at:

Michelle Potter Jennifer Neidig Sara Reed Kristin Roth Larissa Vinci Jennifer Neidig Lisa Tosheff Yurchak Printing Inc.

Published in the United States of America by Idea Group Publishing (an imprint of Idea Group Inc.) 701 E. Chocolate Avenue Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail: [email protected] Web site: http://www.idea-group.com and in the United Kingdom by Idea Group Publishing (an imprint of Idea Group Inc.) 3 Henrietta Street Covent Garden London WC2E 8LU Tel: 44 20 7240 0856 Fax: 44 20 7379 3313 Web site: http://www.eurospan.co.uk Copyright © 2007 by Idea Group Inc. All rights reserved. No part of this book may be reproduced in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Library of Congress Cataloging-in-Publication Data Integrating security and software engineering : advances and future visions / Haralambos Mouratidis and Paolo Giorgini, editors. p. cm. Summary: “This book investigates the integration of security concerns into software engineering practices, drawing expertise from the security and the software engineering community; and discusses future visions and directions for the ield of secure software engineering”--Provided by publisher. ISBN 1-59904-147-2 (hardcover) -- ISBN 1-59904-148-0 (softcover) -- ISBN 1-59904-149-9 (ebook) 1. Computer security. 2. Software engineering. I. Mouratidis, Haralambos, 1977- II. Giorgini, Paolo. QA76.9.A25I5527 2006 005.8--dc22 2006011138

British Cataloguing in Publication Data A Cataloguing in Publication record for this book is available from the British Library. All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher.

Integrating security and software engineering: advances and Future Visions

Table of Contents

Foreword........................................................................................................... vi Preface.............................................................................................................. vii Chapter.I Integrating.Security.and.Software.Engineering:.An.Introduction.............. 1 H. Mouratidis, University of East London, UK P. Giorgini, University of Trento, Italy

Section.I:.Security.Requirements.Engineering Chapter.II Arguing.Satisfaction.of.Security.Requirements........................................... 16 C. B. Haley, The Open University, UK R. Laney, The Open University, UK J. D. Moffett, The Open University, UK B. Nuseibeh, The Open University, UK

Chapter.III Identifying.Security.Requirements.Using.the.Security.Quality. Requirements.Engineering.(SQUARE).Method.......................................... 44 N. R. Mead, Carnegie Mellon University, USA Chapter.IV A.Social.Ontology.for.Integrating.Security.and.Software.Engineering..... 70 E. Yu, University of Toronto, Canada L. Liu, Tsinghua University, China J. Mylopoulos, University of Toronto, Canada

Section.II:.Modelling.and.Developing. Secure.Software.Systems.Using.Patterns Chapter.V A.Methodology.to.Develop.Secure.Systems.Using.Patterns...................... 107 E. B. Fernandez, Florida Atlantic University, USA M. M. Larrondo-Petrie, Florida Atlantic University, USA T. Sorgente, Florida Atlantic University, USA M. Vanhilst, Florida Atlantic University, USA Chapter.VI Modelling.Security.Patterns.Using.NFR.Analysis..................................... 127 M. Weiss, Carleton University, Canada

Section.III:.Modelling.Languages.and.Methodologies. for.Secure.Software.Development Chapter.VII Extending.Security.in.Agile.Software.Development.Methods.................. 143 M. Siponen, University of Oulu, Finland R. Baskerville, Georgia State University, USA T. Kuivalainen, University of Oulu, Finland Chapter.VIII Modelling.Security.and.Trust.with.Secure.Tropos.................................... 160 P. Giorgini, University of Trento, Italy H. Mouratidis, University of East London, UK N. Zannone, University of Trento, Italy

Chapter.IX An Integrated Security Veriication and Security Solution Design Trade-Off.Analysis.Approach...................................................................... 190 S. H. Houmb, Norwegian University of Science and Technology, Norway G. Georg, Colorado State University, USA J. Jürjens, TU Munich, Germany R. France, Colorado State University, USA Chapter.X Access Control Speciication in UML.......................................................... 220 M. Koch, Free University of Berlin, Germany F. Parisi-Presicce, University of Rome “La Sapienza”, Italy K. Pauls, Free University of Berlin, Germany Chapter.XI Security.Engineering.for.Ambient.Intelligence:.A.Manifesto................... 244 A. Maña, University of Malaga, Spain C. Rudolph, Fraunhofer Institute for Secure Information Technology, Germany G. Spanoudakis, City University, UK V. Lotz, SAP Research, France F. Massacci, University of Trento, Italy M. Melideo, Engineering Ingegneria Informatica, Italy J. S. López-Cobo, ATOS Origin, Spain Chapter.XII Integrating.Security.and.Software.Engineering:.Future.Vision.and. Challenges...................................................................................................... 271 H. Mouratidis, University of East London, UK P. Giorgini, University of Trento, Italy About.the.Authors......................................................................................... 276 Index.. ............................................................................................................. 286

vi

Foreword

Protecting valuable assets from intentional harm has been a focus of human ac-

tivity from time immemorial. The proliferation of computers in society has meant that many business and mission critical assets are increasingly stored and manipulated by computer-based systems. The scale of misuse of these assets has also increased, because of their worldwide accessibility through the Internet and the automation of systems. Security is concerned with the prevention of such misuse. While no system can be made completely secure, understanding the context in which a system will be deployed and used, the risks and threats of its misuse, and the systematic development of its software, are increasingly recognized as critical to its success. The cross-fertilization of systems development techniques from software engineering and security engineering offers opportunities to minimise duplication of research efforts in both areas, and, more importantly, to bridge gaps in our knowledge of how to develop secure software-intensive systems. This book provides one of the first attempts to collect research work that draws upon software engineering to develop such systems more effectively. Contributions to this volume draw upon research and techniques from a range of software engineering activities, such as requirements engineering and specification, software patterns and design, and method and process-driven development. An important secondary role of this book is to reach out and appeal to the traditional security engineering community to engage with — even guide — the software engineering community, in order to focus software engineering research on key issues of secure software systems development. If successful, these collected works may well provide the foundations for some seminal work in this area. Bashar Nuseibeh The Open University, UK January 2006

vii

preface

As software systems become more and more critical in every aspect of the human society, so does the demand to secure these systems. This is mainly because private information is stored in software systems and without enough security guarantees, organizations (and individuals) are not willing to share information or even use the technology. Even though security is an important issue, it is usually treated superficially and the usual security process is to add a standard set of security mechanisms, such as authentication, into the system. However, it has been identified in many cases that securing software systems is not only about providing a set of standard security mechanisms. Fitting security enforcement mechanisms into an existing design, can lead to serious design challenges that usually translate into the emergence of computer systems afflicted with security vulnerabilities. Providing adequate security requires the capability of reasoning about security. This means that software systems must be designed and deployed not only to meet certain functional requirements, but also to comply with the security requirements of the companies and/or organizations they are deployed at. In other words, security considerations must be integrated within software engineering practices to allow software system developers to consider security from the early stages of the development process. Traditionally, software engineering deals with security as a non-functional requirement and usually considers it after the definition of the system. One of the reasons is that the research areas of software engineering and security engineering work independently. On one hand, software engineering techniques and methodologies do not consider security as an important issue, although they have integrated concepts such as reliability and performance, and they usually fail to provide precise enough semantics to support the analysis and design of security requirements and properties. On the other hand, security engineering research has mainly produced formal and theoretical methods, which are difficult to understand by non security experts and which, apart from security, they only consider limited aspects of the system.

viii

This separation of work h as resulted in an ab stractio n g ap that makes the integration and practical application of security issues on modelling languages and software engineering methodologies difficult. This book aims to provide the first step towards narrowing the gap between security and software engineering. To achieve this aim, this book (1) introduces the field of secure software engineering, a branch of research investigating the integration of security concerns into software engineering practices, which draws expertise from the security and the software engineering community; (2) introduces the problems and the challenges of considering security during the development of software systems; (3) it provides readers an understanding of the predominant theoretical and practical approaches that integrate security and software engineering by describing current secure software engineering approaches; and (4) it discusses future visions and directions for the field of secure software engineering.

ORGANIZATION. OF. THIS. BOOK This book is organized into three main sections: Security Requirements Engineering, Modelling and Developing Secure Software Systems Using Patterns, and Modelling Languages and Methodologies for Secure Software Development. The Security Requirements Engineering section (Section I) is organized into three chapters, Chapters II, III, and IV. The Modelling and Developing Secure Software Systems Using Patterns section (Section II) includes two chapters, Chapters V and VI. The Modelling Languages and Methodologies for Secure Software Development section (Section III) is organized into five chapters, Chapters VII, VIII, IX, X, and XI. Additionally to these, we have the first chapter that introduces the problem of integrating security and software engineering, and a conclusive chapter that illustrates and explores challenges and future research directions of the field. A brief description of each of the chapters follows. Chapter.I (Integrating Security and Software Engineering: An Introduction) by H. Mouratidis and P. Giorgini, is an introduction to the current advances in the development of secure software systems. It provides an overview of the problem from the perspectives of security and software engineering, and introduces the field of Secure Software Engineering as a new branch of research concerned with the development of secure software systems, which integrates security and software engineering. Secure software engineering results in a situation where security is considered as part of the development process leading to the development of more secure software systems. In particular, the chapter discusses the research areas of software and security engineering are and it emphases the characteristics of these areas. Then the current state of the art on software and security engineering is presented, emphasizing the latest approaches to secure software engineering. Chapter.II.(Arguing Satisfaction of Security Requirements) by C. B. Haley, R. Laney, J. D. Moffett, and B. Nuseibeh proposes an approach to carry out security requirements engineering, namely the process of eliciting, specifying, and analyzing

ix

the security requirements for a system. The approach is founded on four main components. The first component is a framework that provides a systematic statement of the roles and relationships of security goals, security requirements, and security functions, and their relationships with other system and software requirements. The second is a way of describing threats and their interactions with the system. The third is a precise definition of security requirements. The fourth is a two-layer set of arguments to assist with validating the security requirements within the context of the system, to determine that the system is able to meet the security requirements placed upon it. Chapter.III (Identifying Security Requirements Using the Security Quality Requirements Engineering (SQUARE) Method) by N. R. Mead describes general issues in developing security requirements, methods that have been useful, and emphasize the system quality requirements engineering (SQUARE) method, which was developed by the CERT Program at Carnegie Mellon University’s Software Engineering Institute, that can be used for eliciting, analyzing, and documenting security requirements for software systems. The method provides means for eliciting, categorizing, and prioritizing security requirements for information technology systems and applications. The SQUARE method seeks to build security concepts into the early stages of the development life cycle. The model may also be useful for documenting and analyzing the security aspects of fielded systems and could be used to steer future improvements and modifications to these systems. Chapter.IV (A Social Ontology for Integrating Security and Software Engineering) by E. Yu, L. Liu, and J. Mylopoulos describes the i* agent-oriented modelling framework and how it can be used to treat security as an integral part of software system requirements engineering. The framework offers a set of security requirements analysis facilities to help users, administrators, and designers better understand the various threats and vulnerabilities they face, the countermeasures they can take, and how these can be combined to achieve the desired security results within the broader picture of system design and the business environment. The security analysis process is integrated into the main requirements process, so that security is taken into account from the earliest moment. The technology of smart cards and the environment surrounding its usage provides a good example to illustrate the social ontology of i*. Chapter.V (A Methodology to Develop Secure Systems Using Patterns) by E. B. Fernandez, M. M. Larrondo-Petrie, T. Sorgente, and M. Vanhilst presents a methodology to build secure software for complex applications where patterns are used to help to apply security principles. The methodology considers the whole software lifecycle, uses security patterns, and is applied at all the architectural levels of the system. A main idea is that security principles should be applied at every stage and that each stage can be tested for compliance with security principles. The methodology shows how security patterns can be added to conceptual models in the analysis phase and how these analysis models are converted into design models with the addition of distribution and multiple architectural levels. Two running examples about a financial institution and a hospital are used to illustrate the different aspects of the proposed approach. Chapter.VI.(Modelling Security Patterns Using NFR Analysis) by M. Weiss presents an approach where the main idea is to use non-functional requirements (NFR)

x

analysis to describe both the contributions patterns have on forces, and their design context. The level of structuring provided by NFR analysis can help to represent patterns in a more objective manner, and decide which patterns to apply in a given design context. The chapter describes how security requirements can be represented by this approach, but it also shows how the approach allows developers to consider security in the context of other non-functional requirements such as performance and scalability. Chapter. VII (Extending Security in Agile Software Development Methods) by M. Siponen, R. Baskerville, and T. Kuivalainen analyzes and outlines the requirements for security techniques to integrate seamlessly into agile methods. The analysis is presented through an example of an approach for adding security into agile information systems and software development methods. The chapter shows how this approach also offers a promising solution for adding security in agile information systems and software development, expanding earlier work that adapts it into the phases of agile methods. Chapter. VIII (Modelling Security and Trust with Secure Tropos) by P. Giorgini, H. Mouratidis, and N. Zannone describes how the integration of two prominent software engineering approaches, one that provides a security-oriented process and one that provides a trust management process results in the development of a methodology that considers security and trust issues as part of its development process. Such integration represents an advance over the current state of the art by providing the first effort to consider security and trust issues under a single software engineering methodology. Both approaches are extensions of Tropos, an- agent-oriented software development methodology. A case study from the health care domain is used to illustrate the result of the integration. Chapter.IX (An Integrated Security Verification and Security Solution Design Trade-Off Analysis Approach) by S. H. Houmb, G. Georg, J. Jürjens, and R. France describes a method that integrates security verification and security solution design trade-off analysis techniques. The security verification technique is used to verify that the solution has the required security level. The trade-off analysis technique is used to determine the best of the known solutions. The security requirements are precisely specified using UMLsec, an extension to UML for secure systems development. The security level of a solution can then be verified using UMLsec tool support. To evaluate the security solutions separately, the approach proposes to model them as security aspects using an aspect-oriented modelling (AOM) technique. These aspects are then evaluated and trade-off decisions are made based on computed Return on Security Investment (RoSI) for each security solution. Chapter. X (Access Control Specification in UML) by M. Koch, F. Parisi-Presicce, and K. Pauls discusses a methodology to integrate the specification of access control policies into UML. The methodology, along with the graph-based formal semantics for the UML access control specification, allows to reason about the coherence of the access control specification. The chapter also presents a procedure to modify policy rules to guarantee the satisfaction of constraints, and shows how to generate access control requirements from UML

xi

diagrams. The main concepts in the UML access control specification are illustrated with an example access control model for distributed object systems. Chapter. XI (Security Engineering for Ambient Intelligence: A Manifesto) by A. Mana, C. Rudolph, G. Spanoudakis, V. Lotz, F. Massacci, M. Melideo, and J. S. Lopez-Cobo describes SERENITY, a comprehensive approach to overcome problems related to the design and engineering of secure and dependable systems for Ambient Intelligence applications. The key to success in this scenario is to capture security expertise in such a way that it can be supported by automated means. SERENITY’s integral model of S&D considers both static and dynamic aspects. The combination of these innovations lays the foundations of an integrated, solid, flexible, and practical S&D framework for Ambient Intelligence ecosystems. The chapter aims at clarifying the challenges introduced in ambient intelligence ecosystems and pointing out directions for research in the different areas involved. Finally, Chapter.XII (Integrating Security and Software Engineering: Future Vision and Challenges) by H. Mouratidis and P. Giorgini concludes the book. The chapter lists and discusses nine challenges necessary for the advance of the secure software engineering field. The main idea behind each challenge is presented in a short sentence followed by a discussion which indicates why the challenge is important and in some cases the discussion provides ideas of how the challenge could be met. Paolo Giorgini, Italy Haralambos Mouratidis, UK January 2006

Integrating Security and Software Engineering



Chapter.I

Integrating.Security.and. Software.Engineering:. An.Introduction H. Mouratidis, University of East London, UK P. Giorgini, University of Trento, Italy

ABSTRACT This chapter serves as an introduction to this book. It introduces software engineering, security engineering, and secure software engineering, providing deinitions and explanation of terms necessary for readers to understand the subsequent chapters. Characteristics of each of the above areas are presented followed by an overview of the current advances in these areas. Finally, the 10 approaches described in the remaining chapters of the book are briely introduced.

INTRODUCTION Software systems become more and more critical in every domain of the human society. Transportation, telecommunications, entertainment, health care, military, education, and so on; the list is almost endless. These systems are used not only by major corporations and governments but also by individual users. Such wide use of information systems has resulted in these systems containing a large amount of critical information, which inevitably need to remain secure. Therefore, although it is important to ensure that software systems are developed according to the user Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

needs (functional requirements), it is equally important to ensure that these systems are secure. However, traditionally, security is considered after the deinition of the system, meaning that security mechanisms are itted into pre-existing designs. Usually, in practise, a it-all solution is assumed where security mechanisms, such as authentication, are inserted into the system with very little consideration of the implications of inserting such mechanisms into the existing system’s design. As a result, security may conlict with the system’s requirements and this can lead to problems, which most of the times translate into security vulnerabilities (Anderson, 2001; Stallings, 1999). One of the reasons for this situation is the fact that traditionally the two associated research areas of software engineering and security engineering work independently. On one hand, software engineering techniques and methodologies do not consider security as an important issue, although they have integrated concepts such as reliability and performance, and they usually fail to provide precise enough semantics to support the analysis and design of security requirements and properties (Crook, Ince, & Nuseibeh, 2003; Mouratidis, 2004a). On the other hand, security engineering research has mainly produced formal and theoretical methods, which are dificult to understand by non security experts and which, apart from security, they only consider limited aspects of the system. From the viewpoint of the traditional security paradigm, integrating security and software engineering would result in a situation where security is considered as part of the development process, leading to the development of more secure software systems. We call this area of research secure software engineering, and we consider it a branch of research concerned with the development of secure software systems, which integrates security and software engineering. In the rest of the chapter, the research areas of software and security engineering are introduced and a discussion emphasising the characteristics of the secure software engineering research area is presented. Then the current state of the art on software and security engineering are presented, emphasising the latest approaches to secure software engineering. The chapter concludes by introducing the approaches presented in the rest of the book.

SOFTWARE. ENGINEERING

Trying to explicitly and accurately deine something as wide and dynamic as software engineering is a very dificult task. Therefore, there is a tendency from researchers and practitioners to develop personal deinitions (Pressman, 2005). As a result of this, various different deinitions regarding software engineering appear on texts (see for example Macro & Buxton, 1990; Pressman, 2005; Sommerville, 2004; Vliet, 1993). These deinitions often use different words and different ideas to describe software engineering and range from very simple ones, such as software Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering



engineering is what software engineers do (a phrase that came up sometimes in discussions the author had with different people about software engineering), to very complicated ones. An early deinition about software engineering was given at a NATO conference held in 1968. According to the inal report of this conference (Naur, 1968), “Software engineering is the establishment and use of sound engineering principles in order to obtain economic software that is reliable and works eficiently on real machines.” Extending this deinition, Macro and Buxton (1990) claim “software engineering is the establishment and use of sound engineering principles and good management practice, and the evolution of applicable tools and methods and their use as appropriate, in order to obtain — within known and adequate resource provisions — software that is of high quality in an explicitly deined sense.” Similar to the previous deinitions, the IEEE Standard Glossary of Software Engineering Terminology (IEEE, 1990) deines software engineering as “the application of systematic, disciplined, quantiiable approach to the development operation and maintenance of software; that is the application of engineering to software.” More recently, Sommerville (2004) has deined software engineering as “an engineering principle which is concerned with all aspects of software production from the early stages of system speciication through to maintaining the system after it has gone into use.” All these deinitions, although display many differences, they also display many similarities, with the main similarity being that software engineering is a systematic approach to the development of software systems. To perform a systematic approach to the development of software systems, software developers employ notations and follow structured processes. In other words, they are using methodologies (structure processes) and modelling languages (notations) to analyse and design a software system. Booch (1994) deines a methodology as “a collection of methods applied across the software development life cycle and uniied by some general, philosophical approach.” On the other hand, Russel (2000) notes that a modelling language is effectively a collection of elements that helps to model and document the system. As a result, a modelling language gives the designer the opportunity to develop a system without limiting the creativity with any constraints of a particular programming language. Furthermore, a graphical representation of the system presents a much clearer idea of the system than a programming language. A well-known modelling language is the Uniied Modelling Language (UML) (Fowler & Scott, 2000; OMG, 2003).

SECURITY. ENGINEERING

Physical security systems have been around for many thousands of years, ranging from castle fencing, to window bars and door locks. Computer security, on Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

the other hand, although newer in comparison with physical security is deinitely not a new topic since its history starts in the 1960s (Saltzer & Schroeder, 1975). Nevertheless, it was until the advent of distributed systems and computer networks that security of software systems has become an issue of huge concern. According to Anderson (2001), “security engineering is about building systems to remain dependable in the face of malice, error, or mischance.” Therefore, security of computer based information systems is concerned with methods providing cost effective and operationally effective protection of information systems from undesirable events (Lane, 1985). Security is usually deined in terms of the existence of any of the following properties: • • • • • •

Conidentiality: The property of guaranteeing information is only accessible to authorised entities and inaccessible to others. Authentication: The property of proving the identity of an entity. Integrity: The property of assuring that the information remains unmodiied from source entity to destination entity. Access Control: The property of identifying the access rights an entity has over system resources. Non-repudiation: The property of conirming the involvement of an entity in certain communication. Availability: The property of guaranteeing the accessibility and usability of information and resources to authorised entities.

Failure of any of the previously mentioned security properties might lead to many dangers ranging from inancial losses to sensitive personal information losses. The existence of the above security properties within a system is deined in terms of the security policy. A security policy can be deined as “the set of rules that state which actions are permitted and which actions are prohibited” (Gollmann, 2001). A security policy determines the limits of acceptable behaviour and what the response to violations should be and it might deine possible mechanisms, widely known as security mechanisms, designed to detect, prevent, or recover from a security attack. A security attack is deined (Stallings, 1999) as an action that compromises the security information owned by an organisation. It is well known that perfect security is very hard to achieve and usually the goal is to provide an acceptable security level, usually by trading security requirements with other functional and non-functional requirements of the system-to-be. Due to the attention that the issue of securing information systems has received the last few years and due to the large increase on the number of emerging defence mechanisms deriving from the ongoing research advances, it would be expected that system developers are able to develop and deploy very secure systems. Nevertheless, current surveys indicate that we are far even from developing acceptable secure software systems (CERT, 2003; DTI, 2004). Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering



One of the main reasons for this situation is that many software engineers do not always have a strong background in computer security and lack expertise in secure software system development. Nevertheless, in practice, they are asked to develop software systems that require security features. Without appropriate methodologies and modelling languages to guide them during the development process, it is likely that they will fail to produce effective solutions (McDermott & Fox, 1999).

SECURE. SOFTWARE. ENGINEERING Software engineering considers security requirements as non-functional requirements (Chung & Nixon, 1995). Non-functional requirements introduce quality characteristics, but they also represent constraints under which the system must operate (Roman, 1985; Sommerville, 2004). Although software developers have recognised the need to integrate most of the non-functional requirements, such as reliability and performance, into the software development processes (Dardenne, 1991); security still remains an afterthought. As recent research argues (Giorgini, Massacci, & Mylopoulos, 2003, Mouratidis, Giorgini, & Manson, 2005a; Tryfonas, 1997) modelling languages fail to include specialised handling of security requirements, whereas software engineering methodologies do not create a security control environment early in the development process. In fact, it has remained true over the last 30 years, since the seminal paper by Saltzer (1975), that no coherent and complete methodology to ensure security in the construction of large general-purpose systems exists yet, in spite of a large body of security engineering knowledge accumulated (Anderson, 2001) as well as very active research and many useful results addressing particular subgoals. However, as research (Anderson, 2001; Crook et al., 2003; Devanbu & Stubblebine, 2000; Giorgini et al., 2003; McDermott & Fox, 1999; Mouratidis, 2004a; Mouratidis, Giorgini, & Manson, 2005a) indicates, security should be considered from the early stages of the development process and security requirements should be deined alongside with the system’s requirements speciication. Taking security into account alongside the functional requirements throughout the development stages helps to limit the cases of security/functional requirements conlict by avoiding them from the very beginning or by isolating them very early in the development process. On the contrary, adding security concerns as an afterthought increases the chances of conlicts. A solution to this kind of problem requires a deep study of the system, its organization, and its properties. Thus, a considerable amount of money and valuable time is needed and, most of the time, a major rebuild of the system becomes necessary. To adequately consider security issues during the software development life cycle, security should be integrated within software engineering languages, methods, methodologies, and processes. We call this area of research secure software engineering, and we consider it a branch of research investigating the integration of Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

security concerns into software engineering practices, which draws expertise from the security and the software engineering community. We think of secure software engineering as the umbrella term under which the areas of (among others) security requirements engineering (Alexander, 2003; Crook et al., 2003; Haley, Moffett, Laney, & Nuseibeh, 2005) security modelling (Giorgini et al., 2003; Jürjens, 2004; Lodderstedt, Basin, & Doser, 2002; Mouratidis et al., 2003; Mouratidis, Kolp, Faulkner, & Giorgini, 2005b) and secure software development (Fernandez, 2004; Mouratidis et al., 2005a) lie. Therefore, the main aim of such research area is the production of novel techniques, methods, processes and tools which will integrate security and software engineering principles, to enable software developers to analyse, design, implement, test, and deploy secure software systems. The develoment of such techniques should be based on research provided by the security engineering research community, such as attack testing, secure design principles and security ontologies, complimented by research provided by the software engineering community, such as requirements engineering techniques, software development methodologies and modelling languages, and testing. Such interconnection will provide various advantages. It will allow the development of improved security related techniques within structured and well deined methodological frameworks. Moreover, it will provide the ground for a sound and complete security related ontology that will enable developers to consider not just the technical challenges introduced by securing information systems, but also the social implications that arise.

STATE. OF. THE.ART Security.Engineering Initial efforts to include security issues in the development of software systems have been produced by the security engineering research community. Schneier (2000) describes attack trees as a useful way to identify and organise different attacks in an information system. According to Scheneir, attack trees represent a set of intrusion scenarios and allow the reinement of attacks to a level of detail chosen by the developers. Viega and McGraw (2001) proposed 10 principles for building secure software. They argued “the goal of these principles is to identify and to highlight the most important objectives you should keep in mind when designing and building a common security problem.” On the other hand, a large amount of work has been devoted to security policies and the deinition of security models. Various models1 have been proposed based on mandatory access control (MAC), discretionary access control (DAC) and role base access control (RBCA). One of the irst models was the Bell & Lapadula multilevel security model (Bell & Lapadula, 1976). In this model, subjects (active entities) are assigned clearance, whereas objects (passive entities) are assigned clasCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering



siications indicating their security level. Another well known model is the Chinese Wall model (Brewer & Nash, 1989), according to which data is organised into three different levels. At the lowest level, we consider individual items of information, called objects, each concerning a single corporation; at the intermediate level, groups of objects, called dataset, which concern the same corporation are considered; at the highest level, all company datasets whose corporations are in competition are grouped together. Each such group is known as a conlict of interest (COI) class. Such models have been followed by many researchers leading to a wide and thorough understanding of the technical aspects of security. The deinition of security ontology is also an important area of research within the security engineering community. Initial efforts to deine a widely accepted security ontology resulted in what is known as the Orange Book (U.S. Department of Defense Standard DOD 5200.58-STD). However, work towards this standard started in the late 1960s and it concluded in the late 1970s. Therefore important issues, raised by the introduction of the Internet and the usage of information systems to almost every aspect of our lives, are missing from the standard. More recently Kagal and Finin (2005) have developed an ontology expressed in DAML+OIL to represent security information, trust and policies in multi-agent systems, whereas Undercoffer and Pinkston (2002) after analysing over 4000 computer vulnerabilities and the corresponding attack strategies employed to exploit them have produced an ontology for specifying a model of computer attacks. Moreover, the Foundation for Intelligent Physical Agents (FIPA) has launched a technical committee for developing security ontology for multi-agent multi-domain systems. Although important and useful in many situations, the work that has surfaced by the security engineering community has a number of important limitations with respect to the integration to software engineering practice. First, it mainly considers the later stages of the software development process. As it was argued in the previous section, it is important that security is considered from the early stages of the development process. Moreover, existing work is mainly focused on the technological aspects of security and it ignores, in general, the social dimension of security. As it was argued previously, it is important that security is considered within the social context and any social issues, such as trust and the involvement of humans, are taken into account.

Software.Engineering In the software engineering literature, initial work produced a number of methods and processes for reasoning about non-functional requirements, including security. Chung applies a process-oriented approach (Chung & Nixon, 1995) to represent security requirements as potentially conlicting or harmonious goals and using them during the development of software systems. The proposed framework, called the NFR (non-functional requirements) framework, represents, and uses security requirements as a class of non-functional requirements and it allows developers to Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

consider design decisions and relate these decisions to the represented non-functional requirements. Similarly, Yu and Cysneiros (2002) provide an approach to model and reason about non-functional requirements (with emphasis on privacy and security). They are using the concept of a soft-goal to assess different design alternatives, and how each of these alternatives would contribute positively or negatively in achieving the soft-goal. Anton and Earp (2004), propose a set of general taxonomies for security and privacy, to be used as a general knowledge repository for a (security) goal reinement process. Moreover, the last few years a considerable number of researches have been emerged from the software engineering community that are focused on security. Schumacher and Roedig (2001) apply the pattern approach to the security problem by proposing a set of patterns, called security patterns, which contribute to the overall process of secure software engineering. As they argue, security patterns help security novices to act as security experts, and allow security problems to be solved in a structured way. Similarly, Fernandez (2001) speciies security models as object oriented patterns that can be used as guidelines for the development of secure information systems. Fernandez’s pattern language contains the Authorisation pattern, which describe access control for resources, the RBCA pattern, which is an extension of the authorisation pattern, and the multilevel security pattern. In addition, Levanhar (2005) has proposed the comprehensive, lightweight application security process (CLASP) approach to security requirements engineering. CLASP is a life-cycle process that suggests a number of different activities across the development life cycle in order to improve security. Although useful, these approaches lack the deinition of a structured process for considering security. A well deined and structured process is of paramount importance when considering security during the development. On the other hand, a number of researchers model security by taking into account the behaviour of potential attackers. Van Lamsweerde and Letier (2000) use the concept of security goals and anti-goals. Anti goals represent malicious obstacles set up by attackers to threaten the security goals of a system. Two set of techniques, based on a temporal logic formalisation, are employed to reason about obstacles to the satisfaction of goals, requirements, and assumptions elaborated in the requirements engineering process. Similarly, Crook et al. (2003) introduce the notion of anti-requirements to represent the requirements of malicious attackers. Anti-requirements are expressed in terms of the problem domain phenomena and are satisied when the security threats imposed by the attacker are realised in any one instance of the problem. Lin, Nuseibeh, Ince, Jackson, and Moffett (2003), incorporate anti-requirements into abuse frames. The purpose of abuse frames is to represent security threats and to facilitate the analysis of the conditions in the system in which a security violation occurs. An important limitation of all these approaches is that security is considered as a vague goal to be satisied whereas a precise description and enumeration of speciic security properties is still missing. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering



Differently, another “school of thinking” indicates the development of methods to analyse and reason about security based on the relationships between actors (such as users, stakeholders, and attackers) and the system. Liu, Yu, and Mylopoulos (2003) have presented work to identify security requirements during the development of multi-agent systems. In this work, security requirements are analysed as relationships amongst strategic actors, such as users, stakeholders, and potential attackers. Liu proposes three different kinds of analysis techniques: agent oriented, goal oriented and scenario based analysis. Agent oriented analysis is used to model potential threats and security measures, whereas goal oriented analysis is employed for the development of a catalogue to help towards the identiication of the different security relationships on the system. Finally, the scenario-based analysis is considered an elaboration of the other two kinds of analysis. Moreover, secure Tropos (Mouratidis, 2004a) has been proposed to deal with the modelling and reasoning of security requirements and their transformation to design that satisies them. Secure Tropos, is an extension of the Tropos methodology (Bresciani, Giorgini, Giunchiglia, Mylopoulos, & Perini, 2004) and it is based on the concept of security constraint (Mouratidis, 2004a; Mouratidis, 2005a) to analyse the security requirements of an information system. To compliment the development process, security attack scenarios (2004b) and a security patterns language (2005c) have been developed. Giorgini et al. (2003) have introduced an enhancement of Tropos that is based on the clear separation of roles in a dependency relation between those offering a service (the merchant processing a credit card number), those requesting the service (the bank debiting the payment), and those owning the very same data (the cardholder). Moreover, Giorgini et al. (2004) have proposed a PKI/trust management requirements’ speciication and analysis framework based on the clear separation of trust and delegation relationship. This distinction makes possible to capture the high-level security requirements without being immediately bogged down into considerations about cryptographic algorithms or security implementation. Although a relationship based analysis is suitable for reasoning about security, an important limitation of these approaches is that either they focus on some development stages more than others (such as the secure Tropos approach) or they only guide the way security can be handled within a certain stage of the software development process (such as the work by Liu et al. and Giorgini et al.). Another direction of work is based on the extension of use cases and the Uniied Modelling Language (UML). In particular, McDermott and Fox (1999) adapt use cases to capture and analyse security requirements, and they call the adaption an abuse case model. An abuse case is deined as a speciication of a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders of the system. Similarly, Sindre and Opdahl (2005) deine the concept of misuse case, the inverse of use case, which describes a function that the system should not allow. They also deine the concept of mis-actor as someone who intentionally or Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Mouratidis & Giorgini

accidentally initiates a misuse case and whom the system should not support in doing so. Alexander (2003) adds Threatens, Mitigates, Aggravates links to the use case diagram. Jurgens proposes UMLsec (Jürjens, 2002; Jürjens 2004), an extension of the Uniied Modelling Language (UML), to include the modelling of security related features, such as conidentiality and access control. In his work, Jurgens uses four different UML diagrams; class diagrams to ensure that exchange of data obeys security levels, state-chart diagrams to prevent indirect information low from high to low values within an object, interaction diagrams to ensure correctness of security critical interactions between objects and deployment diagrams to ensure that security requirements on communication are met by the physical layer. Lodderstedt et al. (2002) also extend UML to model security. In their work, they present a security modelling language called SecureUML. They describe how UML can be used to specify information related to access control in the overall design of an application and how this information can be used to automatically generate complete access control infrastructures. In their approach, security is considered by analysing security related misuse cases. An important limitation of all the use-case/UML related approaches, is that they do not support the modelling and analysis of security requirements at a social level but they treat security in system-oriented terms. In other words, they lack models that focus on high-level security requirements, meaning models that do not force the designer to immediately go down to security requirements.

INTRODUCING. THE. REST. OF. THE. CHAPTERS

The research approaches presented in this book provide a mixture of work. The irst three approaches, which can be categorised under the security requirements engineering heading, describe a process for security requirements elicitation and analysis, a method for identifying and documenting security requirements, and a social ontology for integrating security and software engineering. The next two chapters describe approaches, which use patterns for modelling and developing secure software systems. The last group of approaches describe modelling languages and methodologies for secure software development.

REFERENCES

Alexander, I. (2003). Misuse cases: Use cases with hostile intent. IEEE Software, 20, 58-66. Anderson, R. (2001). Security engineering: A guide to building dependable distributed systems. Wiley Computer Publishing.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering



Anton, A. I., & Earp, J. B. (2004). A requirements taxonomy for reducing Web site privacy vulnerabilities. Requirements Engineering, 9(3), 169-185. Bell, D. E., & LaPadula, L. J. (1976). Secure computer systems: Mathematical foundations and model. The Mitre Corporation. Booch, G. (1994). Object-oriented analysis and design with applications. The Benjamin/Cummings Publishing Company. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J., & Perin, A. (2004). TROPOS: An agent-oriented software development methodology. Journal of Autonomous Agents and Multi-Agent Systems, 8(3), 203-236. Brewer, D. F. C., & Nash M. J. (1989, May 1-3). The Chinese Wall security policy. Proceedings of the IEEE Symposium on Research in Security and Privacy (pp. 206-214). Oakland, California. pp 206-14) CERT Coordination Centre. (2003). Annual Report. Retrieved from www.cert.org Chung, L., & Nixon, B. (1995). Dealing with non-functional requirements: Three experimental studies of a process-oriented approach. Proceedings of the 17th International Conference on Software Engineering, Seattle, USA. Crook, R., Ince, D., & Nuseibeh, B. (2003). Modelling access policies using roles in requirements engineering. Information and Software Technology, 45(14), 979-991, Devanbu, P., & Stubblebine, S. (2000). Software engineering for security: A roadmap. Proceedings of the 22nd International Conference on Software Engineering. Track on the Future of Software Engineering, Limerick, Ireland. DTI, Information Security Breaches Survey. (2004). Technical Report. Retrieved from www.dti.gov.uk Fernandez, E. B. (2004, June 21-24). A methodology for secure software design. Proceedings of the 2004 International Conference on Software Engineering Research and Practice (SERP’04), Las Vegas, NV. Fernandez, E. B., & Pan, R. (2001, September). A pattern language for security models. Proceedings of the 8th Conference on Pattern Languages of Programs (PLoP 2001), Monticello, IL. Fowler, M., & Scott, K. (2000). UML distilled: A brief guide to the standard object modelling language (2nd ed.). Addison-Wesley Giorgini, P., Massacci, F., & Mylopoulos, J. (2003). Requirements engineering meets security: A case study on modelling secure electronic transactions by VISA and Mastercard. Proceedings of the International Conference on Conceptual Modelling (ER) (pp. 263-276). LNCS 2813, Springer-Verlag. Giorgini, P., Massacci, F., Mylopoulos, J., & Zannone, N. (2004, June 25-26). Filling the gap between requirements engineering and public key / trust management infrastructures. In K. Sokratis, S. Katsikas, & J. L. Gritzalis (Eds.), Public Key Infrastructure, Proceedings of the 1st European PKIWorkshop: Research and Applications, EuroPKI 2004, Samos Island, Greece. LNCS 3093. Springer. Gollmann, D. (2001). Computer security. John Wiley & Sons. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

Haley, C. B., Moffett, J. D., Laney, R., & Nuseibeh, B. (2005). Arguing security: Validating security requirements using structured argumentation. Proceedings of the 3rd Symposium on Requirements Engineering for Information Security (SREIS’05) held in conjunction with the 13th International Requirements Engineering Conference (RE’05). Paris. IEEE Standard Glossary of Software Engineering Terminology. (1990). IEEE Std 729. Jürjens, J., (2004). Secure system development with UML. Springer-Verlag. Jürjens, J. (2002). UMLsec: Extending UML for secure systems development. UML 2002, Lecture Notes in Computer Science 2460 (pp. 412-425). Kagal, L., & Finin, T. (2005, January). Modelling conversation policies using permissions and obligations. In F. Dignum, R. van Eijk, & M. Huget (Eds.), Developments in Agent Communication (Post-proceedings of the AAMAS Workshop on Agent Communication). LNCS. Springer-Verlag. Lane, V. P. (1985). Security of computer based information systems. Macmillan Education Ltd. Levanhar, S. (2005). Comprehensive Lightweight Application Security Process (CLASP). Retrieved December 20, 2005, from https://buildsecuriyin.us-cert. gov/portal/article/bestpractices/requirements_engineering/CLASP.xml Lin, L. C., Nuseibeh, B., Ince, D., Jackson, M., & Moffett, J. (2003). Analysing security threats and vulnerabilities using abuse frames. Technical Report 2003/10, The Open University. Liu, L., Yu, E., & Mylopoulos, J. (2003). Security and privacy requirements analysis within a social setting. Proceedings of the 11th International Requirements Engineering Conference (pp. 151-161). IEEE Press. Lodderstedt, T., Basin, D., & Doser, J. (2002). SecureUML: A UML-based modelling language for model-driven security. Proceedings of the UML’02 (pp. 426-441). LNCS 2460. Springer-Verlag. Macro, A., & Buxton, J. (1990). The craft of software engineering. International Computer Science Series. Addison-Wesley. McDermott, J., & Fox, C. (1999). Using abuse care models for security requirements analysis. Proceedings of the 15th Annual Computer Security Applications Conference. Mouratidis, H. (2004a). A security oriented approach in the development of multiagent systems: Applied to the management of the health and social care needs of older people in England. PhD thesis, University of Shefield. Mouratidis, H., Giorgini, P., & Manson, G. (2003). Modelling secure multiagent systems. Proceedings of the 2nd International Joint Conference on Autonomous Agents and Multiagent Systems (pp. 859-866). ACM. Mouratidis, H., Giorgini, P., & Manson, G. (2004b, April). Using security attack scenarios to analyse security during information systems design. Proceedings

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering



of the International Conference on Enterprise Information Systems (ICEIS 2004) (pp. 10-17). Porto-Portugal Mouratidis, H., Giorgini P., & Manson, G. (2005a). When security meets software engineering: A case of modelling secure information systems. Information Systems, 30(8), 609-629. Mouratidis, H., Kolp, M., Faulkner, S., & Giorgini, P. (2005b). A secure architectural description language for agent systems. Proceedings of the 4th International Joint Conference on Autonomous Agents and Multiagent Systems (pp. 578585). Utrecht, The Netherlands: ACM. Mouratidis, H., Weiss, M., & Giorgini, P. (2005c). Security patterns meet agent oriented software engineering: A complementary solution for developing security information systems. Proceedings of the 24th International Conference on Conceptual Modelling (ER) (pp. 225-240). Lecture Notes in Computer Science 3716. Springer-Verlag. Naur, P., & Randell, B. (1968). Software engineering: Reports on a conference. Garmisch, NATO Scientiic Affairs Division. OMG. (2003). UML 2.0 Speciication. Pressman, R. S. (2005). Software engineering: A practitioner’s approach (6th ed.). McGraw Hill. Roman, G. C. (1985, April). A taxonomy of current issues in requirements engineering. IEEE Computer, 18(4), 14-23. Russel, D. J. (2000). FAD: A Functional Analysis and Design methodology. PhD Thesis, The University of Kent at Canterbury. Saltzer, J., & Schroeder, M. D. (1975, September). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278-1308. Schneier, B. (2000). Secrets & lies: Digital security in a networked world. John Wiley & Sons. Schumacher, M., & Roedig, U. (2001). Security engineering with patterns. Proceedings of the 8th Conference on Pattern Languages for Programs (PLoP), IL. Sindre, G., & Opdahl, A. L. (2005). Eliciting security requirements with misuse cases. Requirements Engineering, 10(1), 34-44. Sommerville, I. (2004). Software engineering (7th ed.). Pearson-Education. Stallings, W. (1999). Cryptography and network security: Principles and practice (2nd ed.). Prentice-Hall. Undercoffer, J., & Pinkston, J. (2002). Modelling computer attacks: A target-centric ontology for intrusion-detection. Proceedings of the CADIP research symposium. Retrieved from http://www.cs.umbc.edu/cadip/2002Symposium Van Lamsweerde, A., & Letier, E. (2000). Handling obstacles in goal-oriented requirements engineering. Transactions of Software Engineering, 26(10), 978-1005. Viega, J., & McGraw, G. (2001). Building secure software. Addison Wesley

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

Vliet H. V. (1993). Software engineering: Principles and practice. John Wiley & Sons. Yu, E., & Cysneiros, L. (2002, November 15-16). Designing for privacy and other competing requirements. The 2nd Symposium on Requirements Engineering for Information Security (SREIS’ 02), Raleigh, NC.

1

ENDNOTE

An extensive presentation and discussion of these models are out of the scope of this chapter and this book.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering



Section.I Security.Requirements. Engineering

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

Chapter.II

Arguing.Satisfaction.of. Security.Requirements C. B. Haley, The Open University, UK R. Laney, The Open University, UK J. D. Moffett, The Open University, UK B. Nuseibeh, The Open University, UK

ABSTRACT This chapter presents a process for security requirements elicitation and analysis, based around the construction of a satisfaction argument for the security of a system. The process starts with the enumeration of security goals based on assets in the system, then uses these goals to derive security requirements in the form of constraints. Next, a satisfaction argument for the system is constructed, using a problem-centered representation, a formal proof to analyze properties that can be demonstrated, and structured informal argumentation of the assumptions exposed during construction of the argument. Constructing the satisfaction argument can expose missing and inconsistent assumptions about system context and behavior that effect security, and a completed argument provides assurances that a system can respect its security requirements.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



INTRODUCTION This chapter describes an approach to carry out security requirements engineering; the process of eliciting, specifying, and analyzing the security requirements for a system. The approach is founded on the following fundamental ideas: • • • •

The “what” of security requirements — its core artifacts — must be understood before the “how” of their construction and analysis. Security cannot be considered as a feature of software alone; it is concerned with the prevention of harm in the real world. We must therefore consider both the security requirements of real-world systems and the speciication of software that demonstrably meets those requirements. Since security is largely concerned with prevention of misuse of system functions, security requirements can most usefully be deined by considering them as constraints upon functional requirements. Since security is by deinition an “open world” problem (the domain of analysis will always be too small), any argument that a system will satisfy its security requirements must take non-provable assertions about the real world into account.

The contribution of this chapter is the combination of four components described in previous work into a coherent security requirements process. The irst component is a framework that provides a systematic statement of the roles and relationships of security goals, security requirements, and security functions, and their relationships with other system and software requirements. The second is a way of describing threats and their interactions with the system. The third is a precise deinition of security requirements. The fourth is a two-layer set of arguments to assist with validating the security requirements within the context of the system, to determine that the system is able to meet the security requirements placed upon it. The irst and third were described in Moffett, Haley, and Nuseibeh (2004), the second in Haley, Laney, and Nuseibeh (2004), and the fourth in Haley, Moffett, Laney, and Nuseibeh (2005). Although all the steps in the process are described in this chapter, the third component — argumentation — is emphasized. This is not an exclusive focus, though, as understanding the role of argumentation in security requirements requires that one understand the irst three parts of the process in order to place the pieces correctly in context. The next section discusses the security requirements process, while the following section provides information about argumentation driven problem analysis. The two subsequent sections present the major steps of the process and illustrate it with the aid of a case study. The following section discusses the proposed approach and the section after introduces related work. The inal section concludes the chapter.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

THE. SECURITY. REQUIREMENTS. PROCESS

The process uses the framework described in Moffett et al. (2004), which enables an understanding of the role of requirements analysis in the validation and veriication of security requirements and the other artifacts in the framework. The framework integrates the concepts of the two disciplines of requirements engineering and security engineering. From requirements engineering it takes the concept of functional goals, which are operationalized into functional requirements, with appropriate constraints. From security engineering it takes the concept of assets, together with threats of harm to those assets. In the framework: • • • •

Security goals aim to protect assets from security threats. Security goals are operationalized into primary security requirements, which take the form of (a subset of) the constraints on the functional requirements. Primary security requirements are realized by requirements on the behavior of relevant domains, and in particular the domain of software. Feasible realizations of the primary security requirements lead to the need for secondary security requirements, which are additional required functions or constraints.

The framework has been developed in order to understand the place of security requirements within the development of an individual application, and our proposals are limited by that scope. The application will, of course, be developed in the context of a software operating environment, a hardware environment, and a human cultural environment. All of these environments will have properties, which impact upon the application.

The Need for Deined Security Requirements

Consider Anderson’s report (Anderson, 1996), which presents a view of the security goals of a hospital clinical information system from the point of view of the doctors. It makes explicit assumptions that the doctors should have control of the system, while the administrators should be subordinate. In reality, in many health services, there is a power struggle between doctors and administrators. In a hypothetical system in which that power struggle has not been resolved, we can consider two possible sets of candidate security requirements. In set one, proposed by the doctors, some actions are considered legitimate for doctors, but prohibited for administrators. In set two, proposed by the administrators, the situation is reversed. However, the system’s requirements in this instance must be free of conlicts, because if not, the implementers may resolve the conlicts in potentially inconsistent and incorrect ways. The conlict between rival stakeholders must be resolved by the production of an agreed set of security requirements. Only then can we analyze the requirements for misuses or abuses.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



Deinition of Security.Requirements

We deine the primary.security.requirements of a system as constraints on the functions of the system: the security goals are operationalized as constraints on the system’s functional requirements: • •

They are constraints on the system’s functional requirements, rather than themselves being functional requirements. They express the system’s security goals in operational terms, precise enough to be given to a designer.

Secondary.security.requirements are additional required functions or constraints that are derived in the course of requirements analysis or system design, in order to enable feasible realizations of the primary security requirements It is worth noting that we do not claim to be correct in deining primary security requirements as constraints on functional requirements, simply that it is useful to do so. We can be pragmatic in this way because: • •

Requirements speciications, in general, describe the functions (or operations or services) to be provided by a system. It is clearly desirable for the speciication to describe security requirements in a way that enables them immediately to be related to the functions.

It is important to reiterate that security requirements (constraints) are expressed in terms of the system context, which is larger than the software. A constraint on a function can be realized in multiple ways, some completely outside the software to be constructed. We use a variant of Jackson’s problem frames (Jackson, 2001) to represent the system context. The reader will ind further detail in the section Problem Frames later in this chapter.

Validation.by.Argumentation One key validation step for the process described in this chapter is the ability to show that the system can satisfy the security requirements. We propose the use of structured informal and formal argumentation for this validation step: to convince a reader that a system can satisfy the security requirements laid upon it. These arguments, called satisfaction arguments, are in two parts. The irst part consists of a formal argument to prove a system can satisfy its security requirements, drawing upon claims about a system, and assuming the claims are accepted. The second part consists of structured informal arguments to support the claims about system behavior and characteristics that were made in the irst argument. Building on our understanding of security requirements, two-step satisfaction arguments assist with determining security — relevant system properties, and how inconsistent and implausible assumptions about them affect the security of a system. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Haley, Laney, Moffett, & Nuseibeh

The.Resulting.Artifacts We assume that the system development process has recognizable stages, each of which produces artifacts that are successively closer representations of a working system. These are core artifacts. They are ordered in an abstraction hierarchy, progressing from the most abstract to the inal concrete working system. At early stages, core artifacts are typically documents or prototypes. The inal core artifact is the working system itself, consisting of a combination of physical and software items. There are two sets of core artifacts in which we have most interest. On the mainstream requirements engineering side, we ind goals, requirements, and the system (not software) architecture. On the security engineering side, we ind assets, threats and control principles. Support artifacts are artifacts that help to develop, analyze, or justify the design of a core artifact. They may represent formal analysis, informal argument, calculation, example or counter-example, etc. They are the by-products of processes whose aim is to help produce veriied and valid core artifacts: either constructive processes which help create them, or analytical processes which test them, both internally (veriied) and in relation to their senior artifacts in the hierarchy (valid). Dependencies between artifacts. In a hierarchy of artifacts, there are dependencies between artifacts. For example, an operationalized requirement is dependent upon a higher-level goal from which it has been derived, because alteration of the goal may cause alteration of the requirement. We will call this kind of dependency hierarchical dependency. There is also a reverse kind of dependency: feasibility. If it proves impossible to implement a system that completely satisies a requirements speciication, then this will force a change in the goals or requirements. The higher-level artifact is dependent on the feasibility of the artifacts below it in the hierarchy. The dependency relationships have an important implication for the structure of development processes: if an artifact is dependent upon the implementation of another artifact for its feasibility, then if the implementation is not feasible, there must be an iteration path in the process, back to the ancestor from its descendant.

ARGUMENTATION. DRIVEN. PROBLEM.ANALYSIS

We use Zave and Jackson’s approach to problem analysis (Jackson, 2001; Zave & Jackson, 1997). They argue that one should construct a correctness argument for a system, where the argument is based on known and desired properties of the domains involved in the problem. To quote Jackson, “Your [correctness] argument must convince yourself and your customer that your proposed machine will ensure that the requirement is satisied in the problem domain.” Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



This section summarizes our approach to problem analysis using problem frames, and describes the two types of arguments. We begin with a short presentation of problem frames.

Problem.Frames

The view of requirements exempliied by problem frames (Jackson, 2001) is that a system is intended to solve a problem in a context of real-world physical domains, where the context includes system design decisions. One uses problem frames to analyze the problem in terms of the context and the design decisions the context represents. The context contains domains, which are physical elements around which the system (not just the software) will be built. The problem frames approach differs from some other approaches (e.g., KAOS, van Lamsweerde, 2001) that hold that a requirements engineer should reason about a system’s characteristics without using a physical model of the world; under this view, a requirements engineer enumerates goals for a system under consideration and produces a temporal logic model of the system’s desired behavior. We will show how using the real-world system perspective provided by problem frames assists with the determination of security requirements. In the problem frames universe, all computing problems involve the interaction between domains in the world. Domains are tangible (e.g., people, equipment, networks) but may contain intangibles (e.g., information). Every domain has interfaces to other domains, which are deined by the phenomena visible between the domains on the interfaces. Descriptions of phenomena controlled by given (existing) domains are indicative; they are “objectively true” (Jackson, 2001), meaning the phenomena and resulting behavior can be observed. Descriptions of phenomena of designed domains (domains to be built as part of the solution) are optative; one hopes to observe the phenomena in the future. Problems are described using a straightforward graphical notation. Domains are boxes, interfaces are arrows, and phenomena are described by indicated by a label on an interface. Figure 1 shows a problem diagram for a simple alarm system. It has one requirement: sound an alarm for 30 seconds when a person enters the room under protection. One special domain is the machine, the domain that performs the transformations to satisfy the requirement. The machine is indicated by two vertical lines in the domain box. The interplay of phenomena between the machine and its connected domains deines what the machine has to work with to satisfy the requirement. The interplay of phenomena is a speciication, describing how the requirements are satisied (Zave & Jackson, 1997). The difference between speciication and requirement is important. A speciication is an expression of the behavior of phenomena visible at the boundary of the domains, whereas a requirement is a description of the problem to be solved. For example, in the context of a building we might ind the requirements “permit passage from one room to another” and “physically separate Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

Figure 1. Example problem diagram Alarm Siren (Causal domain, e.g. a device) C

a

e Machine (the domain that causes the requirements to be satisfied)

Phenomena Label

Sound alarm for 0 seconds when person enters room

d

b

c

Motion Sensor C a: AS!alarm sounds b: P!enters_in_range_of_sensor c: PE!presentInfraredSignature

Person (Biddable domain: one that can be asked to perform actions, not is not required to.) B d: MS!objectDetected e: MA!turnOnAlarm MA!turnOffAlarm

rooms when possible.” Clearly, the problem involves something like doors. Equally as clearly, it does not specify that doors be used, nor does it specify internal phenomena or behavior. It is up to the designer (the architect in this case) to choose the “door” domain(s) for the system. One might satisfy the requirement with a blanket, an automatic door, a futuristic iris, or a garden maze. Each domain implementation presents different phenomena at its boundaries (i.e., they work differently), and the resulting system speciication must consider these differences. However, the requirement does not change. There are two fundamental diagram types in a problem frames analysis, context diagrams and problem diagrams. A context diagram shows the domains of interest in a system, how the domains are interconnected, and optionally the phenomena on the interfaces between domains. A problem diagram is used to describe a problem in the system; the problem is expressed by a requirement. The problem diagram, of which Figure 1 is an example, is a projection of the context, showing only the domains or groups of domains of interest to the particular problem. The diagram shows the domains involved and the phenomena exchanged between the domains. It shows the requirement (the function), the constrained domain(s), the inputs, and the phenomena shared between the domains: the domains that are involved in the system within which the machine operates to realize the necessary function. The behavior of the system is speciied by the sequencing and interplay of phenomena between the domains. Behavior is used to construct the correctness argument by making claims about the behavior. To ground the idea of “claim” in Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



Jackson’s problem analysis, system requirements are optative statements, or statements about what we wish to be true, about the behavior of a system, and therefore are claims about future system behavior that should be argued (and in fact, this is what correctness arguments do). For example, the optative statement “the system shall do X” states a claim that under the conditions described in the problem, the system will do X. The correctness argument establishes the validity of this claim. A similar situation exists with regard to security requirements and correctness arguments. Two signiicant distinctions must be made, however. The irst is that it is very dificult to talk about correctness when discussing security. One can convince the reader that the proposed system meets the needs, but it is far more dificult to prove that the system is correct. The distinction between convince and prove (or show) is important. It is not possible to prove the negative — that violation of security goals do not exist — but one can be convincing that suficient outcomes have been addressed. We propose using argumentation to this end: to convince a reader that the security requirements can be satisied.

Trust.Assumptions.and.Arguments Our earlier work extended the problem frames approach with trust assumptions (Haley, Laney, Moffett, & Nuseibeh, 2004), which are claims about the behavior or the membership of domains included in the system, where the claims are made in order to satisfy a security requirement. These claims represent an analyst’s trust that domains behave as described. Trust assumptions are in the end the analyst’s opinion, and therefore assumed to be true. Said another way, trust assumptions are unsubstantiated claims used in security satisfaction arguments. Any form of security argument must satisfy two goals: (1) that given a collection of domain properties and trust assumptions, one can show that a system can be secure, and (2) to create a uniform structure for the satisfaction argument so that the trust assumptions are made explicit. We satisfy these goals by splitting the satisfaction argument into two parts: a formal outer argument that is irst constructed, and informal structured inner arguments that are constructed to support the outer argument. The inner argument makes extensive use of trust assumptions.

The.Outer.Argument

The formal outer argument uses claims about the behavior of the system (interplay of phenomena) to demonstrate that the security requirement (the constraint) is satisied. It is expressed using an appropriate logic, where the premises are formed from domain behavior properties and the conclusion is the satisfaction of the security requirement. For simplicity, we use propositional logic in this chapter, resulting in the outer argument being a proof of the form: (domain property premises) ├─ security requirement

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

.The.Inner.Arguments The inner argument is a set of informal arguments to recursively support the claims used in the outer argument. We propose a form inspired by the work of Toulmin (1958), one of the earliest advocates and developers of a formal structure for human reasoning. Toulmin style arguments appear to be well suited for our purpose, since they facilitate the capture of relationships between domain properties (grounds in the formal argument), the trust assumptions that eventually support these grounds, and reasons why the argument may not be valid. Toulmin et al. (1979) describe arguments as consisting of: 1. 2. 3. 4. 5. 6.

Claims, specifying the end point of the argument — what one wishes to convince the world of. Grounds, providing any underlying support for the argument, such as evidence, facts, common knowledge, etc. Warrants, connecting and establishing relevancy between the grounds and the claims. A warrant explains how the grounds are related to the claim, not the validity of the grounds themselves. Backing, establishing that the warrants are themselves trustworthy. These are, in effect, grounds for believing the warrants. Modal qualiiers, establishing within the context of the argument the reliability or strength of the connections between warrants, grounds, and claims. Rebuttals, describing what might invalidate any of the grounds, warrants, or backing, thus invalidating the support for the claim.

Toulmin et al. (1979) summarize the above six items as follows: “The claims involved in real-life arguments are, accordingly, well founded only if suficient grounds of an appropriate and relevant kind can be offered in their support. These grounds must be connected to the claims by reliable, applicable, warrants, which are capable in turn of being justiied by appeal to suficient backing of the relevant kind. And the entire structure of argument put together out of these elements must be capable of being recognized as having this or that kind and degree of certainty or probability as being dependent for its reliability on the absence of certain particular extraordinary, exceptional, or otherwise rebutting circumstances.” They propose a diagram for arguments that indicates how the parts it together (see Figure 2). Newman and Marshall (1991) show that the ‘pure’Toulmin form suffers because the fundamental recursive nature of the argument is obscured. Grounds may need to be argued, making them claims. Warrants may need to be argued, which is the reason for the existence of the backing, but it is not clear how the backing differs from grounds in a normal argument. We agree, and extend Toulmin arguments to make the recursive properties of arguments and the relationships between grounds, warrants, and claims explicit, while keeping the basic connections between the components that Toulmin proposed. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



Figure 2. Generic Toulmin-form argument Backing

Warrants

Grounds

Modal Qualifier

Claim

Rebuttal

We propose a simple language to represent the structure of these extended Toulmin arguments. The language, with a syntax formally deined by an LR(1) grammar, captures the essence of Toulmin arguments while facilitating recursion and sub-arguments. We chose a textual language because (a) textual utterances are easier to manipulate than tree diagrams, (b) trees are easily generated from the parser’s abstract syntax tree, and (c) a “compiler” can assist in dynamic browsing of arguments. Further discussion of the use of the language can be found in the case study.

FROM. SECURITY. GOALS. TO. SECURITY. REQUIREMENTS

This section presents the three major steps of our process: identiication of security goals, identiication of security requirements, and construction of satisfaction arguments.

Process.Overview Our process for moving from security goals to security arguments is shown as Figure 3. There are two columns in the igure, corresponding to the “normal” application development process and quality goals, and the development of security requirements. It is assumed that no explicit activity is needed to elicit the organization’s control principles, and these can therefore be fed directly into the Identiication of Security Goals activity. Lines coming out of the bottom of an activity box indicate the successful completion of an activity and carry with them a core artifact into the next activity. Lines coming out of the side of an activity box denote failure and imply the need to iterate back up the process in order to revise an earlier activity. Failure can be Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

Figure 3. Security requirements process overview (Activity Diagram)

Scope the Application Application scope

Elicit/Revise Application Business Goals & Quality Goals Goals

[Not feasible]

Elicit/Revise Assets Assets

Elicit/Revise possible Harm

Goals

[Not feasible]

Possible Harm

Identify/Revise & Verify Security Goals

Elicit/Revise Functional Requirements

[Feasible] Security goals

Functional requirements

Validate Security Goals against Assets, Threats and Business Goals [OK]

[Not feasible]

Construct/Revise & Verify Security Requirements [Feasible] Security requirements

Validate Security Requirements against [Not OK] Security Goals

[OK]

Construct/Revise & Verify System Architecture General System Activity

Security Activity (Construct/Verify)

Security Validation

[Feasible] System Architecture

Validate Security of System Architecture against Security Requirements [OK]

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



one of two kinds: it has been found to be infeasible to create a consistent set of the artifacts that are constructed by that activity; or validation of the artifacts against a higher level — such as validation of security requirements against security goals — shows that they fail to meet their aims. This occurs if it has not been possible to construct a satisfactory satisfaction argument, or if a vulnerability has been found. The iteration may cascade upwards if the architecture is not feasible without a revision of the business or security goals.

Step:.Identify.Security.Goals The security goals of the system owner are derived from a combination of three different sources: the possible harm to assets; management control principles; and application business goals, which will determine the applicability of management control principles, for example by deining those privileges that are needed for the application prior to excluding those that are not. Note that other legitimate stakeholders may have other security goals that conlict with these. The set of relevant security goals may be mutually inconsistent, and inconsistencies will need to be resolved during the goal analysis process, before a set of consistent requirements can be reached. On the other hand, the goals of attackers are not considered to be a part, even negated, of the security goals of the system. The goals of the system owner and other legitimate stakeholders are not directly related to the goals of attackers, because security is not a zero sum game like football. In football, the goals won by an attacker are exactly the goals lost by the defender. Security is different; there is no exact equivalence between the losses incurred by the asset owner and the gains of the attacker. To see this, look at two examples: • •

Robert Morris unleashed the Internet worm (Spafford, 1989), causing millions of dollars of damage, apparently as an experiment without serious malicious intent. The positive value to the attacker was much less than the loss incurred by the attacked sites. Many virus writers today are prepared to expend huge effort in writing a still more ingenious virus, which may cause little damage (screen message “You’ve got a Virus”). Generally, there is no simple relationship between the gains of a virus writer and the losses incurred by those who are attacked.

The consequences of security not being a zero sum game are twofold: the evaluation of possible harm to an asset can generally be carried out without reference to particular attackers; and consideration of the goals of attackers cannot be used simply to arrive at the goals of a defender to prevent harm (i.e., their security goals).

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

Step:.Identify.Security.Requirements

Recall that we deine security requirements to be the constraints on functional requirements that are needed to achieve security goals. In the process, one determines which assets will be implicated in satisfying a particular functional requirement by drawing the context for that functional requirement as a problem diagram. The list of assets and the type of function will produce a list of threats that must be mitigated. The security requirements are these mitigations, constraining the function in ways that will achieve the security goals. A simple example of such a constraint is: The system shall provide Personnel Information only to members of Human Resources Dept.

The constraint (“only to …”) is secondary to the function (“provide Personnel Information”); it only makes sense in the context of the function. One might also impose temporal constraints: The system shall provide Personnel Information only during normal ofice hours.

and complex constraints on traces: The system shall provide information about an organization only to any person who has not previously accessed information about a competitor organization (the Chinese Wall Security Policy) (Brewer & Nash, 1989). Availability requirements will need to express constraints on response time: The system shall provide Personnel Information within  hour for % of requests.

We note that this differs only in magnitude from a Response Time quality goal, which might use the same format to require a sub-second response time.

Step:.Construction.of.Satisfaction.Arguments The next step is to validate the security requirements against the system architecture by constructing the two-part security satisfaction arguments from a problem diagram and a set of security requirements. This step is described in the case study next.

CASE. STUDY This case study, of a personnel information display system, is used to validate the framework that we have set out above and to bring out further issues for discusCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



sion. We irst set out a simple system, with business goals, from which functional requirements are derived, and then show how the system security requirements are derived from the application of the organization’s security goals to the functional requirements. Next, the satisfaction arguments are constructed. Given the system security requirements, there are design decisions to be made about where to locate the security functionality and the approach to be used, and one example of this is provided.

From.System.Business.Goals.to.Security.Requirements. A simple human resources application will be used in this section to illustrate the use of our process. We assume that the business goals have been elicited and that there is only one goal: FG: Provision of people’s personnel information to them.

We further assume that initial requirements have been elicited and that there is only one functional requirement: FREQ: On request from a Person (member of People), the system shall display personnel information (PersonInf) for a speciied payroll number (Payroll#) to that Person.

Further analysis shows that, ignoring physical assets such as the computers and the buildings, there is only one asset implicated in the system: PersonInf, an information asset. The harms that involve PersonInf are exposure (loss of conidentiality), alteration (loss of integrity), and denial of service (loss of availability). The irst harm gives rise to the security goal SG: prevent unauthorized exposure of PersonInf. Likewise, the second harm gives rise to the goal SG: prevent unauthorized alteration of PersonInf, and the third harm gives rise to SG: prevent denial of access to PersonInf by authorized persons.

The next step is to derive security requirements from the combination of functional goals and security goals. Remember that security requirements constrain the function called for by a functional goal. Applying SG to FREQ, we derive the security requirement (constraint) SR: Personnel information must be provided only to HR staff. We cannot apply SG to any functional requirement, because no requirement permits modiication of PersonInf. Applying SG to FREQ, we derive the (somewhat arbitrary) security requirement SR: Personnel information must be provided to HR staff within 0 minutes of its request. Although we have derived two security requirements, for reasons of space we will only look at one of them: SR. Figure 4 shows the initial problem diagram for this application. There are two phenomena of interest. The irst, U!persNumber,

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Haley, Laney, Moffett, & Nuseibeh

Figure 4. Problem diagram for the HR data retrieval application

Users B a

Personal Information Machine + HR Data

Provide HR data requested by user - Only to HR staff

a: U!persNumber HR!persData

is the user’s request for personnel information. The second, HR!persData, is the information returned by the request. We begin by constructing an outer argument that proves the claim: HR data is provided only to HR staff.

Constructing.Satisfaction.Arguments We wish to construct a convincing satisfaction argument that a system can satisfy its security requirements. The reader may note the use of the word “can,” instead of the word “will.” We use the phrase “can satisfy” because we do not know if the eventual implementation will respect the speciications. Nor do we know if the system will introduce unintended vulnerabilities, which manifest themselves as phenomena not described in the behavioral speciication.

The Outer Argument

We irst attempt to construct the outer argument for the HR problem shown in Figure 4. Recall that this argument will take the form: (domain property premises) ├─ security requirement

There are two domains in the problem: the biddable domain “users” and the machine (which contains the data). To construct the argument, we must irst express the behavior of the system more formally, which we do using a notation based on the causal logic described in (Moffett, Hall, Coombes, & McDermid, 1996). In this logic, the behavior of the domains in Figure 4, expressed in terms of the phenomena, is: 1.

U!persNum shall cause M!persData

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



A major problem is immediately exposed. Given what we see in the behavior description, there is no way to connect the system’s behavior to the security requirement, as membership of the Users domain is not made apparent. No formal argument can be constructed. We must ask the system designers for help. There are (at least) three design choices: 1.

Introduce some physical restriction, such as a guard, to ensure that the membership of the domain “users” is restricted to HR staff. Doing so would permit construction of the following outer argument (proof): M is deined as (User ∈ HR) D is deined as (phenomenon HR!persData) D → M (if info is displayed, then user ∈ HR) D (info is displayed) M (therefore user ∈ HR)

2. 3.

Introduce phenomena into the system permitting authentication and authorization of a “user.” Introduce a trust assumption (TA) asserting that the membership of “users” is limited to HR staff, even though no information is available to support the assertion.

To make the example more interesting, we choose option 2. The resulting problem diagram is shown in Figure 5. The diagram shows that the user is to supply some sort of credentials along with the request for information. These credentials are passed to an external authentication and authorization engine, which answers yes or no. If the answer is yes, then the machine provides the data; otherwise, the data is refused. The corresponding behavior speciication is: Figure 5. New HR staff problem diagram

Users B

a

Personal Information Machine + HR Data b

Provide HR data requested by user - Only to HR staff a: U!persNumber(#, userID, credentials) PIM!{ persData | NO }

Credentials Storage

C

b: PIM!validate(userID, credentials) CS!{YES | NO}

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

2. 3.

4. 5.

U!(UserId, credentials, Payroll#) shall cause PIM!Validate(UserId, HR, credentials) if isValid(UserId, credentials) PIM!Validate(HR, UserId, credentials) shall cause CS!YES else PIM!Validate(HR, UserId, credentials) shall cause CS!NO CS!YES shall cause PIM!PersonInf(Payroll#) CS!NO shall cause PIM!NO

We must now construct the satisfaction argument for the new “Users” domain. We begin with the outer argument, irst deining the symbols to be used. These are shown in the following table. Symbol I : Input request V: Validate Creds Y: ReplyYes D: DisplayInfo C: CredsAreValid M: MemberOfHR

Derived from (see Figure 5) U!(UserId, credentials, Payroll#) PIM!Validate(HR, UserId, credentials) CS!YES PIM!PersonInf(Payroll#) isValid(UserId, credentials) Conclusion: user is member of HR

The following predicate logic premises are derived from the behavioral speciication. These premises are the grounds used in the formal argument and, if necessary, will be supported by informal arguments. Name

Premise

Description

P1

I→V

Input of request shall cause validation

P2

C→M

If credentials are valid then user is a member of HR

P3

Y → V&C

A Yes happens only if credentials are valid and validated

P4

D→Y

Display happens only if the answer was Yes

As the requirement is that we display information only to a member of HR, we include D as a premise and M as the conclusion. Thus, we want to show: (P, P, P, P, D ├─ M).

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



Figure 6. Proof: The security argument is satisied 1 2 3 4  6    0 11

I→ V C→ M Y→ V&C D→ Y D Y V&C V C M D→ M

(Premise) (Premise) (Premise) (Premise) (Premise) (Detach (→ elimination), 4, 5) (Detach, , ) (Split (& elimination), ) (Split, ) (Detach, , ) (Conclusion, 5)

A proof is shown in Figure 6.

The Inner Arguments

Each of the rules used in the outer argument should be examined critically. We begin with the premises P1, P3, & P4. These are probably not controversial, because one can say that they are part of the speciication of the system to be implemented. The arguments thus consist of one trust assumption, as shown in the following utterance in our argument language: let G = “system will be correctly implemented”; given grounds G thus claim P. given grounds G thus claim P. given grounds G thus claim P.

Premise P2 is more complex. This premise is making a claim about the membership of the domain “Users” by saying that if a user has valid credentials, then that user must be a member of HR. An argument for this claim is shown next. This argument incorporates three trust assumptions: G2, G3, and G4. given grounds G: “Valid credentials are given only to HR members” warranted by ( given grounds G: “Credentials are given in person” warranted by G: “Credential administrators are honest & reliable” thus claim C: “Credential administration is correct” ) Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

thus claim P: “HR credentials provided --> HR member” rebutted by R: “HR member is dishonest”, R: “social engineering attack succeeds”, R: “person keeps credentials when changing depts” .

The three rebuttals in the argument require some treatment. Recall that rebuttals express conditions under which the argument does not hold. If the rebuttals remain in the argument, they create implicit trust assumptions saying that the conditions expressed in the rebuttals will not occur, which may be acceptable. Alternatively, one could construct an argument against a rebuttal. If we assume that the stakeholder is unwilling to accept R1, then the system must somehow be changed to mitigate the rebuttal.

Removing.Rebuttals.by.Adding.Function At times, the most straightforward way to remove a rebuttal might be to add functionality to a system. The additional functionality would permit adding new grounds or warrants to mitigate the conditions that permit the rebuttal. As an example, consider R1: a dishonest HR member sells credentials. One could mitigate this risk by increasing the probability that an unusual use of the employee’s credentials would be detected, thus raising the probability that the misuse would be detected. Doing so is probably most easily accomplished by adding new functionality to the system. In our example, we add two functional requirements to the system: • •

FREQ: all uses of HR credentials are logged FREQ: any use of HR credentials from a location outside the HR department is immediately signaled by email to the HR director.

These functional requirements would then be used as grounds in an argument against the rebuttal R1: given grounds G: “uses of HR creds are logged (FREQ)” and G: “uses of HR creds from outside are emailed (FREQ)” warranted by G: “these actions increase the probability of detecting improper use of creds” and G: “the employee does not want to get caught” thus claim C: “HR members will not sell their credentials”. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



C2 is added as a mitigating proposition to the rebuttal in argument 1 (R: “HR member is dishonest” mitigated by C).

DISCUSSION. Constructing.Inner.Arguments

One question that arises is “how does the analyst ind rebuttals, grounds, and warrants?” Unfortunately, we cannot propose a recipe. We suggest a method inspired by the how/why questions used in goal-oriented requirements engineering methods (e.g., KAOS, van Lamsweerde, 2001). Given a claim, the analyst asks “Why is this claim true?” and “What happens if it is not true?” The analyst must irst choose which claim is being argued, and then use the “why” question to gather the grounds that are pertinent to the claim along with the warrants that connect the grounds to the claim. The argument is then constructed. The analyst next asks the question “what can prevent this claim from being true?” The answers are the initial rebuttals. Some of these rebuttals will be challenges of the grounds or warrants; these create the need for sub-arguments where the challenged item is a claim. In other cases, the rebuttal will not be addressed, thereby creating an implicit trust assumption stating that the event(s) described in the rebuttal are not to be considered. A third possibility is to add new grounds to the argument that remove the conditions assumed by the rebuttal.

Problem.vs..Solution.Space A reasonable objection to argumentation as described in this chapter is that we are designing the system in order to determine its requirements. To some extent, this is true; the domains included in the system are being more inely described iteratively. However, we argue that the part of the system being constructed is the machine, and we are not designing that. By applying an iterative process that interleaves requirements and design (Nuseibeh, 2001), we are specifying the environment (or context) that the machine lives within. These speciications include additional domains that need to exist (perhaps inside the machine), and additional phenomena required to make use of these domains.

Security.Functional.Requirements Adding functionality to support security requirements creates a traceability problem. This chapter provided two situations where this sort of functionality was added: addition of credential veriication to permit the outer argument to be constructed, and addition of monitoring and logging functionality to support removal of the dishonest employee rebuttal. Somehow these functions must remain connected Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

with the security requirement they support, because the need for these functions could change or disappear if the security requirement changes.

The.Role.of.Automation The structure of the inner argument language permits some forms of automated analysis. Some options under consideration include generating lists of claims supporting a particular premise and testing of the argument through negation of particular trust assumptions. We are also considering using tools like Auraucaria (Reed, 2005) for diagramming the arguments, generating the appropriate input for the program. We have already started using Compendium (Compendium Institute, 2005) to capture problem frame diagrams. We have used BlobLogic (Howitt, 2005) and DC Proof (Christensen, 2005) to help construct and check outer arguments, and we are investigating other proof construction aids.

RELATED. WORK Our work is related to, and builds upon, research on security requirements, design rationale and argument capture, safety requirements analysis.

Security.Requirements We review previous work on security requirements by examining security goals, security policies, non-functional requirements, and other deinitions. Before discussing these it may be useful to point out what security requirements are not.

Security Requirements are not Security Functions

Security requirements are not to be identiied with security functions (e.g., encryption, access control, etc.). Howard and LeBlanc (2001) state this in the following terms: Security Features != Secure Features

The provision of security functionality in a system is only useful if it supports deined and well understood security objectives. Security.Requirements.as.Security.Goals Many authors implicitly assume that security requirements are identical to security goals. Tettero, Out, Franken, and Schot (1997) are explicit about this, deining security requirements as the conidentiality, integrity, and availability of the entity for which protection is needed. While this is a clear deinition, it is too abstract for many purposes: no doubt both doctors and the administrators in the example previously presented would agree on the importance of conidentiality, integrity, Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



and availability of the clinical information, but they would disagree on the concrete security requirements that express those goals. If designers were only given security goals to work with, it would be necessary for them to carry out further work that belongs in the domain of the requirements engineer, by deciding how the security goals should be operationalized in the requirements.

Security Requirements as Security Policies Some authors identify security requirements with security policies. Devanbu and Stubblebine (2000) deine a security requirement as “a manifestation of a highlevel organizational policy into the detailed requirements of a speciic system. [… We] loosely (ab)use the term ‘security policy’ […] to refer to both ‘policy’ and ‘requirement.’” Anderson (2001) is less direct; he states that a security policy is “a document that expresses […] what […] protection mechanisms are to achieve” and that “the process of developing a security policy […] is the process of requirements engineering.” The dificulty with security policies is their chameleon-like meaning; the term can be used for anything from a high-level aspiration to an implementation. Therefore, without accompanying detailed explanation, it is not satisfactory to deine security requirements as security policies.

Security Requirements as Non-Functional Requirements

Devanbu and Stubblebine (2000), in addition to their deinition above, remark that security requirements are a kind of non-functional requirement. We agree with that comment, but it needs further explanation. Kotonya and Sommerville (1998), when discussing non-functional requirements, in which they include security, deine them as “restrictions or constraints” on system services; similar deinitions can be found in other text books. Rushby (2001) appears to take a similar view, stating “security requirements mostly concern what must not happen.” Using the secure Tropos methodology (see Chapter VIII), Mouratidis, Giorgini, and Manson (2003) state that “security constraints deine the system’s security requirements.” Our own view is consistent with these deinitions: that security requirements are most usefully deined as requirements for constraints on system functions.

Other Deinitions of Security Requirements

Lee, Lee, and Lee (2002) point out the importance of considering security requirements in the development life cycle, but do not deine them. ISO/IEC 15408 (ISO/IEC, 1999) does not deine security requirements in its glossary. However, in one place they are depicted as being at a higher level than functional requirements, but elsewhere the reference to “security requirements, such as authorization credentials and the IT implementation itself” appears to us as being at too low a level! Heitmeyer (2001) shows how the SCR method can be used to specify and analyze

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

security properties, without giving the criteria for distinguishing them from other system properties. A number of papers have focused on security requirements by describing how they may be violated. For example, McDermott and Fox (1999) followed independently by Sindre and Opdahl (2000) and elaborated by Alexander (2003), describe abuse and misuse cases, extending the use case paradigm to undesired behavior. Liu, Yu, and Mylopoulos (2003; also Chapter IV) describe a method of analyzing possible illicit use of a system, but omit the important initial step of identifying the security requirements of the system before attempting to identify their violations. Van Lamsweerde (2004) describes a process by which security goals are made precise and reined until reaching security requirements; he does not appear to regard them as different from any other kind of requirement. Antón and Earp (2001) use the GBRAM method to operationalize security goals for the generation of security policies and requirements, but do not deine security requirements.

Design.Rationale.and.Argument.Capture Design rationale is principally concerned with capturing how one arrived at a decision, alternate decisions, or the parameters that went into making the decision (Lee & Lai, 1991). For example, Buckingham Shum (2003) focuses on how rationale (argument) is visualized, especially in collaborative environments. Potts and Bruns (1988), and later Burge and Brown (2004) discuss capturing how decisions were made, which decisions were rejected, and the reasons behind these actions. Mylopoulos, Borgida, Jarke, and Koubarakis (1990) present a way to represent formally knowledge that was captured in some way, without focusing on the outcome of any decisions. Ramesh and Dhar (1992) describe a system for “capturing history in the upstream part of the life cycle.” Fischer, Lemke, McCall, and Morch (1996) suggest that the explicit process of argumentation can itself feed into and beneit design. Finkelstein and Fuks (1989) suggest that the development of speciications by multiple stakeholders, who hold disparate views, may be achieved through an explicit dialogue that captures speech acts, such as assertions, questions, denials, challenges, etc. The representation of the dialogue is then a rationale for the speciications constructed. The common element in all of the above work is the capture over time of the thoughts and reasons behind decisions. Whether the decisions satisfy the needs is not the primary question.

Safety.Cases

Kelly (1999) argues that “a safety case should communicate a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a particular context.” He goes on to show the importance of the distinction between argument and evidence. An argument calls upon appropriate evidence to convince a reader that the argument holds. Attwood et al use the same principles in (2004), taking the position that argument is a bridge between requirements and speciicaCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



tion, permitting capture of suficient information to realize rich traceability. Our work combines these two ideas. The techniques proposed by Kelly are not directly applicable to security without modiication, primarily because the techniques are focused around objective evidence, component failure, and accident, rather than subjective reasoning, subversion, and malicious intent.

Integration.with.Other.RE.Frameworks One area for future work is to adapt the process described in this chapter to other requirements engineering frameworks such as KAOS (van Lamsweerde, 2001), i* (Chung, Nixon, Yu, & Mylopoulos, 2000; Yu, 1997), and SCR (Heitmeyer, Kirby, Lebaw, & Bharadwaj, 1998). All of these frameworks are amenable to using the steps of our process, especially asset and harm analysis, and construction of satisfaction arguments. However, as each of the previous frameworks speciies behavior in a very different way, the construction of the outer argument will be different, and these differences must be investigated.

CONCLUSION At the beginning of this chapter, we stated four motivating concerns, repeated here: • • • •

The “what” of security requirements — its core artifacts — must be understood before the “how” of their construction and analysis. Security cannot be considered as a feature of software alone; it is concerned with the prevention of harm in the real world. We must therefore consider the security requirements of real-world systems in addition to the software. Since security is largely concerned with prevention of misuse of system functions, security requirements can most usefully be deined by considering them as constraints upon functional requirements. Since security is by deinition an “open world” problem (the domain of analysis will always be too small), any argument that a system will satisfy its security requirements must take non-provable assertions about the real world into account.

In this chapter, we have addressed these concerns by presenting a precise deinition of security requirements, a framework for determining these requirements, and a structure for arguing that the requirements will be satisied. Other advantages of our approach are: •

Security requirements are naturally integrated with the system’s functional requirements and with constraints derived from other sources. An integrated development is possible.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Haley, Laney, Moffett, & Nuseibeh

• •

This has the consequence that interactions and trade-offs between security and other quality requirements can be analyzed. For example, interactions and trade-offs between them can be considered in terms of the different required constraints on the same functional requirements. The two-level satisfaction arguments facilitate showing that a system can meet its security requirements. The structure behind the arguments assists in inding system-level vulnerabilities. By irst requiring the construction of the formal argument based on domain properties, one discovers which domain properties are critical for security. Constructing the informal argument showing that these domain properties can be trusted helps point the analyst toward vulnerabilities; the rebuttal is an important part of this process. Vulnerabilities found in this way are removed either through modiication of the problem, addition of security functional requirements, or through addition of trust assumptions that explain why the vulnerability can be discounted.

We claim that this framework will help requirements and security engineers to understand the place of the various synthetic and analytical activities that have previously been carried out in isolation. The framework has raised a number of open issues, mentioned in the discussion, but we believe that it provides a way forward to effective co-operation between the two disciplines of requirements and security.

ACKNOWLEDGMENT

The authors wish to thank Michael Jackson for his continuous involvement and support. Thanks also to Simon Buckingham Shum for many helpful conversations about argumentation. The inancial support of the Leverhulme Trust and the Royal Academy of Engineering is gratefully acknowledged, as is EU support of the E-LeGI project, number IST-002205.

REFERENCES

Alexander, I. (2003). Misuse cases in systems engineering. Computing and Control Engineering Journal, 14(1), 40-45. Anderson, R. (1996). A security policy model for clinical information systems. Proceedings of the 1996 IEEE Symposium on Security and Privacy (pp. 3043). Oakland, CA. Anderson, R. (2001). Security engineering: A guide to building dependable distributed systems. Antón, A. I., & Earp, J. B. (2001). Strategies for developing policies and requirements for secure e-commerce systems. In A. K. Ghosh (Ed.), E-commerce security and privacy (Vol. 2, pp. 29-46). Kluwer Academic Publishers.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



Attwood, K., Kelly, T., & McDermid, J. (2004). The use of satisfaction arguments for traceability in requirements reuse for system families: Position paper. Proceedings of the International Workshop on Requirements Reuse in System Family Engineering, 8th International Conference on Software Reuse (pp. 1821). Carlos III University of Madrid, Spain. Brewer, D. F. C., & Nash, M. J. (1989). The Chinese Wall security policy. Proceedings of the 1989 IEEE Symposium on Security and Privacy (pp. 206-214). Oakland, CA: IEEE Computer Society Press. Buckingham Shum, S. J. (2003). The roots of computer supported argument visualization. In P. A. Kirschner, S. J. Buckingham Shum, & C. S. Carr (Eds.), Visualizing argumentation: Software tools for collaborative and educational sense-making (pp. 3-24). London: Springer-Verlag. Burge, J. E., & Brown, D. C. (2004). An integrated approach for software design checking using design rationale. In J. S. Gero (Ed.), Proceedings of the 1st International Conference on Design Computing and Cognition (pp. 557-576). Cambridge, MA: Kluwer Academic Press. Christensen, D. (2005). DC proof. Retrieved November 9, 2005, from http://www. dcproof.com/ Chung, L., Nixon, B., Yu, E., & Mylopoulos, J. (2000). Non-functional requirements in software engineering. Kluwer Academic Publishers. Compendium Institute. (2005). Compendium. Retrieved from http://www.compendiuminstitute.org/ Devanbu, P., & Stubblebine, S. (2000). Software engineering for security: A roadmap. In A. Finkelstein (Ed.), The future of software engineering. ACM Press. Finkelstein, A., & Fuks, H. (1989). Multiparty speciication. Proceedings of the 5th Int. Workshop on Software Speciication and Design (pp. 185-195). Pittsburgh. Fischer, G., Lemke, A. C., McCall, R., & Morch, A. (1996). Making argumentation serve design. In T. Moran & J. Carroll (Eds.), Design rationale concepts, techniques, and use (pp. 267-293). Lawrence Erlbaum and Associates. Haley, C. B., Laney, R. C., Moffett, J. D., & Nuseibeh, B. (2004). The effect of trust assumptions on the elaboration of security requirements. Proceedings of the 12th International Requirements Engineering Conference (RE’04) (pp. 102-111). Kyoto, Japan: IEEE Computer Society Press. Haley, C. B., Laney, R. C., & Nuseibeh, B. (2004). Deriving security requirements from crosscutting threat descriptions. Proceedings of the 3rd International Conference on Aspect-Oriented Software Development (AOSD’04) (pp. 112121). Lancaster, UK: ACM Press. Haley, C. B., Moffett, J. D., Laney, R., & Nuseibeh, B. (2005). Arguing security: Validating security requirements using structured argumentation. Proceedings of the 3rd Symposium on Requirements Engineering for Information Security (SREIS’05) held in conjunction with the 13th International Requirements Engineering Conference (RE’05). Paris. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Haley, Laney, Moffett, & Nuseibeh

Heitmeyer, C. L. (2001). Applying “practical” formal methods to the speciication and analysis of security properties. Proceedings of the International Workshop on Information Assurance in Computer Networks: Methods, Models, and Architectures for Network Computer Security (MMM ACNS 2001) (Vol. 2052, pp. 84-89). St. Petersburg, Russia: Springer-Verlag Heidelberg. Heitmeyer, C. L., Kirby, J., Lebaw, B. G., & Bharadwaj, R. (1998). SCR*: A toolset for specifying and analyzing software requirements. In A. J. Hu & M. Y. Vardi (Eds.), Proceedings of the 10th International Conference on Computer Aided Veriication (Vol. 1427, pp. 526-531). Vancouver, BC, Canada: Springer. Howard, M., & LeBlanc, D. (2001). Writing secure code. Microsoft Press. Howitt, C. (2005). BlobLogic. Retrieved November 9, 2005, from http://users.ox.ac. uk/~univ0675/blob/blobSplash.html ISO/IEC. (1999). Information technology -- security techniques - -evaluation criteria for it security -- Part 1: Introduction and general model (International Standard No. 15408-1). Geneva, Switzerland: ISO/IEC. Jackson, M. (2001). Problem frames. Addison Wesley. Kelly, T. P. (1999). Arguing safety: A systematic approach to safety case management. Unpublished D.Phil Dissertation, University of York. Kotonya, G., & Sommerville, I. (1998). Requirements engineering: Processes and techniques. UK: John Wiley & Sons. Lee, J., & Lai, K. Y. (1991). What’s in design rationale? Human-Computer Interaction, Special Issue on Design Rationale, 6(3-4), 251-280. Lee, Y., Lee, J., & Lee, Z. (2002). Integrating software lifecycle process standards with security engineering. Computers and Security, 21(4), 345-355. Liu, L., Yu, E., & Mylopoulos, J. (2003). Security and privacy requirements analysis within a social setting. Proceedings of the 11th IEEE International Requirements Engineering Conference (RE’03). Monteray Bay, CA. McDermott, J., & Fox, C. (1999). Using abuse case models for security requirements analysis. In Proceedings of the 15th Computer Security Applications Conference (ACSAC’99) (pp. 55-64). Phoenix, AZ: IEEE Computer Society Press. Moffett, J. D., Haley, C. B., & Nuseibeh, B. (2004). Core security requirements artefacts (Technical Report No. 2004/23). Milton Keynes UK: Department of Computing, The Open University. Moffett, J. D., Hall, J. G., Coombes, A., & McDermid, J. A. (1996). A model for a causal logic for requirements engineering. Requirements Engineering, 1(1), 27-46. Mouratidis, H., Giorgini, P., & Manson, G. (2003). Integrating security and systems engineering: Toward the modelling of secure information systems. Proceedings of the 15th Conference on Advanced Information Systems Engineering (CAiSE’03). Klagenfurt/Velden, Austria: Springer-Verlag. Mylopoulos, J., Borgida, A., Jarke, M., & Koubarakis, M. (1990). Telos: Representing knowledge about information systems. ACM Transactions on Information Systems (TOIS), 8(4), 325-362. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Arguing Satisfaction of Security Requirements



Newman, S. E., & Marshall, C. C. (1991). Pushing Toulmin too far: Learning from an argument representation scheme (Technical Report No. SSL-92-45). Palo Alto, CA: Xerox PARC. Nuseibeh, B. (2001). Weaving together requirements and architectures. Computer (IEEE), 34(3), 115-117. Potts, C., & Bruns, G. (1988). Recording the reasons for design decisions. Proceedings of the 10th International Conference on Software Engineering (ICSE’88) (pp. 418-427). Singapore: IEEE Computer Society. Ramesh, B., & Dhar, V. (1992). Supporting systems development by capturing deliberations during requirements engineering. IEEE Transactions on Software Engineering, 18(6), 498-510. Reed, C. (2005). Araucaria. Retrieved from http://araucaria.computing.dundee. ac.uk/ Rushby, J. (2001). Security requirements speciications: How and what? Proceedings of the Symposium on Requirements Engineering for Information Security (SREIS). Indianapolis. Sindre, G., & Opdahl, A. L. (2000). Eliciting security requirements by misuse cases. Proceedings of the 37th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-Paciic’00) (pp. 120-131). Sydney, Australia. Spafford, E. H. (1989). The internet worm program: An analysis. ACM SIGCOMM Computer Communication Review, 19(1), 17-57. Tettero, O., Out, D. J., Franken, H. M., & Schot, J. (1997). Information security embedded in the design of telematics systems. Computers and Security, 16(2), 145-164. Toulmin, S. E. (1958). The uses of argument. Cambridge: Cambridge University Press. Toulmin, S. E., Rieke, R. D., & Janik, A. (1979). An introduction to reasoning. New York: Macmillan. van Lamsweerde, A. (2001). Goal-oriented requirements engineering: A guided tour. Proceedings of the 5th IEEE International Symposium on Requirements Engineering (RE’01) (pp. 249-263). Toronto, Canada: IEEE Computer Society Press. van Lamsweerde, A. (2004). Elaborating security requirements by construction of intentional anti-models. Proceedings of the 26th International Conference on Software Engineering (ICSE’04) (pp. 148-157). Edinburgh, Scotland. Yu, E. (1997). Towards modelling and reasoning support for early-phase requirements engineering. Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE’97) (pp. 226-235). Annapolis, MD. Zave, P., & Jackson, M. (1997). Four dark corners of requirements engineering. Transactions on Software Engineering and Methodology (ACM), 6(1), 1-30.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

Chapter.III.

Identifying.Security. Requirements.Using.the. Security.Quality. Requirements.Engineering. (SQUARE).Method N. R. Mead, Carnegie Mellon University, USA

ABSTRACT In this chapter, we describe general issues in developing security requirements, methods that have been useful, and a method (SQUARE) that can be used for eliciting, analyzing, and documenting security requirements for software systems. SQUARE, which was developed by the CERT Program at Carnegie Mellon University’s Software Engineering Institute, provides a systematic approach to security requirements engineering. SQUARE has been used on a number of client projects by Carnegie Mellon student teams, prototype tools have been developed, and research is ongoing to improve this promising method.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



THE. IMPORTANCE. OF. REQUIREMENTS. ENGINEERING It is well recognized in industry that requirements engineering is critical to the success of any major development project. Several authoritative studies have shown that requirements engineering defects cost 10 to 200 times as much to correct once ielded than if they were detected during requirements development. Other studies have shown that reworking requirements defects on most software development projects costs 40 to 50% of total project effort, and the percentage of defects originating during requirements engineering is estimated at more than 50%. The total percentage of project budget due to requirements defects is 25 to 40%. A recent study found that the return on investment when security analysis and secure engineering practices are introduced early in the development cycle ranges from 12 to 21%, with the highest rate of return occurring when the analysis is performed during application design (Soo Hoo, Sudbury, & Jaquith, 2001). The National Institute of Standards and Technology (NIST) reports that software that is faulty in security and reliability costs the economy $59.5 billion annually in breakdowns and repairs (NIST, 2002). The costs of poor security requirements show that even a small improvement in this area would provide a high value. By the time that an application is ielded and in its operational environment, it is very dificult and expensive to signiicantly improve its security. Requirements problems are the number one cause of why projects: • • • • • •

Are signiicantly over budget Are signiicantly past schedule Have signiicantly reduced scope Deliver poor-quality applications Are not signiicantly used once delivered Are cancelled

Requirements engineering typically suffers from the following major problems: •

•

•

Requirements identiication typically does not include all relevant stakeholders and does not use the most modern or eficient techniques. Requirements analysis typically is either not performed at all (identiied requirements are directly speciied without any analysis or modeling) or analysis is restricted to functional requirements, ignoring quality requirements, other non-functional requirements, and architecture, design, implementation, and testing constraints. Requirements speciication is typically haphazard, with speciied requirements being ambiguous, incomplete (e.g., non-functional requirements are often missing), inconsistent, not cohesive, infeasible, obsolete, neither testable

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

•

nor capable of being validated, and not usable by all of their intended audiences. Requirements management is typically weak with poor storage (e.g., in one or more documents rather than in a database or tool) and missing attributes, and is limited to tracing, scheduling, and prioritization. (http://www.sei.cmu. edu/cmmi/)

Security.Requirements.Issues.

Although security requirements are often identiied during the system life cycle, they tend to be general mechanisms such as password protection, irewalls, virus detection tools, and the like. Often the security requirements are developed independently of the rest of the requirements engineering activity and hence are not integrated into the mainstream of the requirements activities. As a result, security requirements that are speciic to the system and that provide for protection of essential services and assets are often neglected. In typical requirements documents, security requirements, when they exist, are in a section by themselves and have been copied from a generic set of security requirements. The requirements elicitation and analysis that is needed to get a better set of security requirements seldom takes place. Much requirements engineering research and practice has addressed the capabilities that the system will provide. So a lot of attention is given to the functionality of the system, from the user’s perspective, but little attention is given to what the system should not do. In one discussion on requirements prioritization for a speciic large system, ease of use was assigned a higher priority than security requirements. Security requirements were in the lower half of the prioritized requirements. This occurred in part because the only security requirements that were considered had to do with access control. Current research recognizes that security requirements are negative requirements. As such, general security requirements, such as “The system shall not allow successful attacks,” are generally not feasible as there is no agreement on ways to validate them other than to apply formal methods to the entire system, including commercial off-the-shelf (COTS) components. We can, however, identify the essential services and assets that must be protected. We are able to validate that mechanisms such as access control, levels of security, backups, replication, and policy are implemented and enforced. We can also validate that the system will properly handle speciic threats identiied by a threat model and correctly respond to intrusion scenarios. If security requirements are not effectively deined, the resulting system cannot be effectively evaluated for success or failure prior to implementation. In addition to employing applicable software engineering techniques, the organization must understand how to incorporate the techniques into its existing software development processes (Linger, Mead, & Lipson, 1998). The extent to which an organization Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



promotes the adoption of security requirements elicitation can be an indicator of the security level of its products. Although data exists to support the beneits of requirements engineering in general, the data to speciically support the beneits of security requirements engineering is anecdotal. Organizations can signiicantly improve the security of their systems by utilizing a systematic approach to security requirements engineering. The SQUARE method, which will be described here in detail, can help in this task.

METHODS.AND. PRACTICES Misuse.and.Abuse.Cases

A security “misuse” case (Alexander, 2003; Sindre & Opdahl, 2000; Sindre, Opdahl, & Brevik, 2002), a variation on a use case, is used to describe a scenario from the point of view of the attacker. Since use cases have proven useful in documenting normal use scenarios, they can also be used to document intruder usage scenarios, and ultimately can be used to identify security requirements or security use cases (Firesmith, 2003). A similar concept has been described as an “abuse” case (McDermott, 2001; McDermott & Fox, 1999). One obvious application of a misuse case is in eliciting requirements. Since use cases are used successfully for eliciting requirements, it follows that misuse cases can be used to identify potential threats and to elicit security requirements. In this application, the traditional user interaction with the system is diagrammed simultaneously with the hostile user’s interactions. An example of this is shown in Figure 1 (Alexander, 2003). Alternatively, abuse cases tend to show the “abuse” side of the system, in contrast to traditional use cases. The contrast between use and abuse cases is shown in Table 1 (McDermott, 1999).

Formal.Methods

Formal methods are typically used in speciication and veriication of secure and secure systems. From a life cycle viewpoint, the speciication typically represents either formal requirements or a formal step between informal requirements and design. Some formal methods are applied to security standards, such as the Common Criteria. Organizational objectives are translated into the speciication of all relevant security functions in a planned system. The subset of speciications to be implemented is identiied and further assessment or risk analysis takes place (Leiwo, 1999a). The Common Criteria are used during the second or evaluation phase. The Kruger-Eloff process, based on the Common Criteria, is used for evaluation of information security. Another method focuses more generally on information security policy speciication (Ortalo, 1998). A formal speciication language is described, and in a Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

Figure 1. Abuse case diagram for an Internet-based information security laboratory Copy another student’s work Tamper with scores Tamper with exercise Malicious Student Root lab host Vandalize lab host Browse exercise with Warez Script Kiddie

Browse exercise with Scalpel Capture lab host Nazgul

Table 1. Contrast between use and abuse cases Use.Case • A complete transaction between one or more actors and a system. • UML-based use case diagrams. • Typically described using natural language.

Abuse.Case • A family of complete transactions between one or more actors and a system that results in harm. • UML-based use case diagrams. • Typically described using natural language. A tree/DAG diagram may also be used. • Potentially one family member for each kind of privilege abuse and for each component that might be exploited. • Includes a description of the range of security privileges that may be abused. • Includes a description of the harm that results from an abuse case.

case study the method is applied to the description of security requirements for a medium-size banking organization. This method provides lexibility and expression so as to correspond to speciic organizational needs. The B formal method is used speciically to support the design and validation of the transaction mechanism for smart card applications. The mathematical proofs provide conidence that the design of the transaction mechanism satisies the security requirements (Sabatier & Lartigue, 1999). Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



An interesting contribution is a model that focuses on modeling the organization in which information security is developed (Leiwo, Gamage, & Zheng, 1999b). The organization is described in layers of abstraction. In addition, a notation for expressing security requirements is described, under a framework of harmonization functions and merging of requirements. A case study that focuses on the security requirements for sharing of patient data among hospitals and medical practitioners is described.

Use.of.Attack.Trees.for.Modeling.and.Analysis The notion of attack trees as a method for modeling attacks has been described extensively in the literature (Schneier, 2000). The work by Ellison and Moore (Ellison, 2003; Moore, 2001) explores the use of attack trees in the development of intrusion scenarios, which can then be used to identify security requirements. A small attack tree example is shown in Figure 2. Once fault trees have been used to model intrusions, they can also be used to help identify requirements for intrusion detection systems, as described in the paper. Alternatively, fault tree analysis can be used to identify other security requirements, once the fault trees have been used to model intrusion behavior. Formal use of fault trees suggests the possibility of formal analysis, which could be a great advantage in developing a set of consistent and complete requirements.

Software.Cost.Reduction Software cost reduction (SCR) is a formal method based on a tabular representation of speciications and analysis of the requirements for complex systems. It was originally developed to document the behavior of the A-7E aircraft (Henninger, 1980) and has been augmented with a tool suite and applied to many complex and safety-critical systems (Heitmeyer, 2002). Figure 3 shows the relationship between the system requirements speciication (SRS), the system design speciication (SDS), and the software requirements speciication (SoRS). This decomposition is commonly used in many large DoD and other government systems. The SCR notation is used for speciication. According to Heitmeyer and Bharadwaj (Bharadwaj, 2003): To specify the required system behavior in a practical and eficient manner, the SCR method uses terms and mode classes. A term is an auxiliary variable that helps keep the speciication concise. A mode class is a special case of a term, whose values are modes. Each mode deines an equivalence class of system states, useful in specifying the required system behavior. In SCR speciications, we often use preixes in variable name. In SCR speciications, we often use the following preixes in variable names: “m” to indicate monitored variables, “t” for terms, “mc” for mode classes, “c” for controlled variables, “i” for input variables and “o” for output variables.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Mead

Figure 2. Attack tree example Open Safe

Pick Lock I

Learn Combo

Find Written Combo I

Threaten I

Cut Open Safe P

Install Improperly I

Get Combo From Target

Blackmail I

Bribe P

Eavesdrop

and Listen to Conversation P

P = Possible I = Impossible

Get Target to State Combo I

Figure 3. Relationship between the SRS, the SDS, and the SoRS NAT

M SRS

{

C

SYSTEM

…

REQ

…

sensors

SDS

SoRS

{

input vars.

{

Input Device Interf. Module

actuators

output vars.

SOFTWARE

D_IN

~ M

DeviceIndepend. Module

~

REQ

~ C

Output Device Interf. Module

D_OUT

Conditions and events are important constructs in SCR speciications. A condition is a predicate deined on one or more state variables (a state variable is a monitored or controlled variable, a mode class, or a term). An event occurs when a state variable changes value.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



Table 2. Condition table deining the value of term tRemLL

Mode unoccupied occupied temp_empty tRemLL

Mode.Class.=.mcStatus Trac. Condition True False FM3 mIndoorLL > mIndoorLL ≤ FM1 tCurrentLSVal tCurrentLSVal mIndoorLL > mIndoorLL ≤ tCurrentLSVal tCurrentLSVal FM1, FM6 OR tOverride AND NOT tOverride tCurrentLSVal – FM1 0 mIndoorLL

Table 2 is an example of an SCR table. For systems that require a rigorous speciication method, SCR would seem to be a good choice. It is probably not as useful in the early requirements stages, for example during elicitation, and may have the most utility in the speciication activity that tends to occur between requirements and design activities.

OVERVIEW. OF. THE. SQUARE. PROCESS System quality requirements engineering (SQUARE) is a model developed at Carnegie Mellon University by Nancy Mead as part of a research project with Donald Firesmith and Carol Woody of the Software Engineering Institute. The motivation behind SQUARE is to see whether good requirements engineering processes can be adapted speciically to the problem of identifying security requirements. If this can be done successfully, organizations will have the ability to identify security requirements up front, rather than as an afterthought. The SQUARE process provides a means for eliciting, categorizing, and prioritizing security requirements for information technology systems and applications. Note that while there is nothing unique about the steps in the process, which have existed for many years in requirements engineering, we have seen relatively little on their application to security requirements, and even less on whether such a process is successful for developing security requirements. Many of the existing methods that were described it nicely into the SQUARE process. These include misuse and abuse cases, attack trees, and formal methods. Others, such as the common criteria and SCR, suggest their own requirements engineering process. The SQUARE method seeks to build security concepts into the early stages of the development life cycle. The model may also be useful for documenting and analyzing the security aspects of ielded systems and could be used to steer future improvements and modiications to these systems. This was the initial draft process: Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

Step 1: Agree on deinitions • Input: Candidate deinitions from IEEE and other standards • Techniques: Structured interviews, focus group • Participants: Stakeholders, requirements team • Output: Agreed-to deinitions Step.2:.Identify.safety.and.security.goals • Input: Deinitions, candidate goals, business drivers, policies and procedures, examples • Techniques: Facilitated work session, surveys, interviews • Participants: Stakeholders, requirements engineer • Output: Goals Step.3: Select.elicitation.techniques • Input: Goals, deinitions, candidate techniques, expertise of stakeholders, organizational style, culture, level of safety and security needed, cost beneit analysis, etc. • Techniques: Work session • Participants:.Requirements engineer • Output: Selected elicitation techniques Step.4: Develop.artifacts.to.support.elicitation.technique • Input: Selected techniques, potential artifacts (e.g., scenarios, misuse cases, templates, forms) • Techniques: Work session • Participants: Requirements engineer • Output: Needed artifacts: scenarios, misuse cases, models, templates, forms Step.5: Elicit.safety.and.security.requirements • Input: Artifacts, selected techniques • Techniques: Joint application design (JAD), interviews, surveys, model-based analysis, safety analysis, checklists, lists of reusable requirements types, document reviews • Participants: Stakeholders facilitated by requirements engineer • Output: Initial cut at safety and security requirements Step.6: Categorize.requirements.as.to.level.(system,.software,.etc.).and.whether. they.are.requirements.or.other.kinds.of.constraints • Input: Initial requirements, architecture • Techniques: Work session using a standard set of categories • Participants: Requirements engineer, other specialists as needed • Output: Categorized requirements Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



Step.7:.Perform.risk.assessment • Input: Categorized requirements, target operational environment • Techniques: Risk assessment method, analysis of anticipated risk against organizational risk tolerance, including hazard/threat analysis (OCTAVE, Shawn Butler, Martin Feather) • Participants: Requirements engineer, risk expert, stakeholders • Output: Risk assessment results, added mitigation requirements to bring exposure into acceptable level Step.8: Prioritize.requirements • Input: Categorized requirements and risk assessment results • Techniques: Prioritization methods such as Triage, Win-Win, etc. • Participants: Stakeholders facilitated by requirements engineer • Output: Prioritized requirements Step.9: Requirements.inspection • Input: Prioritized requirements, candidate formal inspection technique • Techniques: Inspection method such as Fagan, peer reviews, etc. • Participants: Inspection team • Output: Initial selected requirements, documentation of decision making process and rationale Subsequent to initial development, SQUARE was applied in a series of client case studies. Carnegie Mellon graduate students worked on this project during the summer and fall of 2004. The case study results were published (Chen et al., 2004; Gordon, Mead, Stehney, Wattas, & Yu, 2005; Xie et al., 2004). Prototype tools were also developed to support the process. These case studies focused on security more than on other quality attributes, so the name has evolved to become security quality requirements engineering. Since the process was not actually used for elicitation and analysis of safety requirements, safety was dropped from the documented process. The draft process itself was revised based on the case studies. The revised process is shown next. The students recommended a reordering and merger of some of the steps. There was a change in the order, but the steps were not merged. The reason for not merging the steps was that the students had suggested compressing most of the requirements process itself into one-step, which did not seem like it was the right direction to take. In order to try to make the process more manageable, however, it was decided to reorder the steps and separate those that could be considered prerequisites from the rest of the process. In principle, Steps 1-4 are actually activities that precede security requirements engineering but are necessary to ensure that it is successful. An important change was the decision to move risk assessment earlier in the process, so that the risk assessment would help in generating security requirements, rather than attempting to generate the requirements irst and then perform the risk assessment. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

Step.1: Agree on deinitions • Input: Candidate deinitions from IEEE and other standards • Techniques: Structured interviews, focus group • Participants: Stakeholders, requirements team • Output: Agreed-to deinitions Step.2: Identify.security.goals • Input: Deinitions, candidate goals, business drivers, policies and procedures, examples • Techniques: Facilitated work session, surveys, interviews • Participants: Stakeholders, requirements engineer • Output: Goals Step.3: Develop artifacts to support security requirements deinition • Input: Potential artifacts (e.g., scenarios, misuse cases, templates, forms) • Techniques: Work session • Participants: Requirements engineer • Output: Needed artifacts: scenarios, misuse cases, models, templates, forms Step.4: Perform.risk.assessment • Input: Misuse cases, scenarios, security goals • Techniques: Risk assessment method, analysis of anticipated risk against organizational risk tolerance, including threat analysis • Participants: Requirements engineer, risk expert, stakeholders • Output: Risk assessment results Step.5: Select.elicitation.techniques • Input: Goals, deinitions, candidate techniques, expertise of stakeholders, organizational style, culture, level of security needed, cost beneit analysis, etc. • Techniques: Work session • Participants: Requirements engineer • Output: Selected elicitation techniques Step.6: Elicit.security.requirements • Input: Artifacts, risk assessment results, selected techniques • Techniques: Joint Application Development (JAD), interviews, surveys, model-based analysis, checklists, lists of reusable requirements types, document reviews • Participants: Stakeholders facilitated by requirements engineer • Output: Initial cut at security requirements Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



Step.7: Categorize.requirements.as.to.level.(system,.software,.etc.).and.whether. they.are.requirements.or.other.kinds.of.constraints • Input: Initial requirements, architecture • Techniques: Work session using a standard set of categories • Participants: Requirements engineer, other specialists as needed • Output: Categorized requirements Step.8: Prioritize.requirements • Input: Categorized requirements and risk assessment results • Techniques: Prioritization methods such as Triage, Win-Win, etc. • Participants: Stakeholders facilitated by requirements engineer • Output: Prioritized requirements Step.9: Requirements.inspection • Input:.Prioritized requirements, candidate formal inspection technique • Techniques: Inspection method such as Fagan, peer reviews, etc. • Participants: Inspection team • Output: Initial selected requirements, documentation of decision-making process and rationale

How.to.Apply.SQUARE This process is best applied by the project’s requirements engineers and security experts, in the context of supportive executive management and stakeholders. We believe the process works best when elicitation occurs after risk assessment (Step 4) has been done, and when security requirements are speciied prior to critical architecture and design decisions. Thus critical business risks will be considered in development of the security requirements. Step 1: Agree on Deinitions is needed as a prerequisite to security requirements engineering. On a given project, team members will tend to have deinitions in mind, based on their prior experience, but those deinitions will not necessarily agree (Woody, 2005). For example, to some government organizations, security has to do with access based on security clearance levels, whereas to others security may have to do with physical security or cybersecurity. It is not necessary to invent deinitions. Most likely, sources such as IEEE and SWEBOK will provide a range of deinitions to select from or tailor. A focus group meeting with the interested parties will most likely allow a consistent set of deinitions to be selected for the security requirements activity. Step.2:.Identify.Security.Goals should be done at the level of the organization and is needed to develop the information system. This provides a consistency check with the organization’s policies and operational security environment. Different stakeholders will likely have different goals. For example, a stakeholder in human Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

resources may be concerned about maintaining the conidentiality of personnel records, whereas a stakeholder in a inancial area may be concerned with ensuring that inancial data is not accessed or modiied without authorization. It is important to have a representative set of stakeholders, including those with operational expertise. Once the goals of the various stakeholders have been identiied, they will need to be prioritized. In the absence of consensus, an executive decision may be needed to do that. Step.3:.Develop.Artifacts is necessary to support all the subsequent activities. It is often the case that organizations do not have a documented concept of operations for a project, succinctly stated project goals, documented normal usage and threat scenarios, misuse cases, and other documents needed to support requirements deinition. This means that either the entire requirements process is built on a foundation of sand or a lot of time is spent backtracking to try to obtain such documentation. Step. 4:. Perform. Risk. Assessment requires an expert in risk assessment methods, the support of the stakeholders, and the support of a requirements engineer. There are a number of risk assessment methods to select from. A speciic method can be recommended by the risk assessment expert, based on the needs of the organization. The artifacts from Step 3 provide the input to the risk assessment process. The outcomes of the risk assessment can help in identifying the high-priority security exposures. Organizations that do not perform risk assessment typically do not have a logical approach to consider organizational risk when identifying security requirements but tend to select mechanisms, such as encryption, without really understanding the problem that is being solved. Step.5:.Select.Elicitation.Technique becomes important when there are several classes of stakeholders. A more formal elicitation technique, such as JAD or structured interviews, can be effective in overcoming communication issues when there are stakeholders with different cultural backgrounds. In other cases, elicitation may simply consist of sitting down with a primary stakeholder to try to understand that stakeholder’s security requirements needs. Step.6:.Elicit.Security.Requirements is the actual elicitation process using the selected technique. Most elicitation techniques provide detailed guidance on how to perform elicitation. This builds on the artifacts that were developed in earlier steps, such as misuse and abuse cases, attack trees, and threat scenarios. Step.7:.Categorize.Requirements allows the requirements engineer to distinguish among essential requirements, goals (desired requirements), and architectural constraints that may be present. Requirements that are actually constraints typically occur when a speciic system architecture has been chosen prior to the requirements process. This is good, as it allows assessment of the risks associated with these constraints. This categorization also helps in the prioritization activity that follows. Step.8:.Prioritize.Requirements depends not only on the prior step but may also suggest performing a cost/beneit analysis in order to determine which security requirements have a high payoff relative to their cost. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



Step.9:.Requirements.Inspection can be done at varying levels of formality, from Fagan Inspections to peer reviews. Once inspection is complete, the organization should have an initial set of prioritized security requirements. It should also understand which areas are incomplete and must be revisited at a later time. Finally, the organization should understand which areas are dependent on speciic architectures and implementations and should expect to revisit those as well.

Measurement.

Although quantitative measures are still dificult to arrive at, the client for the case studies mentioned earlier recognized the value of the new security requirements and has started to take steps to incorporate them into the system. Important considerations for management are the amount of resources to be invested in this activity and in the implementation of the resultant requirements (Xie et al., 2004). Management also needs to provide insights into the business environment and drivers, the mission of the system under development, and inputs as to the essential services and assets of the system.

CASE. STUDIES The initial SQUARE model was tested by graduate students at Carnegie Mellon University in 2004 in two consecutive case study phases. Carnegie Mellon students, under the mentorship of Nancy Mead, partnered with an IT irm, Acme Corporation, in order to apply the model to one of the irm’s ielded systems.

Acme.Corporation Acme Corporation (Acme)1 is a private company headquartered in Pittsburgh. It provides technical and management services to various public sectors and a number of diversiied private sectors. Its product under study, the asset management system (AMS),2 provides a tool for companies to make strategic allocations and planning of their critical IT assets. It provides specialized decision support capabilities via customized views. The AMS provides a graphical interface to track and analyze the state of important assets. The security requirements surrounding the AMS are the subject of these graduate case studies. It is important to note here that the AMS is a ielded system, undergoing major upgrades, so the results from the irst two case studies may not be a perfect it for determining SQUARE’s usefulness in a preproduction environment. However, the willingness of the client to participate was an important factor in its selection. Further, the results of these case studies are important in beginning to understand the effectiveness of the initial nine steps of the SQUARE process.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

Case.Study.Phase.1

The irst phase of the case study was conducted by seven graduate students at Carnegie Mellon University, during the summer of 2004. The team followed the SQUARE model with two goals in mind: 1. 2.

Complete a security requirements deliverable for Acme Provide feedback to the CERT Program regarding both dificulties encountered and recommendations for incorporation into the model

The work from this phase of the case study is documented in Chen et al. (2004) and Mead (2004). The team attempted to address each of the nine steps in the model. Within the time allotted in the summer semester, the team was unable to give all nine steps the full attention needed to provide complete results to the SEI. For this reason, a second iteration was eventually needed. However, this team completed a great deal of important work that was critical to the success of the second iteration. In short, this case study served as the information-gathering workhorse — its results were analyzed in the second case study to provide the inal outputs from SQUARE. Most of the meaningful work produced from this iteration came in the form of artifacts developed and the delivery of other meaningful documentation. The team laid the groundwork in deining business and security goals and had Acme agree to a list of security deinitions. Then it completed use case and misuse case work and a preliminary attack tree analysis and completed a inal deliverable to the client consisting of architectural and policy recommendations. The team did not have enough time to complete a true security requirements deliverable, but instead provided draft requirements and architectural and policy recommendations, along with cost data, as a meaningful product for Acme. Lacking was a succinct document that focused more on requirements and less on recommendations. Further, the inal deliverable did not easily map back to Acme’s business or security goals. A second case study would be conducted to reine the output from this case study.

Case.Study.Phase.2 During the fall of 2004, a second team, comprising four Carnegie Mellon graduate students, began a new iteration of the case study that built on the deliverables from the irst iteration. Two main goals were identiied: 1. 2.

Provide a deeper examination of certain aspects of the nine-step model Provide a more focused security requirements deliverable for Acme Corporation

Work from this phase of the case study is documented in Gordon et al. (2005). Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



The initial work for this phase began with a more in-depth analysis of artifact generation. The team worked to ill in the gaps in the documentation provided from the previous iteration and to forge new ground in untested artifact generation. A more comprehensive set of use cases (and corresponding diagrams) was generated. Not only did this work help to more fully characterize the system, but it also allowed the group to become familiar with AMS. Attack trees were reexamined and a more robust set of attack trees was created. These attack trees were then compared to the misuse cases provided by the previous team. This comparison served as a sanity check — all misuse cases and attack trees were resolved, and the team moved forward conident that a reasonable set of possible attacks had been considered and documented. Following a recommendation from the irst case study, this team borrowed from the Survivable Systems Analysis model in characterizing essential services and assets. This was completed as an additional sanity check to be utilized in the prioritization stage to follow. Along with this work, the team worked with Acme to determine a reined set of security goals (Step 2 in the SQUARE Process) that could be represented in a hierarchy. The team irst outlined Acme’s business goal and then determined three high-level security goals. From here, nine lower level security requirements were drawn from the various architectural and policy recommendations provided as input from the irst team’s work. The hierarchy allows for varying levels of abstraction and provides a means for mapping a low-level recommendation to Acme’s security goals and ultimately its business goals (see Figure 4). To examine risk assessment, the team irst completed a literature review of eight industry models aimed at analyzing risk. Based on various suitability and feasibility criteria, the team selected two models to ield test within the boundaries of the case study. More speciically, the team tested the Risk Filtering and Ranking Methodology created by Yacov Haimes (Haimes, 2004), as well as the NIST risk assessment technique outlined in its Special Publication 800-30 (Stoneburner, Goguen, & Feringa, 2002). Risk assessment results from these two ield tests were then combined and used as input into requirements prioritization. The results of the risk assessment were then used to prioritize the categorized requirements provided from the output of Step 6. Each of the nine security requirements were labeled essential, conditional, or optional based on how well they protected against likely and important threats. Essential asset and service identiication served as an added sanity check to ensure that the requirements truly fulilled all security goals. More details on this process can be found in the case study report (Gordon et al., 2005). For the requirements inspection portion of the research, the team kept a peer review log to keep formal documentation of bugs and defects. This tool provided a useful way for the team to communicate and manage a wide range of documents.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Mead

Figure 4. Hierarchy of security goals

Output.from.SQUARE.Steps In each case study, the student teams focused part of their efforts in researching various methods to conduct each step. In some cases, redundant work was completed to determine which methods might lend themselves better to SQUARE. In order to provide concrete examples of the nine SQUARE steps, we present here a sample of the output from each individual step (all taken from the irst two case studies) to demonstrate how SQUARE looks in action. Step 1: Agree on Deinitions The student teams worked with the client to agree on a common set of security deinitions in order to create a common base of understanding. The following is a small subset of the deinitions that were agreed upon: •

• •

Access.control: Access control ensures that resources are only granted to those users who are entitled to them. Access.control.list: A table that tells a computer operating system which access rights or explicit denials each user has to a particular system object, such as a ile directory or individual ile. Antivirus.software: A class of program that searches hard drives and loppy disks for any known or potential viruses.

The full set of deinitions was drawn from resources such as Carnegie Mellon University, IEEE, industry, and dictionaries. Step.2:.Identify.Safety.and.Security.Goals Here, the project team worked with the client to lesh out security goals that mapped to the company’s overall business goal. The business and security goals were deined as follows:

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method

•

•

1. 2. 3.



Business.goal.of.AMS: To provide an application that supports asset management and planning. Security. goals: Three high-level security goals were derived for the system: Management shall exercise effective control over the system’s coniguration and usage The conidentiality, accuracy, and integrity of the AMS shall be maintained The AMS shall be available for use when needed

Step.3:.Select.Elicitation.Techniques For this step, student teams were tasked with testing various elicitation techniques and models for the overall beneit of SQUARE. Since there were only three stakeholders and all were members of Acme’s development team, structured interviews were the primary elicitation technique. In later case studies, some clients had a broader variety of stakeholders. Step.4:.Developing.Artifacts Architectural diagrams, use cases, misuse cases, attack trees, and essential assets and services were documented in this portion of SQUARE. For instance, an attack scenario was documented in the following way: 1.

2.

System Administrator accesses conidential information By being recruited OR a. By being bribed OR b. By being threatened OR c. Through social engineering OR By purposefully abusing rights.

This step creates a volume of important documentation that serves as a vital input into the following steps. Steps.5.and.6:.Elicit.and.Categorize.Safety.and.Security.Requirements Nine security requirements were derived and then organized to map to the three higher level security goals. Two of the nine requirements are depicted here: •

•

Req.1:.The system is required to have strong authentication measures in place at all system gateways/entrance points (maps to Goals 1 and 2). Req.3: It is required that a continuity of operations plan (COOP) be in place to ensure system availability (maps to Goal 3).

The nine security requirements made up the heart of the security requirements document that was ultimately delivered to the client. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

Step.7:.Perform.Risk.Assessment The risk management techniques that were ield tested were selected after a literature review was completed. This literature review examined the usefulness and applicability of eight risk assessment techniques: 1. 2. 3. 4. 5. 6. 7. 8.

General Accounting Ofice Model (GAO, 1999) National Institute of Standards Model (Stoneburner et al., 2002) NSA’s INFOSEC Assessment Methodology (Infosec, 2004) Shawn Butler’s Security Attribute Evaluation Method (Butler, 2002) Carnegie Mellon’s Vendor Risk Assessment and Threat Evaluation (Lipson, Mead, & Moore, 2001) Yacov Haimes’s Risk Filtering, Ranking, and Management Model (Haimes, 2004) Carnegie Mellon’s Survivable Systems Analysis Method (Mead, 2002) Martin Feather’s Defect Detection and Prevention Model (Cornford, Feather, & Hicks, 2004) Each method was ranked in four categories:

1. 2. 3. 4.

Suitability for small companies Feasibility of completion in the time allotted Lack of dependence on historical threat data Suitability in addressing requirements

After averaging scores from the four categories, NIST’s and Haimes’s models were selected as useful techniques for the risk assessment step. Many threat scenarios were brainstormed during this step. Some of this input came from the attack tree and misuse case documentation provided from Step 4. The two independent risk assessment analyses produced a useful risk proile for the company’s system. The two most meaningful indings were 1. 2.

Insider threat poses the most important risk to the AMS. Because of weak controls, it is easy for an insider or passerby to defeat authentication.

All indings from the risk assessment, along with the indings from the essential services and asset identiication process completed in the artifact generation stage, were used to determine the priority level associated with each of the nine requirements. Step.8:.Prioritize.Requirements The nine security requirements were prioritized based on the following qualitative rankings: Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method

• •

•



Essential: Product will be unacceptable absent these requirements. Conditional: Requirement would enhance safety and security but would not be unacceptable in its absence. Optional: Requirement may or may not be necessary.

Recalling the requirements identiied in Steps 5-6, Req 1, which dealt with authentication at borders and gateways, was deemed essential because of its importance in protecting against the authentication-related risks outlined as a major risk in the risk assessment. Req 3, dealing with continuity of operations planning, is still seen as an important element and worth considering, but was found to be an optional requirement relative to the other eight requirements. That is, though COOP plans are valuable, the risk assessment phase found that the greater threats to the system were those that dealt with unauthorized disclosure of information, rather than availability attacks. Step.9:.Requirements.Inspection Each team member played a role in inspecting the quality of the team’s work and deliverables. A peer review log was created to document what had been reviewed and was used to maintain a log of all problems, defects, and concerns. Each entry in the log was numbered and dated, addressing the date, origin, defect type, description, severity, owner, reviewer, and status. Each piece of documentation was assigned to an owner, who was held responsible for making sure that defects were ixed. This step was used as a sanity check to ensure that the team’s work met the group’s quality goals and expectations.

Managing.and.Assessing.SQUARE

The inal output to the client was a security requirements document that began by addressing the business goal, followed by the three security goals that supported this business goal, the nine categorized security requirements that supported the higher-level security goals, and a list of application and coniguration-speciic recommendations to meet these security requirements. From here, a responsible irm would use this document in the early stages of the production life cycle to make sure that security requirements are built into the planning of the project. Once a system has been deployed, the irm can look back to its requirements documentation to analyze whether it meets its requirements and thus satisies its security goals to protect the system’s business function. As change occurs — be it a coniguration concern in the system, the organization’s risk proile, or overall business goal — the process can be reused to plan how the changing environment will affect the security concerns of the system. SQUARE is thus easily reapplied to a system as needed. Because the key players include a dedicated task force with knowledge of security who team with a group of knowledgeable client personnel, conducting a SQUARE assessment only requires that a irm have the time and human resources available to Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

assist a group of outside analysts. Further, a irm knowledgeable in security could be in a position to conduct SQUARE analysis without outside help. The irst student team spent a signiicant amount of time with the client in helping the client develop documentation. Many irms may complete this step before the SQUARE analysis begins. The second phase of the case made use of this documentation and was able to complete its assessment with very little client/analyst interaction. The SQUARE analysis was very lightweight and unobtrusive to the client in this regard.

Current.Activities.and.Future.Plans Another group of graduate students at Carnegie Mellon University continued to perform case studies of the SQUARE process implementation. Their goal was to experiment with structured requirements elicitation techniques and analyze their effectiveness in eliciting security requirements. Speciically, the following elicitation techniques were considered: Joint Application Development (JAD) (Wood & Silver, 1989), Hubbard’s facilitator-driven approach (Hubbard, Schroeder, & Mead, 2000), structured interviews with IBIS (Kunz & Rittel, 1970), controlled requirements expression (CORE) (Mullery, 1979), quality function deployment (QFD) (QFD, 2005), feature-oriented domain analysis (FODA) (Kang, Cohen, Hess, Novak, & Peterson, 1990), misuse cases (Alexander, 2003; Sindre et al., 2000; Sindre et al., 2002), soft systems methodology (SSM) (Checkland, 1989), critical discourse analysis (Schiffrin, 1994). The techniques selected were Structured Interviews with IBIS, Hubbard’s facilitator-driven approach, and controlled requirements expression (CORE). To compare the relative strengths and weaknesses of these elicitation techniques, the students worked with three separate industrial projects over the summer of 2005. For each project, the student team selected a different elicitation technique and performed Steps 5 through 9 of the SQUARE process. Hubbard’s facilitator-driven approach seemed to be most successful in eficiently eliciting security requirements. Additionally the analytical hierarchical prioritization method (AHP) helped to prioritize requirements. The weakest area was Step 9. The informal review method used for inspecting the requirements was not illuminating. Security requirements merit a more formal inspection, such as an adaptation of the Fagan inspection method. The SQUARE model was subsequently baselined in a technical report (Mead et al., 2005a). Future plans include more extensive application by requirements engineers in an industrial setting and further tools development. There are also plans to incorporate more robust methods for developing security requirements, such as SQUARE, into international standards.

SQUARE.Tools A prototype tool called T-SQUARE has been developed to support SQUARE. It primarily provides an organizational framework for the artifact documents and Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



provides default content for some of the steps. At present, it does not perform sophisticated functions such as requirements analysis. The current plans call for extending the T-SQUARE user interface to be more inviting and to provide more value to the user. This could be achieved by producing a complete requirements document or providing analysis functionality.

RELATED. WORK Several usable approaches to security requirements engineering have been developed. A description of such approaches can be found in Chapter I and therefore it is not repeated here. This section is focused in providing a discussion of the SQUARE method in relation to the other approaches presented in the chapters of this book. The SQUARE work is consistent with some of the approaches presented in the other chapters of this book. For instance, the work by Fernandez et al. (Chapter V) in using misuse cases and attack patterns is consistent with SQUARE, where misuse cases and attack trees are used as part of the process. However, the Fernandez approach provides less detail, than the SQUARE, on how to use these speciically in the requirements area. Moreover, the approach presented in Chapter VI (by Weiss) on security patterns is consistent with SQUARE and could be used as part of the SQUARE process. Speciically security patterns could be used to help identify and document security requirements. The chapter by Houmb et al. (Chapter IX) addresses architecture and design tradeoffs. This would come after using a process like SQUARE to identify requirements. On the other hand, the TROPOS material by Giorgini et al. (Chapter VIII) is a self-contained lifecycle approach. It is not likely that an engineer would use both TROPOS and SQUARE. If they were using TROPOS they would use it throughout. The work by Koch et al. (Chapter X) is speciic to access control and UML. This is much more speciic than anything that we get into in SQUARE. Moreover, the approach presented by Haley et al. (Chapter II) is not inconsistent with SQUARE, in that the goals and some of the process steps are similar, but it is a different process for arriving at security requirements.

CONCLUSION The main focus of this chapter is the presentation of the SQUARE method, which can be used for eliciting, analyzing, and documenting security requirements for software systems. The method, has been developed by the CERT Program at Carnegie Mellon University’s Software Engineering Institute, and it has been used on a number of client projects by Carnegie Mellon student teams. To support the method, prototype tools have been developed. However, this work is not complete and research is ongoing to improve this promising method. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

.ACKNOWLEDGMENT This work would not have been possible without the help of the Carnegie Mellon University graduate students: Don Ojoko-Adams, Peter Chen, Lydia Chung, Marjon Dean, Daniel Gordon, Eric Hough, Frank Hung, Lilian Lopez, Hassan Osman, Ted Stehney, Neha Wattas, Ning (Nick) Xie, and Eugene Yu.

FUNDING

This project is inancially supported by the Software Engineering Institute, Cylab, and the Heinz School at Carnegie Mellon University.

REFERENCES

Alberts, C., Dorofee, A., & Woody, C. (2004). Considering operational security risks during systems development. Proceedings of the Software Engineering Process Group 2004 Conference. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Alexander, I. (2003). Misuse cases: Use cases with hostile intent. IEEE Software, 20, 58-66. American Supplier Institute. (1987). Quality function deployment: A collection of presentations and QFD case studies. Dearborn, MI: American Supplier. Bharadwaj, R. (2003). How to fake a rational design process using the SCR method. SEHAS’03 International Workshop on Software Engineering for High Assurance Systems. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Butler, S. (2002). Security attribute evaluation method: A cost-beneit approach. Proceedings of the 24th International Conference on Software Engineering (pp. 232-240). New York: ACM Press. Checkland, P. (1989). An application of soft systems methodology. In Rational Analysis for a Problematic World (pp. 101-119). New York: John Wiley & Sons. Chen, P., Mead, N. R., Dean, M., Lopez, L., Ojoko-Adams, D., Osman, H., & Xie, N. (2004). SQUARE methodology: Case study on asset management system (Rep. No. CMU/SEI-2004-SR-015). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu. edu/publications/documents/04.reports/04sr015.html Conklin, J., & Begeman, M. L. (1988). gIBIS: A hypertext tool for exploratory policy discussion. ACM Transactions on Ofice Information Systems, 6, 303-331. Cornford, S. L., Feather, M. S., & Hicks, K. A. (2004). DDP: A tool for life-cycle risk management. Retrieved November 9, 2005, from http://ddptool.jpl.nasa. gov/docs/f344d-slc.pdf Firesmith, D. G. (2003). Security use cases. Journal of Object Technology, 2, 53-64. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



Goguen, J. A., & Linde, C. (1993). Techniques for requirements elicitation. Proceedings of IEEE Requirements Engineering ‘93 (pp. 152-164). Gordon, D., Mead, N. R., Stehney, T., Wattas, N., & Yu, E. (2005). System quality requirements engineering (SQUARE) methodology: Case study on asset management system, Phase II (Rep. No. CMU/SEI-2005-SR-005). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/publications/documents/05.reports/05sr005.html Haimes, Y. (2004). Risk modeling, assessment, and management (Rev. ed.). Hoboken, NJ: John Wiley & Sons. Heninger, K. L. (1980). Specifying software requirements for complex systems: New techniques and their application. IEEE Transactions on Software Engineering SE-6, 2-13. Hubbard, R., Schroeder, C. N., & Mead, N. (2000). An assessment of the relative eficiency of a facilitator-driven requirements collection process with respect to the conventional interview method. ICRE 2000, 178-188. INFOSEC Assessment Methodology. (2004). INFOSEC assurance training and rating program. Retrieved November 9, 2005, from http://www.iatrp.com/iam.cfm Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., & Peterson, A. S. (1990). Featureoriented domain analysis (FODA) feasibility study (Rep. No. CMU/SEI-90-TR021,ADA235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/publications/documents /90.reports/90.tr.021.html Kunz, W., & Rittel, H. (1970). Issues as elements of information systems. Retrieved November 9, 2005 from http://www-iurd.ced.berkeley.edu/pub/WP-131.pdf Leiwo, J. (1999a). A mechanism for deriving speciications of security functions in the CC framework. The 10th International Workshop on Database and Expert Systems Applications. Berlin: Springer-Verlag. Leiwo, J., Gamage, C., & Zheng, Y. (1999b). Organizational modeling for eficient speciication of information security requirements. Advances in Databases and Information Systems: Third East European Conference, ADBIS’99 (pp. 247-260). Berlin: Springer-Verlag. Linger, R. C., Mead, N. R., & Lipson, H. F. (1998). Requirements deinition for survivable systems. Third International Conference on Requirements Engineering (pp. 14-23). Los Alamitos: IEEE Computer Society. Lipson, H. F., Mead, N. R., & Moore, A. P. (2001). A risk-management approach to the design of survivable cots-based systems. Retrieved November 9, 2005, from http://www.cert.org/research/isw/isw2001/papers/Lipson-29-08-a.pdf McDermott, J. (2001). Abuse-case-based assurance arguments. Proceedings of the 17th Annual Computer Security Applications Conference (pp. 366-374). Los Alamitos: IEEE Computer Society Press. McDermott, J., & Fox, C. (1999). Using abuse case models for security requirements analysis. Proceedings of the 15th Annual Computer Security Applications Conference (pp. 55-64). Los Alamitos, CA: IEEE Computer Society Press. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mead

Mead, N. (2004). Requirements elicitation and analysis processes for safety & security requirements. Paper presented at the meeting of the 4th International Workshop on Requirements for High Assurance Systems, Kyoto, Japan. Mead, N. R. (2002). Survivable systems analysis method. Retrieved November 9, 2005, from http://www.cert.org/archive/html/analysis-method.html Mead, N. R. (2003). Requirements engineering for survivable systems (Rep. No. CMU/SEI-2003-TN-013). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/publications/documents/03.reports/03tn013.html Mead, N. R., Hough, E., & Stehney, T. (2005a). Security quality requirements engineering (SQUARE) methodology (Rep. No. CMU/SEI-2005-TR-009). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/publications/documents/05. reports/05tr009.html Mead, N. R., & Stehney, T. (2005b). Security quality requirements engineering (SQUARE) methodology. Paper presented at the meeting of the Software Engineering for Secure Systems (SESS05), ICSE 2005 International Workshop on Requirements for High Assurance Systems, St. Louis, MO. Moore, A. P., Ellison, R. J., & Linger, R. C. (2001). Attack modeling for information security and survivability (Rep. No. CMU/SEI-2001-TN-001, ADA388771). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/publications/documents/01. reports/01tn001.html Mullery, G. P. (1979). CORE: A method for controlled requirements speciication. Proceedings of the 4th International Conference on Software Engineering. Los Alamitos: IEEE Computer Society Press. National Institute of Standards and Technology (NIST). (2002). Software errors cost U.S. economy $59.5 billion annually (Rep. No. NIST 2002-10). Gaithersburg: National Institute of Standards and Technology. Retrieved November 9, 2005, from http://www.nist.gov/public_affairs/releases/n02-10.htm Ortalo, R. (1998). A lexible method for information system security policy speciication. Proceedings of the 5th European Symposium on Research in Computer Security (pp. 67-84). Berlin: Springer-Verlag. QFD Institute. (2005). Frequently asked questions about QFD. Retrieved November 9, 2005, from http://www.qfdi.org/what_is_qfd/faqs_about_qfd.htm Sabatier, D., & Lartigue, P. (1999). The use of the B formal method for the design and validation of the transaction mechanism for smart card applications. In FM ’99: World Congress on Formal Methods (Vol. 1, pp. 348-368). Berlin: Springer-Verlag. Schiffrin, D. (1994). Approaches to discourse. Oxford: Blackwell. Schneier, B. (2000). Secrets and lies: Digital security in a networked world. New York: John Wiley & Sons. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

The SQUARE Method



Sindre, G., & Opdahl, A. (2000). Eliciting security requirements by misuse cases. Proceedings of TOOLS Paciic 2000 (pp. 120-130). Los Alamitos: IEEE Computer Society Press. Sindre, G., Opdahl, S., & Brevik, G. (2002). Generalization/specialization as a structuring mechanism for misuse cases. In SREIS 2002, Second Symposium on Requirements Engineering for Information Security. Lafayette: CERIAS. Software Engineering Institute. (2004). International Workshop on Requirements for High Assurance Systems. Pittsburgh, PA: Carnegie Mellon University. Soo Hoo, K., Sudbury, A. W., & Jaquith, A. R. (2001). Tangible ROI through secure software engineering. Secure Business Quarterly, 1. Stoneburner, G., Goguen, A., & Feringa, A. (2002). Risk management guide for information technology systems (Rep. No. 800-30). Gaithersburg: National Institute of Standards and Technology. Retrieved November 9, 2005, from http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf Systems Designers Scientiic. (1985). CORE: The method. In CORE Manual, 1.0. Camberley: Pembroke House. U.S. General Accounting Ofice. (1999). Information security risk assessment: Practices of leading organizations, a supplement to GAO’s May 1998 executive guide on information security management. Washington, DC: U.S. General Accounting Ofice. Wood, J., & Silver, D. (1989). Joint application design: How to design quality systems in 40% less time. New York: Wiley. Woody, C. (2005). Eliciting and analyzing quality requirements: Management inluences on software quality requirements (Rep. No. CMU/SEI-2005-TN010). Pittsburgh, PA: Software Engineering Inst., Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/publications/documents/05. reports/05tn010.html Woody, C, Hall, A., & Clark, J. (2004). Can secure systems be built using today’s development processes? Panel presented at the European SEPG, London. Xie, N., Mead, N. R., Chen, P., Dean, M., Lopez, L., Ojoko-Adams, D., & Osman, H. (2004). SQUARE project: Cost/beneit analysis framework for information security improvement projects in small companies (Rep. No. CMU/SEI-2004TN-045). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/publications/documents/04. reports/04tn045.html

ENDNOTES 1

2

Acme Corporation (Acme) is an alias used to protect the identity of the client under study. Asset Management System (AMS) is an alias used to protect the identity of the client under study.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Yu, Liu, & Mylopoulos

Chapter.IV

A.Social.Ontology.for. Integrating.Security.and. Software.Engineering E. Yu, University of Toronto, Canada L. Liu, Tsinghua University, China J. Mylopoulos, University of Toronto, Canada

ABSTRACT As software becomes more and more entrenched in everyday life in today’s society, security looms large as an unsolved problem. Despite advances in security mechanisms and technologies, most software systems in the world remain precarious and vulnerable. There is now widespread recognition that security cannot be achieved by technology alone. All software systems are ultimately embedded in some human social environment. The effectiveness of the system depends very much on the forces in that environment. Yet there are few systematic techniques for treating the social context of security together with technical system design in an integral way. In this chapter, we argue that a social ontology at the core of a requirements engineering process can be the basis for integrating security into a requirements driven software engineering process. We describe the i* agent-oriented modelling framework and show how it can be used to model and reason about security concerns and responses. A smart card example is used to illustrate. Future directions for a social paradigm for security and software engineering are discussed. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



INTRODUCTION It is now widely acknowledged that security cannot be achieved by technological means alone. As more and more of our everyday activities rely on software, we are increasingly vulnerable to lapses in security and deliberate attacks. Despite ongoing advances in security mechanisms and technologies, new attack schemes and exploits continue to emerge and proliferate. Security is ultimately about relationships among social actors — stakeholders, system users, potential attackers — and the software that are instruments of their actions. Nevertheless, there are few systematic methods and techniques for analyzing and designing social relationships as technical systems alternatives are explored. Currently, most of the research on secure software engineering methods focuses on the technology level. Yet, to be effective, software security must be treated as originating from high-level business goals that are taken seriously by stakeholders and decision makers making strategic choices about the direction of an organisation. Security interacts with other high-level business goals such as quality of service, costs, time-to-market, evolvability and responsiveness, reputation and competitiveness, and the viability of business models. What is needed is a systematic linkage between the analysis of technical systems design alternatives and an understanding of their implications at the organisational, social level. From an analysis of the goals and relationships among stakeholders, one seeks technical systems solutions that meet stakeholder goals. In this chapter, we describe the i* agent-oriented modelling framework and how it can be used to treat security as an integral part of software system requirements engineering. The world is viewed as a network of social actors depending on each other for goals to be achieved, tasks to be performed, and resources to be furnished. Each actor reasons strategically about alternate means for achieving goals, often through relationships with other actors. Security is treated as a high-level goal held by (some) stakeholders that need to be addressed from the earliest stages of system conception. Actors make tradeoffs among competing goals such as functionality, cost, time-to-market, quality of service, as well as security. The framework offers a set of security requirements analysis facilities to help users, administrators, and designers better understand the various threats and vulnerabilities they face, the countermeasures they can take, and how these can be combined to achieve the desired security results within the broader picture of system design and the business environment. The security analysis process is integrated into the main requirements process, so that security is taken into account from the earliest moment. The technology of smart cards and the environment surrounding its usage provides a good example to illustrate the social ontology of i*. In the next section, we review the current challenges in achieving security in software systems, motivating the need for a social ontology. Given that a social modelling and analysis approach is needed, what characteristics should it have? We consider this in the following section. The two subsequent sections describe Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

the ontology of the i* strategic actors modelling framework and outline a process for analyzing the security issues surrounding a smart card application. The last section reviews several areas of related work and discusses how a social ontology framework can be complementary to these approaches.

BACKGROUND Despite ongoing advances in security technologies and software quality, new vulnerabilities continue to emerge. It is clear that there can be no perfect security. Security inevitability involves tradeoffs (Schneier, 2003). In practice, therefore, all one can hope for is “good enough” security (Sandhu, 2003). But how does one determine what is good enough? Who decides what is good enough? These questions suggest that software and information security cannot be addressed by technical specialists alone. Decisions about security are made ultimately by stakeholders — people who are affected by the outcomes — users, investors, the general public, etc. — because the tradeoffs are about how their lives would be affected. In electronic commerce, consumers decide whether to purchase from a vendor based on the trustworthiness of the vendor’s business and security practices. Businesses decide how much and where to invest on security to reduce exposure to a tolerable level. In healthcare, computerized information management can streamline many processes. But e-health will become a reality only if patients and the general public are satisied that their medical records are protected and secure. Healthcare providers will participate only if liability concerns can be adequately addressed. Tradeoffs are being made by participants regarding competing interests and priorities. Customers and businesses make judgments about what is adequate security for each type of business, in relation to the beneits derived from online transactions. Patients want their personal and medical information to be kept private, but do not want privacy mechanisms to interfere with the quality of care. In national defense, secrecy is paramount, but can also lead to communication breakdown. In each case, security needs to be interpreted within the context of the social setting, by each stakeholder from his/her viewpoint. Current approaches to security do not allow these kinds of tradeoffs to be conveyed to system developers to guide design. For example, UML extensions for addressing security (see Chapter I for a review) do not lend themselves well to the modelling of social actors and their concerns about alternate security arrangements, and how they reason about tradeoffs. Access control models can specify policies, but cannot support reasoning about which policies are good for whom and what alternate policies might be more workable. They cannot explain why certain policies meet with resistance and non-compliance. Each of the common approaches in security modelling and analysis focuses on selective aspects of security, which are important in their own right, but cannot provide the guidance needed to achieve “good enough” overall security. Most apCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



proaches focus on technical aspects, neglecting the social context, which is crucial for achieving effective security in practice. The technical focus is well served by mechanistic ontology (i.e., concepts that are suitable for describing and reasoning about automated machinery — objects, operations, state transitions, etc.). The importance of social context in security suggests that a different set of concepts is needed. From the previous discussion, we propose that the following questions are important for guiding system development in the face of security challenges: • • • • • •

Who are the players who have an interest in the intended system and its surrounding context? Who would be affected by a change? What are their strategic interests? What are their business and personal objectives? What do they want from the system and the other players? What are the different ways in which they can achieve what they want? How do their interests complement or interfere with each other? How can players achieve what they want despite competing or conlicting interests? What opportunities exist for one player to advance its interests at the expense of others? What vulnerabilities exist in the way that each actor envisions achieving its objectives? How can one player avoid or prevent its interests from being compromised by others?

These are the kind of questions that can directly engage stakeholders, helping them uncover issues and concerns. Stakeholders need the help of technical specialists to think through these questions, because most strategic objectives are accomplished through technological systems. Stakeholders typically do not know enough about technology possibilities or their implications. Technologists do not know enough about stakeholder interests to make choices for them. In order that stakeholder interests can be clariied, deliberated upon, and conveyed effectively to system developers, a suitable modelling method is needed to enable stakeholders and technologists to jointly explore these questions. The answers to these questions will have direct impact on system development, as they set requirements and guide technical design decisions. We argue therefore that a social ontology is needed to enable security concerns to become a driving force in software system development. In the next section, we explore the requirements for such a social ontology.

APPROACH If a treatment of security requires attention to the social context of software systems, can the social analysis be given full weight in a software engineering methodology that is typically dominated by a mechanistic worldview? How can the social modelling be reconciled and integrated with mainstream software modelling? Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

It turns out that a social paradigm for software system analysis is motivated not only by security concerns, but is consistent with a general shift in the context of software and information systems. The analysis of computers and information systems used to be machine-centric when hardware was the precious resource. The machine was at the centre, deining the human procedures and structures needed to support its proper functioning. Today, hardware and software are commoditized and distributed everywhere. Human practices and imagination determine how hardware and software are put to use, not the other way round. Pervasive networking, wired and wireless, has also contributed to blurring the notion of “system.” Computational resources can be dynamically harnessed in ad hoc conigurations (e.g., through Web services protocols in service-oriented architectures) to provide end-to-end services for a few moments, then dissolved and reconigured for another ad hoc engagement. Even computational entities, in today’s networked environment, are better viewed as participants in social networks than as ixed components in a system with predeined structure and boundary. Increasingly, the computational services that we desire will not be offered as a single pre-constructed system, but by a conglomeration of interacting services operated by different organisations, possibly drawing on content owned by yet other providers. The questions raised in the previous section arise naturally from today’s open networked environments, even if one were not focusing on security concerns. The relevance of a social ontology is therefore not unique to security. Competing interests and negative forces that interfere with one’s objectives are ever present in every organisation and social setting. They are accentuated in an open network environment. In security scenarios, the negative forces are further accentuated as they materialize into full-ledged social structures, involving malicious actors collaborating with other actors, engaging in deliberate attacks, possibly violating conventions, rules, and laws. Security can therefore be seen as covering the more severe forms of a general phenomenon. Competing and conlicting interests are inherent in social worlds. Negative forces do not come only from well identiied malicious external agents, but can be present legitimately within one’s organisation, among one’s associates, and even among the multiple roles that one person may play. It may not be possible to clearly separate security analysis from the analysis of “normal” business. We conclude, therefore, that a social ontology would serve well for “normal” business analysis, recognizing the increasingly “social” nature of software systems and their environments. A social ontology offers a smooth integration of the treatment of normal and security scenarios, as the latter merely refer to one end of a continuum covering positive and negative forces from various actors. Given this understanding, the social ontology should not be preoccupied with those concepts conventionally associated with security. For example, the concepts of asset, threat, attack, counter-measure are key concepts for security management. In the social ontology we aim to construct, we do not necessarily adopt these as primitive concepts. Instead, the social ontology should aim to be as general as posCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



sible, so that the concepts may be equally applicable to positive as well as negative scenarios. The general ontology is then applied to security. Special constructs unique to security would be introduced only if the expressiveness of the general constructs is found to be inadequate. The principle of Occam’s razor should be applied to minimize the complexity of the ontology. If desired, shorthand notations for common recurring patterns can be deined in terms of the primitives. The premises behind a social ontology are further discussed in Yu (2001a, 2001b).

BASIC. CONCEPTS. OF. THE. i*. STRATEGIC. MODELLING. FRAMEWORK The i* framework (Yu, 1993, 1997) proposes an agent oriented approach to requirements engineering centering on the intentional characteristics of the agent. Agents attribute intentional properties such as goals, beliefs, abilities, commitments to each other and reason about strategic relationships. Dependencies give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning approach. Agents consider alternative conigurations of dependencies to assess their strategic positioning in a social context. The name i* (pronounced eye-star) refers to the concept of multiple, distributed “intentionality.” The framework is used in contexts in which there are multiple parties (or autonomous units) with strategic interests, which may be reinforcing or conlicting in relation to each other. The i* framework has been applied to business process modelling (Yu, 1993), business redesign (van der Raadt, Gordijn, & Yu, 2005; Yu et al., 2001), requirements engineering (Yu, 1997), architecture modelling (Gross & Yu, 2001), COTS selection (Franch & Maiden, 2003), as well as to information systems security. There are three main categories of concepts: actors, intentional elements, and intentional links. The framework includes a strategic dependency (SD) model — for describing the network of relationships among actors, and a strategic rationale (SR) model — for describing and supporting the reasoning that each actor has about its relationships with other actors.

Actor. In i*, an actor ( ) is used to refer generically to any unit to which intentional dependencies can be ascribed. An actor is an active entity that carries out actions to achieve its goals by exercising means-ends knowledge. It is an encapsulation of intentionally, rationality and autonomy. Graphically, an actor is represented as a circle, and may optionally have a dotted boundary, with intentional elements inside.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

Intentional.Elements:.Goal,.Softgoal,.Task,.Resource.and. Belief The intentional elements in i* are goal, task, softgoal, resource and belief. A goal ( ) is a condition or state of affairs in the world that the stakeholders would like to achieve. A goal can be achieved in different ways, prompting alternatives to be considered. A goal can be a business goal or a system goal. Business goals are about the business or state of the affairs the individual or organisation wishes to achieve in the world. System goals are about what the target system should achieve, which, generally, describe the functional requirements of the target system. In the i* graphical representation, goals are represented as a rounded rectangle with the goal name inside. A softgoal ( ) is typically a quality (or non-functional) attribute on one of the other intentional elements. A softgoal is similar to a (hard) goal except that the criteria for whether a softgoal is achieved are not clear-cut and a priori. It is up to the developer to judge whether a particular state of affairs in fact suficiently achieves the stated softgoal. Non-functional requirements, such as performance, security, accuracy, reusability, interoperability, time to market and cost are often crucial for the success of a system. In i*, non-functional requirements are represented as softgoals and addressed as early as possible in the software lifecycle. They should be properly modelled and addressed in design reasoning before a commitment is made to a speciic design choice. In the i* graphical representation, a softgoal is shown as an irregular curvilinear shape. Tasks ( ) are used to represent the speciic procedures to be performed by agents, which speciies a particular way of doing something. It may be decomposed into a combination of subgoals, subtasks, resources, and softgoals. These sub-components specify a particular course of action while still allowing some freedom. Tasks are used to incrementally specify and reine solutions in the target system. They are used to achieve goals or to “operationalize” softgoals. These solutions provide operations, processes, data representations, structuring, constraints, and agents in the target system to meet the needs stated in the goals and softgoals. Tasks are represented graphically as a hexagon. A resource ( ) is a physical or informational entity, which may serve some purpose. From the viewpoint of intentional analysis, the main concern with a resource is whether it is available. Resources are shown graphically as rectangles. The belief ( ) construct is used to represent domain characteristics, design assumptions and relevant environmental conditions. It allows domain characteristics to be considered and properly relected in the decision making process, hence facilitating later review, justiication, and change of the system, as well as enhancing traceability. Beliefs are shown as ellipses in i* graphical notation.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Strategic.Dependency.Model A strategic dependency (SD) model consists of a set of nodes and links. Each node represents an actor, and each link between two actors indicates that one actor depends on the other for something in order that the former may attain some goal. We call the depending actor the depender, and the actor who is depended upon the dependee. The object around which the dependency relationship centers is called the dependum. By depending on another actor for a dependum, an actor (the depender) is able to achieve goals that it was not able to without the dependency, or not as easily or as well. At the same time, the depender becomes vulnerable. If the dependee fails to deliver the dependum, the depender would be adversely affected in its ability to achieve its goals. A dependency link ( ) is used to describe such an inter-actor relationship. Dependency types are used to differentiate the kinds of freedom allowed in a relationship. In a goal dependency, an actor depends on another to make a condition in the world come true. Because only an end state or outcome is speciied, the dependee is given the freedom to choose how to achieve it. In a task dependency, an actor depends on another to perform an activity. The depender’s goal for having the activity performed is not given. The activity description speciies a particular course of action. A task dependency speciies standard procedures, indicates the steps to be taken by the dependee. In a resource dependency, an actor depends on another for the availability of an entity. The depender takes the availability of the resource to be unproblematic. The fourth type of dependency, softgoal dependency, is a variant of the goal dependency. It is different in that there are no a priori, cut-and-dry criteria for what constitutes meeting the goal. The meaning of a softgoal is elaborated in terms of the methods that are chosen in the course of pursuing the goal. The dependee contributes to the identiication of alternatives, but the decision is taken by the depender. The notion of the softgoal allows the model to deal with many of the usually informal concepts. For example, a service provider’s dependency on his customer for continued business can be achieved in different ways. The desired style of continued business is ultimately decided by the depender. The customer’s softgoal dependency on the service provider for “keep personal information conidential” indicates that there is not a clear-cut criterion for the achievement of conidentiality. The four types of dependencies relect different levels of freedom that is allowed in the relationship between depender and dependee. Figure 1 shows a SD model for a generic smart card-based payment system involving six actors. This example is adapted from Yu and Liu (2001). A Card Holder depends on a Card Issuer to be allocated a smart card. The Terminal Owner depends on Card Holder to present the card for each transaction. The Card Issuer in turn depends on the Card Manufacturer and Software Manufacturer to provide cards, devices, and software. The Data Owner is the one who has control of the data within the card. He depends on the Terminal Owner to submit transaction Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

information to the central database. In each case, the dependency means that the depender actor depends on the dependee actor for something in order to achieve some (internal) goal. The goal dependency New Account Be Created from the Card Issuer to the Data Owner means that it is up to the Data Owner to decide how to create a new account. The Card Issuer does not care how a new account is created; what matters is that, for each card, an account should be created. The Card Issuer depends on the Card Holder to apply for a card via a task dependency by specifying standard application procedures. If the Card Issuer were to indicate the steps for the Data Owner to create a new account, then the Data Owner would be related to the Card Issuer by a task dependency instead. The Card Issuer’s dependencies on the Card Manufacturer for cards and devices, the manufacturer’s dependencies on Card Issuer for payment are modelled as resource dependencies. Here the depender takes the availability of the resource to be unproblematic. The Card Holder’s softgoal dependency on the Card Issuer for Keep Personal Information Conidential indicates that there is not a clear-cut criterion for the achievement of conidentiality. In the Manufacturer’s softgoal dependency on Card Issuer, Continued Business could be achieved in different ways. The desired style of continued business is ultimately decided by the depender. The strategic dependency model of Figure 1 is not meant to be a complete and accurate description of any particular smart card system. It is intended only for illustrating the modelling features of i*. In conventional software systems modelling, the focus is on information lows and exchanges — what messages actors or system components send to each other. With the social ontology of i*, the focus is on intentional relationships — what are the actors’ expectations and constraints on each other. Since actors are intentional, Figure 1. Strategic dependency model of a generic smart card system

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



strategic, and have autonomy, they relect on their relationships with other actors. If these relationships are unsatisfactory, they will seek alternative ways of associating with others. Security concerns arise naturally from this perspective. A social ontology therefore provides a way to integrate security into software system engineering from the earliest stages of conception, and at a high level of abstraction.

Intentional.Links. Dependencies are intentional relationships between actors. Within each actor, we model intentional relationships in terms of means-ends, decomposition, contribution, and correlation links. • •

•

Means-ends links ( ) are used to describe how goals can be achieved. Each task connected to a goal by a means-ends link is one possible way of achieving the goal. Decomposition links ( ) deine the sub-elements of a task, which can include sub-tasks, sub-goals, resources, and softgoals. The softgoals indicate the desired qualities that are considered to be part of the task. The sub-tasks may in turn have decomposition links that lead to further sub-elements. Sub-goals indicate the possibility of alternate means of achievement, with means-ends links leading to tasks. A contribution link (→) describes the qualitative impact that one element has on another. A contribution can be negative or positive. The extent of contribution is judged to be partial or suficient based on Simon's concept of satisicing (Simon, 1996), as in the NFR framework (Chung, Nixon, Yu, & Mylopoulos, 2000). Accordingly, contribution link types include: help (positive and partial), make (positive and suficient), hurt (negative and partial), break (negative and suficient), some+ (positive of unknown extent), some- (negative of unknown extent). Correlation links (dashed arrows) are used to express contributions from one element to other elements that are not explicitly sought, but are side effects.

Strategic.Rationale.Model The strategic rationale (SR) model provides a detailed level of modelling by looking “inside” actors to model internal intentional relationships. Intentional elements (goals, tasks, resources, and softgoals) appear in SR models not only as external dependencies, but also as internal elements arranged into a predominantly hierarchical structure of means-ends, task-decompositions and contribution relationships. The SR model in Figure 2 elaborates on the rationale of a Card Manufacturer. The Card Manufacturer’s business objective Manufacture Card Hardware is modeled as a “hard” functional goal (top right corner). Quality requirements such as Security Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Yu, Liu, & Mylopoulos

Figure 2. Strategic rationale model of card manufacturer

and Low Cost are represented as softgoals. The different means for accomplishing the goal are modeled as tasks. The task Provide Total Card Solution can be further decomposed into three sub-components (connected with task-decomposition links): sub-goal of Get Paid, sub-task Develop Card Solution, and sub-task Manufacture Card & Devices. To perform the task Manufacture Card & Devices, the availability of Materials need to be taken into consideration, which is modeled as a resource. In the model, task node Provide Simple Card Solution (such as the Millicent solution), and Provide Total Card Solution (such as the Mondex solution) are connected to the goal with means-ends links. This goal will be satisied if any of these tasks is satisied. Provide Total Card Solution will help the Security of the system (represented with a Help contribution link to Security), while Provide Simple Card Solution is considered to have no signiicant impact on security if it is applied to cards with small monetary value. The Simple Card Solution is good for the goal of Low Cost whereas the Total Card Solution is bad. This is supported by the belief that “Total Card Solution, such as Mondex, is expensive.” Beliefs are usually used to represent such domain properties, or design assumption or environmental condition, so that traceability of evidence of design decision could be explicitly maintained with the model. During system analysis and design, softgoals such as Low Cost and Security [card] are systematically reined until they can be operationalized and implemented. Unlike functional goals, nonfunctional qualities represented as softgoals frequently interact or interfere with each other, so the graph of contributions is usually not a strict tree structure (Chung et al., 2000). Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Agents,.Roles,.and.Positions

To model complex relationships among social actors, we further deine the concepts of agents, roles, and positions, each of which is an actor, but in a more specialized sense. A role ( ) is an abstract actor embodying expectations and responsibilities. It is an abstract characterization of the behavior of a social actor within some specialized context or domain of endeavor. An agent ( ) is a concrete actor with physical manifestations, human or machine, with speciic capabilities and functionalities. A set of roles packaged together to be assigned to an agent is called a position. A position ( ) is intermediate in abstraction between a role and an agent, which often has an organisational lavor. Positions can COVER roles. Agents can OCCUPY positions. An agent can PLAY one or more roles directly. The INS construct is used to represent the instance-and-class relation. The ISA construct is used to express conceptual generalization/specialization. Initially, human actors representing stakeholders in the domain are identiied together with existing machine actors. As the analysis proceeds, more actors are identiied, including new system agents, when certain design choices have been made, and new functional entities are added. Figure 3 shows some actors in the domain. At the top, six generic abstract roles are identiied, including the Card Holder, the Terminal Owner, the Data Owner, the Card Issuer, the Card Manufacturer, and the Software Manufacturer. These actors are modeled as roles since they represent abstractions of responsibilities and functional units of the business model. Then concrete agents in smart card systems are identiied. For instance, actors in a Digital Stored Value Card system include Customer, Merchant, Subcontractor Company, and their instances. These agents can play one or more roles in different smart card systems. Here, Financial Institution is modeled as a position that bridges the multiple abstract roles it covers, and the real world agents occupying it. Initially, human/organisational actors are identiied together with existing machine actors. As the requirements analysis proceeds, more actors could be added in, including new system agents such as security monitoring system, counter-forgery system, etc., when certain design choices have been made, and new functional entities are added. An agent is an actor with concrete, physical manifestations, such as a human individual. An agent has dependencies that apply regardless of what role he/she/it happens to be playing. For example, in Figure 3, if Jerry, a Card Holder desires a good credit record, he wants the credit record to go towards his personal self, not to the positions and abstract roles that Jerry might occupy or play. We use the term agent instead of person for generality, so that it can be used to refer to human as well as artiicial (hardware, software, or organisational) agents. Customer and Merchant are represented as agent classes and groups. Dependencies are associated with a role when these dependencies apply regardless of who plays the role. For example, we consider Card Holder an abstract role that agents can play. The objective of obtaining possession of the card, and deciding when and whether to use it, are associated with the role, no matter who plays the role. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

Figure 3. Actor hierarchy (roles, positions, and agents) in a smart card system

The INS construct represents the instance-and-class relation. For example, Mr. Lee’s Convenience Store is an instance of Merchant, and Jerry is an instance of Customer. The ISA construct expresses conceptual generalization/ specialization. For example, a Subcontractor Company is a kind of Technical Company. These constructs are used to simplify the presentation of strategic models with roles, positions, and agents. There can be dependencies from an agent to the role it plays. For example, a Merchant who plays the role of Terminal owner may depend on that role to attract more customers. Otherwise, he may choose not to play that role. Roles, positions, and agents can each have subparts. In general, aggregate actors are not compositional with respect to intentional properties. Each actor, regardless of whether it has parts, or is part of a larger whole, is taken to be intentional. Each actor has inherent freedom and is therefore ultimately unpredictable. There can be intentional dependencies between the whole and its parts (e.g., a dependency by the whole on its parts to maintain unity).

DOMAIN. REQUIREMENTS.ANALYSIS. WITH. i* We now illustrate how the social ontology of i* allows security issues to be identiied and addressed early in the requirements process. We continue with the example of smart card systems design. Security in smart card systems is a challenging task due to the fact that different aspects of the system are not under a single trust boundary. Responsibilities are split among multiple parties. The processor, I/O, data, programs, and network may be controlled by different, and potentially hostile, parties. By discussing the security ramiications of different ways of splitting responsibilities, we aim to show how the proposed modelling framework can help produce a proper understanding of the security systems that employ smart cards. Figure 4 shows the basic steps to take during the process of domain requirements analysis with i*, before we consider security. The process can be organised into the following iterative steps. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Figure 4. Requirements elicitation process with i*

(1).Actor.Identification.

(5

(3

(2).Goal/Task.Identification.

(4) Dependency.Identification.

Figure 5. Security requirements elicitation process with i*

(1)Actor Identification

(3)

Attacker Identification [1]

(2)Goal/Task Identification

Malicious Intent Identification [2] (5) (4)Dependency Identification

Vulnerability Analysis[3]

[7]

Attacking Measure Identification[4]

[6]

Countermeasure Identification[5]

Figure 5

Actor Identiication In step (1), the question “who is involved in the system?” will be answered. According to the deinition given above, we know that all intentional units may be represented as actors. For example, in any smart card based systems, there are many parties involved. An actor hierarchy composed of roles, positions, and agents such as the ones in Figure 3 is created.

Goal/Task Identiication In the step (2) of the requirements analysis process, the question “what does the actor want to achieve?” will be answered. As shown in the strategic rationale (SR) Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

model of Figure 2, answers to this question can be represented as goals capturing the high-level objectives of agents. During system analysis and design, softgoals such as low cost and security are systematically reined until they can be operationalized and implemented. Using the SR model, we can reason about each alternative’s contributions to high-level non-functional quality requirements including security, and possible tradeoffs. The reinements of goals, tasks and softgoals (step (3) in Figure 4) are considered to have reached an adequate level once all the necessary design decisions can be made based on the existing information in the model. The SR model in Figure 3 was created by running through steps (1), (2), (3) in Figure 4 iteratively.

Strategic Dependency Identiication In the step (4) of the requirements analysis process, the question “how do the actors relate to each other?” will be answered. Figure 1 shows the SD model for a generic smart card-based payment system. By analyzing the dependency network in a Strategic Dependency model, we can reason about opportunities and vulnerabilities. A Strategic Dependency model can be obtained by hiding the internal rationales of actors in a Strategic Rationale model. Thus, the goal, task, resource, softgoal dependencies in a Strategic Dependency model can be seen as originating from SR models. The kinds of analysis shown above answers questions such as “who is involved in the system? What do they want? How can their expectations be fulilled? And what are the inter-dependencies between them?” These answers initially provide a sketch of the social setting of the future system, and eventually result in a fairly elaborate behavioral model where certain design choices have already been made. However, another set of very important questions has yet to be answered (i.e., what if things go wrong)? What if some party involved in the smart card system does not behave as expected? How bad can things get? What prevention tactics can be considered?” These are exactly the questions we want to answer in the security requirements analysis.

SECURITY. REQUIREMENTS.ANALYSIS. WITH. i*. We now extend the process to include attacker analysis, vulnerability analysis, and countermeasure analysis. The dashed lines and boxes on the right hand side of Figure 5 indicate a series of analysis steps to deal with security. These steps are integrated into the basic domain requirements engineering process, such that threats from potential attackers are anticipated and countermeasures for system protection are sought and equipped wherever necessary. Each of the security related analysis steps (step [1] to [7]) will be discussed in detail in the following subsections. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Attacker.Analysis. The attacker analysis steps aim to identify potential system abusers and their malicious intents. The basic premise here is that all the actors are assumed “guilty until proven innocent.” In other words, given the result of the basic i* requirements modelling process, we now consider any one of the actors (roles, positions, or agents) identiied so far can be a potential attacker to the system or to other actors. For example, we want to ask, “In what ways can a terminal owner attack the system? How will he beneit from inappropriate manipulation of the card reader, or transaction data?” In this analysis, each actor is considered in turn as an attacker. This attacker inherits the intentions, capabilities, and social relationships of the corresponding legitimate actor (i.e., the internal goal hierarchy and external dependency relationships in the model). This may serve as a starting point of a forward direction security analysis (step [1] in Figure 5). A backward analysis starting from identifying possible malicious intents and valuable business assets can also be done. Proceeding to step [2] of the process, for each attacker identiied, we combine the capabilities and interests of the attacker with those of the legitimate actor. For simplicity, we assume that an attacker may be modeled as a role or an agent. To perform the attacker analysis, we consider that each role may be played by an attacker agent, each position may be occupied by an attacker agent, and that each agent may play an attacker role (Figure 6). The analysis would then reveal the commandeering of legitimate resources and capabilities for illicit use. The intents and strategies of the attackers are explicitly represented and reasoned about in the models. This approach treats all attackers as insider attackers, as attacks are via associations with normal actors. We set a system boundary, then exhaustively search for possible attackers. Random attackers such as Internet hackers/crackers, or attackers breaking into a building can also be dealt with by being represented as sharing the same territory with their victim. By conducting analysis on the infrastructure of

Figure 6. Modelling attackers in strategic actors model

⇒ ⇒ ⇒ Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

Figure 7. Motives of attacker in a smart card system

the Internet, we may identify attackers by treating Internet resources as resources in the i* model. By conducting building security analysis, break-in attackers, or attackers sharing the same workspace can be identiied. Alternatively, we could adopt an opposite assumption, i.e., assume there is a trusted perimeter for each agent, all the potential threat sources within this trusted perimeter are ignored, measures will only be taken to deal with threats from outside of the perimeter. As shown in the Strategic Rationale model in Figure 7, the motives of Attacker in the smart card system may be modeled as intentional elements in an i* model. An attacker may be motivated by inancial incentives (softgoal Be Proitable), or by non-inancial ones (e.g., Desire for Notoriety). These malicious intents may lead to various attack strategies, such as Financial Theft, Impersonation Attack, Gain Unauthorized Access, Attack on Privacy, and Publicity Attack.

Dependency.Vulnerability.Analysis. Dependency vulnerability analysis aims at identifying the vulnerable points in the dependency network (step [3] in Figure 5). A dependency relationship makes the depender inherently vulnerable. Potential attackers may exploit these vulnerabilities to actually attack the system, so that their malicious intents can be served. i* dependency modelling allows a more speciic vulnerability analysis because the potential failure of each dependency can be traced to a depender and to its dependers. The questions we want to answer here are “which dependency relationships are vulnerable to attack?”, “What are the chain effects if one dependency link is compromised?” The analysis of dependency vulnerabilities does not end with the identiication of potential vulnerable points. We need to trace upstream in the dependency network, and see whether the attacked dependency relationship impacts other actors in the network. Figure 8 is a simpliied version of the SD model of Figure 4, showing only the softgoal dependencies. We assume that each of the actors in the SD model can be a potential attacker. And as an attacker, an actor will fail to deliver the expected dependencies directed to it, of whom it is the dependee. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Figure 8. Dependencies (in other words, vulnerable points) in a smart card system

For instance, the Card Holder depends on the Terminal Owner to Read/Write Card Correctly. To analyze the vulnerability arising from this dependency, we consider the case where the terminal owner is not trustworthy. And we try to identify the potential attacks by answering question of “In what possible ways could the attacker break this dependency relationship?” To do this, we elaborate on the agent Attacker Playing Terminal Owner. Starting from attacker’s potential motivations, we reine the high-level goals of the attackers (and possible attack routes) based on analysis of the SD and SR models of the normal operations of the smart card (e.g., what resources an actor accesses, what types of interactions exist, etc.). In this way, we may identify a number of potential attacks that are suficient to make this dependency not viable (Break). Proceeding to step [4], we now focus on how an attacker may attack the vulnerable points identiied above by exploring the attacker’s capacities. We model potential attacks (including fraud) as negative contributions from the attackers (from their speciic methods of attack) toward the dependee-side dependency link. A Break contribution indicates that the attack is suficient to make the softgoal unviable. For clarity of analysis, we place the attack-related intentional elements into agents called “Attacker Playing Role X.” Details of the attack methods (e.g., Steal Card Information, Send Falsiied Records) can be elaborated by further means-ends and decomposition analysis. Thus, the steps and methods of the attack can be modeled and analyzed. Other internal details of the Terminal Owner are not relevant and are thus not included in the model. Negative contribution links are used

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

Figure 9. Attacks directed to vulnerable dependencies in a smart card system

to show attacks on more speciic vulnerabilities of the depender (e.g., reinements of Transact with Card). The dependencies that could be broken are highlighted with a small square in Figure 9. When a dependency is compromised, the effect could propagate through the dependency network upstream along the dependency links. For example, if the Terminal Owner is not Quickly Be Paid, he may stop accepting card as a payment option.

Countermeasure.Analysis During countermeasure analysis, system designers make decisions on how to mitigate vulnerabilities and set up defenses against potential attackers. This type of analysis covers general types of attacks, and formulates solutions by selectively applying, combining, or instantiating prototypical solutions to address the speciic needs of various stakeholders. The general types of attacks and the prototypical solutions can be retrieved from a taxonomy or knowledge repository. Necessary factors for the success of an attack are attacker’s motivations, vulnerabilities of the system, and attacker’s capabilities to carry out the attack. Thus, to counteract a hypothetical attack, we seek measures that will suficiently negate these factors. Based on the above analysis, we already understand the attackers’ possible malicious intents and system vulnerabilities. As shown in Figure 5, countermeasure Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Figure 10. Resistance models defeating hypothetical attacks

analysis is an iterative process. Adding protective measures may bring new vulnerabilities to the system, so a new round of vulnerability analysis and countermeasure analysis will be triggered (step [6]). With the knowledge of some potential attacks and frauds, the depender may irst look for trustworthy partners, or change their methods of operation, or add control mechanisms (countermeasures) to protect their interests. A countermeasure may prevent the attack from happening by either making it technically impossible, or by eliminating the attacker’s intent of attack. Figure 10 shows a SR model with defensive actions as well as attacks. Protection mechanisms are adopted to counteract speciic attacks. In some cases, the protections are suficient to defeat a strong attack (defense Break link (dotted arrow) pointing to an attack Break link). In other cases, countermeasures are only partially effective in defending against their respective attacks (through the Hurt or Some- contribution types).

Qualitative.Goal-Reasoning.Mechanism A qualitative goal-reasoning process is used to propagates a series of labels through the models. A label (or satisicing status) on a node is used to indicate whether that intentional element (goal, task, resource, or softgoal) is viable or not (e.g., whether a softgoal is suficiently met). Labels can have values such as Satisied “ ,” Denied “ ,” Weakly Satisied “ ” and Weakly Denied “ ,” Undecided “ ,” etc. (Liu et al., 2003). Leaf nodes (those with no incoming contributions) are given labels by the analyst based on judgment of their independent viability. These values are then propagated “upwards” through the contribution network (following the direction of the contribution links, and from dependee to depender). The viability of the overall system appears in the high level nodes of the various stakeholders. The process is an interactive one, requiring the analyst to make judgments whenever the outcome is inconclusive given the combination of potentially conlicting contributions. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Yu, Liu, & Mylopoulos

Figure 11. Countermeasure effectiveness evaluation model

To begin, the analyst labels all the attack leaf nodes as Satisiced since they are all judged to be possible (Figure 11). Similarly, all the defense leaf nodes are judged to be viable, thus labelled Satisied. The values are then propagated along contribution links. Before adding defense nodes, the Card Holder’s dependency on the Terminal Owner for Read Write Card Correctly softgoal was labelled as Denied, because of the potentially strong attacks from Terminal Owner. However, as countermeasures are added, the inluences of the attacks will be correspondingly weakened. Regarding Read Write Card Correctly, three possible attacks are identiied. One of them Steal Card Info is counteracted by three defense measures, though each one is partial (Hurt). Another attack Remember Account Number & Password has a defense of unknown strength (Some-). The third attack has no defensive measure. The softgoal dependency Read Write Card Correctly is thus judged to be weakly unviable ( ). On the other side, as the Data Owner’s protection mechanism could suficiently defeat the four possible attacks, the Transmit Complete and Correct Data softgoal dependency is thus judged to be viable ( ). Potential attacks lead to the erosion of viability of the smart card system. Incorporating suficient countermeasures restores viability. A prototype knowledge-based tool is being constructed to support this framework for analyzing information systems security.

Trust.Analysis.Based.on.System Coniguration In the models previously given, the various participants in a smart card system were modelled as abstract roles and analyzed generally. However, in real world smart card systems, various concrete physical or organisational parties play or occupy these roles. These are shown in Table 1. Thus, to actually understand their trust and security situations, we have to apply the generic model to the real world conigurations. We consider two representative kinds of smart card based systems. One is the Digital Stored Value Card, the other is the Prepaid Phone Card (Schneier & Shostack, 1998). Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Table 1. Actors (roles, positions, and agents) in various smart card system conigurations

Generic Smart Card Model

Card Holder

Terminal Owner

Card Issuer

Digital Stored Value card

Customer

Merchant

Financial Institution

Digital Check Card

Customer

Merchant

Prepaid Phone Card

Customer

Account-based Phone Card

Customer

Key store card Employee Access Token Web browsing card

Financial Institution

Card Manufacturer

Customer

Software Manufacturer

Technology Company Technology Company

Phone Company Phone Company

User

Customer

Technology Company

Technology Company

Employee Customer

Data Owner

Employer Financial Institution

Technology Company

Digital Stored Value Card System These are payment cards intended to be substitutes for cash. Both Mondex and VisaCash are examples of this type of system. The Customer is the Card Holder. The Merchant is the Terminal Owner. The Financial Institution that supports the system is both the Data Owner and the Card Issuer. The Smart Card Technology Company, such as Mondex, is both the Card Manufacturer and the Software Manufacturer. In such a coniguration, the previously separated roles of Data Owner and Card Issuer are Played by the same physical agent, namely, Financial Institution. Similarly, Card Manufacturer and Software Manufacturer are combined into one physical agent — the Smart Card Technology Company. Figure 12 describes the threat model of a digital stored value card. Here the Software Manufacturer’s attack on Card Manufacturer can be ignored since they belong to the same agent — the Smart Card Technology Company. Also the attack from Data Owner to Card Issuer can be ignored since they both played by the Financial Institution. These two attacking-defending relationships are highlighted in Figure 11 with little squares.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

Figure 12. A threat model of digital stored value card system

Prepaid Phone Card System These are special-use stored value cards. The Customer is the Card Holder. The Phone Company plays all the four roles of Terminal Owner, Data Owner, Manufacturer, and Card Issuer. Figure 13 shows the threat model of a prepaid card system. Under such a system coniguration, more attack-defense pairs disappear. Only four possible attacks need to be considered now. Three of them are from the phone company, which includes violating privacy, to issue unusable card, to read write card incorrectly. The other attack is from the Card Holder, who might use an illegitimate card. Note that each time new roles are created, the possibility of new attacks arises. These models relect Schneier’s observation that the fewer splits we make, the more trustworthy the target system is likely to be (Schneier & Shostack, 1998).

RELATED. WORK. This section is complementary to the review presented in Chapter I. Each approach to security and software engineering has an ontology, whether explicitly deined or implied. We expect that a social ontology can be complementary and beneicial to various approaches to integrating security and software engineering. We begin with work from the security community, followed by software engineering approaches that have paid special attention to security.

Security.Models. Formal models have been an important part of computer security since mainframe computing (Samarati & Vimercati, 2001). Security policies originate from laws, regulations, or organisational practices, and are typically written in natural Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Figure 13. A threat model of prepaid phone card system

language. Security models using mathematical formalisms can provide a precise formulation of the policies for implementation. More importantly, formally speciied policy models can be mathematically veriied to guarantee security properties. As mathematical abstractions, they provide unambiguous speciications that are independent of implementation mechanisms. Some concepts in security models include: subject, object, action, clearance level, user, group, role, task, principal, owner, etc. Since security models are idealized abstractions, their application in real life requires a series of translations, involving interpretation and decision making at each stage. Organisational structures must be analyzed so as to select the appropriate models, or a combination of models. Policies need to be interpreted and codiied properly to achieve the desired results. Real world entities and relationships are mapped to the model abstractions. Finally, the security model is mapped to security implementation mechanisms. The levels of abstractions used in security requirements, design, and implementation therefore mirror those in software system development and provide a basis for integration. The social ontology outlined in this chapter can facilitate and augment an integrated security development process by enriching the reasoning support needed to arrive at decisions at each stage in the process. The ontology in existing security models are intended for the automated enforcement of speciied security rules (e.g., to Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

decide whether to give access). They do not support reasoning about why particular models or policies are appropriate for the target environment, especially when there are conlicting objectives and interpretations. Furthermore, many of the simplifying assumptions that formal models rely on do not hold in real life (Denning, 1999). The social ontology of strategic actors provides a framework for reasoning about the use of such models from a pragmatic, broader perspective. In the development of new security models, there is a trend towards ontologies that are more closely aligned with the ontology of organisational work. For example, role based access control (RBAC) (Ferraiolo, Sandhu, Gavrila, Kuhn, & Chandramouli, 2001; Sandhu, Coyne, Feinstein, & Youman, 1996) allows privileges to be organised according to organisational roles such as loan oficer or branch manager. These trends are consistent with the proposed social ontology approach, though RBAC models, like other access control models, are meant for enforcement, not strategic organisational reasoning.

Security.Management.Frameworks. While formal computer security models focus on policies built into the automated system, the overall security of information and software systems depends very much on organisational practices. Security practices have existed long before the computer age. Many of the principles continue to apply and have been adapted to software systems. Standards have been deined to promote best practices (e.g., ISO 17799, 1999). OCTAVE (Alberts & Dorofee, 2002), CRAMM, and FRAP (Peltier, 2001), are oriented toward decision making from a business perspective, leading to management, operational, and technical requirements and procedures. Although few frameworks have explicit information models, they do have implicit ontologies revolving around key concepts such as asset, attack, threat, vulnerability, countermeasure, and risk. The main focus of these frameworks is on prescriptive guidelines. Tables and charts are used to enumerate and cross-list vulnerabilities and threats. Potential countermeasures are suggested. Risks are computed from potential losses arising from estimated likelihood of threats. Since quantitative estimates are hard to come by, most assessments rely on ratings such as low, medium, high. While formal computer security models attempt to guarantee security (requiring simplifying assumptions that may depart from reality), security management frameworks acknowledge that security breaches will occur, and suggest countermeasures to reduce risk. This pragmatic stance is very much in the spirit of the social ontology proposed in this chapter. Security management frameworks can be augmented by the modelling of strategic actor relationships and reasoning about how their goals may be achieved or hindered. Another drawback of checklists and guidelines is that they tend to be too generic. Experience and expert judgment are needed to properly apply them to speciic

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



systems and organisational settings. Such judgments are hard to trace or maintain over time as the systems evolve. The explicit modelling of strategic relationships can provide a more speciic analysis of sources of vulnerabilities and failures, thus also allowing countermeasures to be targeted appropriately. Using the strategic dependencies and rationales, one can trace the impact of threats along the paths to determine which business goals are affected. The impact on goals other than security can also be determined through the model since they appear in the same model. One can see how security goals might compete with or are synergistic with non-security goals, thus leading to decisions that take the overall set of goals into account. Using an agent-oriented ontology, one can determine which actors are most affected by which security threats, and are therefore likely to be most motivated to take measures. Tradeoffs are done from the viewpoint of each stakeholder. This approach provides a good basis for an ontology of security, which can mediate between business reasoning from an organisational perspective and system design reasoning from a technical perspective. Some preliminary work have been done to integrate the i* modelling ontology with risk-based security management approaches (Gaunard & Dubois, 2003; Mayer, Rifaut, & Dubois, 2005). Further extensions could incorporate economic theories and reasoning (e.g., Anderson, 2001; Camp & Lewis, 2004). The ontology of i* can provide the structure representation of social relationships on which to do economic reasoning.

Software.Systems.Design.Frameworks

Having considered work originating from the security side, we now turn to contributions from the software engineering and system development perspective. Extensions.to.UML (see Chapter I for information of such approaches).The ontology of UML, consisting of objects and classes, activities, states, interactions, and so forth, with its security-oriented extensions, are useful for specifying the technical design of security features and functionalities, but does not support the reasoning that lead up to those requirements and designs. As indicated in the second section of this chapter, technical design notations are useful for recording the results of decisions, but do not offer support for arriving at those decisions. The social ontology proposed in this chapter can therefore complement UML-based approaches, such as the one presented in Chapter IX, by supporting the early-stage requirements modelling and reasoning that can then be propagated to the technical design stage, resulting in design choices expressed in UML-like design notations. Stakeholder deliberations and tradeoffs therefore are effectively conveyed to technical designers. Conversely, the effect of technical choices can be propagated upstream to enable stakeholders to appreciate the consequences as they appear in the stakeholders’ world.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

Extensions.to.information.systems.modelling.and.design..In the information systems area, Pernul (1992) proposes secure data schemas (extension of entity-relationship diagrams) and secure function schemas (extension of data low diagrams). In Herrmann and Pernul (1999) and Röhm and Pernul (1999), these models are extended to include a business process schema, with tasks, data/material, humans, legal bindings and information low, and an organisational schema with role models and organisation diagrams to describe which activities are done where and by whom. Other information systems security approaches include the automated secure system development method (Booysen & Eloff, 1995) and the logical controls speciication approach (Baskerville, 1993; Siponen & Baskerville, 2001). These approaches illustrate the extension of conventional information systems ontologies to incorporate security-speciic ontologies. Different concepts are added to each level of modelling (e.g., database schemas, process or function schemas, worklow schemas, and organisation diagrams). As with UML extensions, these approaches tend to emphasize the notation needed to express security features in the requirements speciication or design descriptions and how those features can be analyzed. However, the notations (and the implied ontology) do not provide support for the deliberations that lead up to the security requirements and design. A social ontology that supports explicit reasoning about relationships among strategic actors, as outlined in this chapter, can be a helpful extension to these approaches. Responsibility.modelling..A number of approaches center around the notion of responsibility. In Strens and Dobson (1994), when an agent delegates an obligation, the agent becomes a responsibility principal, and the receiver of the delegation process is a responsibility holder. An obligation is a high-level mission that the agent can fulill by carrying out activities. Agents cannot transfer their responsibilities, only their obligations. Three kinds of requirements are derived from responsibilities: need-to-do, need-to-know and need-for-audit. The need-to-know requirements relate to security policies — which subjects (e.g., users) should be allowed to access which objects (e.g., iles, etc.) so that they are able to fulill their responsibilities. Backhouse and Dhillon (1996) also adopt a responsibilities analysis approach, incorporating speech acts theory. The model for automated proile speciication (MAPS) approach (Pottas & Solms, 1995) uses responsibilities and role models to generate information security proiles (such as access control) from job descriptions and organisational policies. This group of work has a more explicit ontology of social organisation. The emphasis is on the mappings between organisational actors and the tasks or activities they have to perform. While actors or agents have responsibilities, they are not viewed as having strategic interests, and do not seek alternate conigurations of social relationships that favor those interests. The focus of attention is on functional behaviors and responsibilities. Security is treated as additional functions to be incorporated, and there are no attempts to deal with interactions and tradeoffs between security and other non-functional objectives such as usability or maintainCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



ability. The social ontology of i* can therefore be quite complementary to these approaches. Other socio-organisational approaches are reviewed in Dhillon and Backhouse (2001).

Requirements.Engineering.Approaches.to.Security While security needs to be integrated into all stages of software engineering, there is general agreement that integration starting from the earliest stages is essential. It is well known that mistakes early in the software process can have far reaching consequences in subsequent stages that are dificult and costly to remedy. Fred Brooks (1995) had noted that the requirements stage is the most dificult, and suggested that software engineering should focus more on “building the right system,” and not just on “building the system right.” In requirements engineering research, a large part of the effort has been devoted to verifying that the requirements statements are precise, unambiguous, consistent, and complete. Recently, more attention has been given to the challenge of understanding the environment and context of the intended system so that the requirements will truly relect what stakeholders want. Goal-oriented.requirements.engineering..Traditional requirements languages for software speciication focus on structure and behavior, with ontologies that center around entities, activities, states, constraints, and their variants. A goal-oriented ontology allows systems to be placed within the intentional setting of the usage environment. Typically, goal-oriented requirements engineering frameworks employ AND/OR tree structures (or variants) to analyze and explore alternate system deinitions that will contribute to stakeholder goals in different ways. Security can be readily integrated into such a framework since attacks and threats interfere with the normal achievement of stakeholder goals. Security controls and countermeasures can be derived from defensive goals to counteract malicious actions and intents. The.NFR.framework:.Security.as.softgoal..The NFR framework (Chung, 1993; Chung et al., 2000) is distinctive from most of the above cited approaches to security in that it does not start with vulnerabilities and risks, nor from security features and functions. It starts by treating security as one among many non-functional requirements. As with many other non-functional requirements such as usability, performance, or information accuracy, security is viewed as a goal whose operational meaning needs to be interpreted according to the needs of the speciic application setting. This interpretation is done by a series of reinements in a goal graph until the point (called operationalization) where subgoals are suficiently concrete as to be accomplishable by implementable actions and mechanisms, such as access control mechanisms or protocols. At each stage in the reinement, subgoals are judged to be contributing qualitatively to the parent goals in different ways. Because the nature and extent of the contribution requires judgement from experience and pos-

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Yu, Liu, & Mylopoulos

sibly domain expertise, the term softgoal is used, drawing on Simon’s notion of satisicing (Simon, 1996). The NFR framework thus offers a systematic approach for achieving “good enough” security — a practical objective in real life (Sandhu, 2003; Schneier, 2003) that have been hard to achieve in conventional mathematical formalisms. A formal treatment of the satisicing semantics of softgoals is offered in Chung et al. (2000). The NFR framework is also distinctive in that it allows security goals to be analyzed and understood at the same time as other potentially competing requirements, for example, usability, performance, maintainability, and evolvability. In the past, it has been dificult to deal with these non-functional requirements early in the development life cycle. Typically functional requirements dominate the design process. Experienced and expert designers take non-functional requirement into account intuitively and implicitly, but without support from systematic frameworks, languages, or tools. The softgoal graph approach acknowledges that security needs to compete with other goals during requirements analysis and during design. Different aspects of security may also compete with each other. The NFR goal-oriented approach supports reasoning about tradeoffs among these competing goals and how they can be achieved. Beyond clarifying requirements, the NFR softgoals are used to drive subsequent stages in system design and implementation, thus offering a deep integration of security into the software engineering process. A related body of work is in quality attributes of software architecture, for example, the ATAM approach (Kazman, Klein, & Clements, 2000) for architectural evaluation. Many of the basic elements are similar to the NFR framework. The classiication of quality attributes and mechanisms (for security and other attributes), however, are viewed from an evaluation viewpoint. The taxonomy structure of quality attribute is not seen as goals to be elaborated based on tradeoffs encountered in the particular system. Quality attributes are concretized in terms of metrics, which are different for each quality, so trade-offs are dificult across different metrics. The.KAOS.framework:.Goals,.obstacles,.and.anti-goals..KAOS (Dardenne, van Lamsweerde, & Fickas, 1993; van Lamsweerde, 2001, 2004; van Lamsweerde, Brohez, Landtsheer, & Janssens, 2003) is a goal-oriented requirements engineering framework that focuses on systematic derivation of requirements from goals. It includes an outer layer of informally speciied goals, and an inner layer of formalized goal representation and operations using temporal logic. It is therefore especially suitable for real-time and safety critical systems. Reinement patterns are developed making use of temporal logic relationships. The KAOS ontology includes obstacles, which impede goal achievement. The methodology provides techniques for identifying and resolving obstacles. To incorporate security analysis, attackers present obstacles to security goals. New security requirements are derived from attack generation and resolution. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security



Tree structures have been used in the security community for analyzing the structure of threats (Schneier, 1999), and in the safety community for the analysis of faults and hazards (Helmer et al., 2002). Experiences from these approaches can be incorporated into goal-oriented frameworks.

Agent-Oriented.Requirements.Engineering The agent-oriented approach adopts goal-oriented concepts and techniques, but treats goals as originating from different actors. The i* modelling framework views actors as having strategic interests. Each actor aims to further its own interests in exploring alternative conceptions of the future system and how the system will affect its relationships to other actors. This may be contrasted with other frameworks which may include some notion of actor which are non-intentional (e.g., in use case diagrams in UML) or non-strategic (e.g., in KAOS, where agents are passive recipients of responsibility assignments at the end of a goal reinement process). i* adopts the notion of softgoal from the NFR framework, but makes further distinctions with goal, task, and resource. Softgoals are operationalized into tasks, which may in turn contain decompositions that include softgoals. Security issues are traced to antagonistic goals and dependencies among attackers and defenders. As in the NFR framework, security is treated as much as possible within the same notational and reasoning framework as for other nonfunctional requirements (as softgoals), but extended to include functional elements (as goals, tasks, and resources). Security is therefore not treated in isolation, but interacts with other concerns at all steps throughout the process. The illustration of i* in this chapter is based on the example in Yu and Liu (2000, 2001). Further illustrations are in Liu et al. (2002), Yu and Cysneiros (2001), Liu et al. (2003), Liu and Yu (2003, 2004). The i* approach has been adopted and extended in a number of directions. The Tropos framework (Bresciani, Perini, Giorgini, Giunchiglia, & Mylopoulos, 2004; Castro, Kolp, & Mylopoulos, 2002) further develops the i* approach into a full-ledged software engineering methodology, using the agent-oriented social ontology originating from requirements modelling to drive architectural design, detailed design, and eventual implementation on agent-based software platforms. Formal Tropos incorporates formalization techniques similar to KAOS, so that automated tools such as model checking can be applied to verify security properties (Liu et al., 2003). A number of extensions to i* have been developed to address speciic needs of security modelling and analysis. Mouratidis et al. (2003a, 2003b, 2004, 2005, also Chapter VIII) introduced the concepts of security reference diagram and security constraints. Common security concepts such as secure entities, secure dependencies, and secure capabilities are reinterpreted within the i* ontology. The security constraint concept attaches a security-related strategic dependency to the dependency that it applies to. An intuitive beneit of this concept is that the association between the two Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

00 Yu, Liu, & Mylopoulos

is indicated without having to refer to the internal rationale structures of actors. An attack scenarios representation structure that aims to support the analysis of speciic attacking and protecting situations at a more detailed design stage is developed. New language structures developed include secure capability, and attacking link. Giorgini et al. (2003, 2005; also Chapter VIII) introduced four new primitive relationships related to security requirements: trust, delegation, offer and owner relation. These new primitives offer an explicit treatment of security concepts such as permission, ownership, and authority, which allows a more detailed analysis. In Crook, Ince, and Nuseibeh (2005), the problem of modelling access policies is addressed by extending the Tropos approach (Liu et al., 2003), to ensure that security goals can be achieved and that operational requirements are consistent with access policies.

Misuse/Abuse Cases Misuse and abuse cases techniques (Alexander, 2001; Sindre & Opdahl, 2000, 2001; see also Review in Chapter I) are complementary to goal-oriented techniques as they offer different ways of structuring requirements knowledge (Rolland, Grosz, & Kla, 1999). Use cases are action-oriented and include sequence and conditionals. Goal reinements are (mostly) hierarchical covering multiple levels of abstraction. In addressing security requirements, the development of misuse/abuse cases can be assisted by using goal analysis. Conversely, goal analysis can be made concrete by considering positive and negative use cases and scenarios. Note that use cases are better suited to later stages in requirements analysis since they assume that the system boundary is already deined. Unlike the strategic actors in i*, actors in use cases are non-intentional and serve to delineate the boundary of the automated system.

CONCLUSION In this chapter, we have argued that a social ontology can provide the basis for integrating security and software engineering. We presented the social ontology of i* and illustrated how it can be used to include security goals when designing a smart card system. We have outlined how a social ontology is complementary to a number of techniques in security engineering and in software engineering, thus building common ground between the two areas.

ACKNOWLEDGMENT

The authors (1 & 3) gratefully acknowledge inancial support from the Natural Sciences and Engineering Research Council of Canada, Bell University Laboratories, and author (2) the National Key Research and Development Plan (973, no.2002CB312004) and NSF China (no. 60503030). Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security

0

REFERENCES Alberts, C., & Dorofee, A. (2002, July). Managing information security risks: The OCTAVE (SM) approach. Boston: Addison Wesley. Alexander, I. (2002, September). Modelling the interplay of conlicting goals with use and misuse cases. Proceedings of the 8th International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ-02), Essen, Germany (pp. 9-10). Alexander, I. (2003, January). Misuse cases: Use cases with hostile intent. IEEE Software, 20(1), 58-66. Anderson, R. (2001). Security engineering: A guide to building dependable distributed systems. New York: Wiley. Backhouse, J., & Dhillon, G. (1996). Structures of responsibilities and security of information systems. European Journal of Information Systems, 5(1), 2-10. Baskerville, R. (1993). Information systems security design methods: Implications for information systems development. Computing Surveys, 25(4), 375-414. Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61-72. Booysen, H. A. S., & Eloff, J. H. P. (1995). A methodology for the development of secure application systems. Proceeding of the 11th IFIP TC11 International Conference on Information Security. Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., & Mylopoulos, J. (2004) Tropos: An agent-oriented software development methodology. Autonomous Agents and Multi-Agent Systems, 8(3), 203-236. Brooks, F. (1995, August). The mythical man-month: Essays on software engineering, 20th Anniversary Edition (1st ed.). Boston: Addison-Wesley. Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements driven information systems engineering: The Tropos project. Information Systems, 27(6), 365-389. Chung, L. (1993). Dealing with security requirements during the development of information systems. In C. Rolland, F. Bodart, & C. Cauvet (Eds.), Proceedings of the 5th International Conference Advanced Information Systems Engineering, CAiSE ’93 (pp. 234-251). Springer. Chung L., Nixon, B. A., Yu, E., & Mylopoulos, J. (2000). Non-functional requirements in software engineering. Kluwer Academic Publishers. CRAMM – CCTA (Central Computer and Telecommunications Agency, UK). Risk analysis and management method. Retrieved from http://www.cramm. com/cramm.htm Crook, R., Ince, D., & Nuseibeh, B. (2005, August 29-September 2). On Modelling access policies: Relating roles to their organisational context. Proceedings of the 13th IEEE International Requirements Engineering Conference (RE’05), Paris (pp. 157-166). Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993). Goal-directed requirements acquisition. Science of Computer Programming, 20(1-2), 3-50. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Yu, Liu, & Mylopoulos

Denning, D. E. (1998). The limits of formal security models. National Computer Systems Security Award Acceptance Speech. Retrieved October 18, 1999, from www.cs.georgetown.edu/~denning/infosec/award.html Dhillon, G., & Backhouse, J. (2001) Current directions in IS security research: Toward socio-organizational perspectives. Information Systems Journal, 11(2), 127-154. Ferraiolo, D., Sandhu, R., Gavrila, S., Kuhn, R., & Chandramouli, R. (2001, August). Proposed NIST standard for role-based access control. ACM Transactions on Information and Systems Security, 4(3), 224-74. Franch, X., & Maiden, N. A. M. (2003, February 10-13). Modelling component dependencies to inform their selection. COTS-Based Software Systems, 2nd International Conference, (ICCBSS 2003) (pp. 81-91). Lecture Notes in Computer Science 2580. Ottawa, Canada: Springer. Gaunard, P., & Dubois, E. (2003, May 26-28). Bridging the gap between risk analysis and security policies: Security and privacy in the age of uncertainty. IFIP TC11 18th International Conference on Information Security (SEC2003) (pp. 409-412). Athens, Greece. Kluwer. Giorgini, P., Massacci, F., & Mylopoulos, J. (2003, October 13-16). Requirement engineering meets security: A case study on modelling secure electronic transactions by VISA and Mastercard. The 22nd International Conference on Conceptual Modelling (ER’03) (LNCS 2813, pp. 263-276). Chicago: Springer. Giorgini, P., Massacci, F., Mylopoulos, J., & Zannone, N. (2005). Modelling social and individual trust in requirements engineering methodologies. Proceedings of the 3rd International Conference on Trust Management (iTrust 2005). LNCS 3477. Heidelberg: Springer-Verlag. Gross, D., & Yu, E. (2001, August 27-31). Evolving system architecture to meet changing business goals: An agent and goal-oriented approach. The 5th IEEE International Symposium on Requirements Engineering (RE 2001) (pp. 316317). Toronto, Canada. Helmer, G., Wong, J., Slagell, M., Honavar, V., Miller, L., & Lutz, R. (2002). A software fault tree approach to requirements analysis of an intrusion detection system. In P. Loucopoulos & J. Mylopoulos (Ed.), Special Issue on Requirements Engineering for Information Security. Requirements Engineering (Vol. 7, No. 4, pp. 177-220). Herrmann, G., & Pernul, G. (1999). Viewing business-process security from different perspectives. International Journal of Electronic Commerce, 3(3), 89-103. ISO 17799. (1999). Information security management — Part 1: Code of practice for information security. London: British Standards Institution. Kazman, R., Klein, M., & Clements, P. (2000). ATAM: Method for architectural evaluation (CMU/SEI-2000-TR-004). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Liu, L., & Yu, E. (2003). Designing information systems in social context: A goal and scenario modelling approach. Information Systems, 29(2), 187-203. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security

0

Liu, L., & Yu, E. (2004). Intentional modelling to support identity management. In P. Atzeni et al. (Eds.), Proceedings of the 23rd International Conference on Conceptual Modelling (ER 2004) (pp. 555-566). LNCS 3288. Berlin, Heidelberg: Springer-Verlag. Liu, L., Yu, E., & Mylopoulos, J. (2002, October 16). Analyzing security requirements as relationships among strategic actors. The 2nd Symposium on Requirements Engineering for Information Security (SREIS'02). Raleigh, NC. Liu, L., Yu, E., & Mylopoulos, J. (2003, September). Security and privacy requirements analysis within a social setting. Proceedings of International Conference on Requirements Engineering (RE’03) (pp. 151-161). Monterey, CA. Lodderstedt, T., Basin, D. A., J, & Doser, R. (2002). SecureUML: A UML-based modelling language for model-driven security. Proceedings of UML '02: Proceedings of the 5th International Conference on The Uniied Modelling Language, Dresden, Germany (pp. 426-441). Mayer, N., Rifaut, A., & Dubois, E. (2005). Towards a risk-based security requirements engineering framework. Workshop on Requirements Engineering For Software Quality (REFSQ’05), at the Conference for Advanced Information Systems Engineering (CAiSE), Porto, Portugal. McDermott, J., & Fox, C. (1999). Using abuse case models for security requirements analysis. Proceedings 15th IEEE Annual Computer Security Applications Conference, Scottsdale, USA (pp. 55-67). Mouratidis, H., Giorgini, P., & Manson, G. A. (2003a). Integrating security and systems engineering: Towards the modelling of secure information systems. Proceedings of the 15th Conference on Advanced Information Systems Engineering (CAiSE 03) (Vol . LNCS 2681, pp. 63-78). Klagenfurt, Austria: Springer. Mouratidis, H., Giorgini, P., & Manson, G. (2004, April 13-17). Using security attack scenarios to analyse security during information systems design. Proceedings of the 6th International Conference on Enterprise Information Systems, Porto, Portugal. Mouratidis, H., Giorgini, P., & Schumacher, M. (2003b). Security patterns for agent systems. Proceedings of the 8th European Conference on Pattern Languages of Programs, Irsee, Germany. Mouratidis, H., Kolp, M., Faulkner, S., & Giorgini. P. (2005, July). A secure architectural description language for agent systems. Proceedings of the 4th International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS05). Utrecht, The Netherlands: ACM Press. Peltier, T. R. (2001, January). Information security risk analysis. Boca Raton, FL: Auerbach Publications. Pernul, G. (1992, November 23-25). Security constraint processing in multilevel secure AMAC schemata. The 2nd European Symposium on Research in Computer Security (ESORICS 1992) (pp. 349-370). Toulouse, France. Lecture Notes in Computer Science 648. Springer. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Yu, Liu, & Mylopoulos

Pottas, D., & Solms, S. H. (1995). Aligning information security proiles with organizational policies. Proceedings of the IFIP TC11 11th International Conference on Information Security. Röhm, A. W., & Pernul, G. (1999). COPS: A model and infrastructure for secure and fair electronic markets. Proceedings of the 32nd Annual Hawaii International Conference on Systems Sciences. Rolland, C., Grosz, G., & Kla, R. (1999, June). Experience with goal-scenario coupling in requirements engineering. Proceedings of the IEEE International Symposium on Requirements Engineering, Limerick, Ireland. Samarati, P., & Vimercati, S. (2001). Access control: Policies, models, and mechanisms. In R. Focardi & R. Gorrieri (Eds.), Foundations of security analysis and design: Tutorial lectures (pp. 137-196). LNCS 2171. Sandhu, R. (2003, January/February). Good enough security: Towards a business driven discipline. IEEE Internet Computing, 7(1), 66-68. Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996, February). Role-based access control models. IEEE Computer, 29(2), 38-47. Schneier, B. (1999). Attack trees modelling security threats. Dr. Dobb’s Journal, December. Retrieved from http://www.counterpane.com/attacktrees-ddj-ft.html Schneier, B. (2003). Beyond fear: Thinking sensibly about security in an uncertain world. New York: Copernicus Books, an imprint of Springer-Verlag. Schneier, B., & Shostack, A. (1998). Breaking up is hard to do: Modelling security threats for smart-cards. First USENIX Symposium on Smart-Cards, USENIX Press. Retrieved from http://www.counterpane.com/smart-card-threats.html Simon, H. (1996). The sciences of the artiicial (3rd ed.). MIT Press. Sindre, G., & Opdahl, A. L. (2000). Eliciting security requirements by misuse cases. Proceedings of the 37th Conference on Techniques of Object-Oriented Languages and Systems (pp. 120-131). TOOLS Paciic 2000. Sindre, G., & Opdahl, A. L. (2001, June 4-5). Templates for misuse case description. Proceedings of the 7th International Workshop on Requirements Engineering, Foundation for Software Quality (REFSQ2001), Switzerland. Siponen, M. T., & Baskerville, R. (2001). A new paradigm for adding security into IS development methods. In J. Eloff, L. Labuschagne, R. von Solms, & G. Dhillon (Eds.), Advances in information security management & small systems security (pp. 99-111). Boston: Kluwer Academic Publishers. Strens, M. R., & Dobson, J. E. (1994). Responsibility modelling as a technique for requirements deinition. IEEE, 3(1), 20-26. van der Raadt, B., Gordijn, J., & Yu, E. (2005). Exploring Web services from a business value perspective. To appear in Proceedings of the 13th International Requirements Engineering Conference (RE’05), Paris (pp. 53-62). van Lamsweerde, A. (2001, August 27-31). Goal-oriented requirements engineering: A guided tour. The 5th IEEE International Symposium on Requirements Engineering (RE 2001) (p. 249). Toronto, Canada. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Social Ontology for Integrating Security

0

van Lamsweerde, A. (2004, May). Elaborating security requirements by construction of intentional anti-models. Proceedings of ICSE’04, 26th International Conference on Software Engineering (pp. 148-157). Edinburgh: ACM-IEEE. van Lamsweerde, A., Brohez, S., Landtsheer, R., & Janssens, D. (2003, September). From system goals to intruder anti-goals: Attack generation and resolution for security requirements engineering. Proceedings of the RE’03 Workshop on Requirements for High Assurance Systems (RHAS’03) (pp. 49-56). Monterey, CA. Yu, E. (1993, January). Modelling organizations for information systems requirements engineering. Proceedings of the 1st IEEE International Symposium on Requirements Engineering (pp. 34-41). San Diego, CA. Yu, E. (1997, January 6-8). Towards modelling and reasoning support for early-phase requirements engineering. Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE'97) (pp. 226-235). Washington, DC. Yu, E. (2001a, April). Agent orientation as a modelling paradigm. Wirtschaftsinformatik, 43(2), 123-132. Yu, E. (2001b). Agent-oriented modelling: Software versus the world. Agent-Oriented Software Engineering AOSE-2001 Workshop Proceedings (LNCS 222, pp. 206-225). Springer Verlag. Yu, E., & Cysneiros, L. (2002, October 16). Designing for privacy and other competing requirements. The 2nd Symposium on Requirements Engineering for Information Security (SREIS’02). Raleigh, NC. Yu, E., & Liu, L. (2000, June 3-4). Modelling trust in the i* strategic actors framework. Proceedings of the 3rd Workshop on Deception, Fraud and Trust in Agent Societies, Barcelona, Catalonia, Spain (at Agents2000). Yu, E., & Liu, L. (2001). Modelling trust for system design using the i* strategic actors framework. In R. Falcone, M. Singh, & Y. H. Tan (Eds.), Trust in cyber-societies--integrating the human and artiicial perspectives (pp. 175-194). LNAI-2246. Springer. Yu, E., Liu, L., & Li, Y. (2001, November 27-30). Modelling strategic actor relationships to support intellectual property management. The 20th International Conference on Conceptual Modelling (ER-2001) (LNCS 2224, pp. 164-178). Yokohama, Japan: Spring Verlag.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Yu, Liu, & Mylopoulos

Section.II Modelling.and.Developing. Secure.Software.Systems. Using.Patterns

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Methodology to Develop Secure Systems Using Patterns

0

Chapter.V

A.Methodology.to. Develop.Secure.Systems. Using.Patterns E. B. Fernandez, Florida Atlantic University, USA M. M. Larrondo-Petrie, Florida Atlantic University, USA T. Sorgente, Florida Atlantic University, USA M. Vanhilst, Florida Atlantic University, USA

ABSTRACT We are developing a methodology to build secure software for complex applications and its related support. This methodology considers the whole software lifecycle, uses security patterns, and is applied at all the architectural levels of the system. A main idea is that security principles should be applied at every stage and that each stage can be tested for compliance with security principles. Patterns help apply security principles. This chapter presents the current status of our work.

INTRODUCTION A good percentage of the software deployed in industrial/commercial applications is of poor quality, it is unnecessarily complex, and contains numerous laws that can be exploited by attackers. Every day the press reports of attacks to Web sites or databases around the world, resulting in millions of dollars in direct or indiCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Fernandez, Larrondo-Petrie, Sorgente, & Vanhilst

rect losses and the number of vulnerabilities and incidents keep increasing (CERT, 2005). Until recently, the only software vendors’ response to security problems was to provide patches to ix the latest vulnerability found or to blame the users for their lack of caution. However, patches are clearly not a solution: it is hard for system administrators to keep up with the latest patches and the patch itself may open new possibilities for attack. There are two basic approaches to improve application security: (1) examine inal production code and look for possible problems (e.g., buffer overlow conditions) (Howard & LeBlanc, 2003) or (2) plan for security from the beginning. We believe that the solution lies in developing secure software from the beginning, applying security principles along the whole life cycle. Part of the problem is that developers are not, in general, acquainted with security methods. We see the use of patterns as a fundamental way, even for developers with little experience, to implicitly apply security principles. We are developing a methodology to build secure software based on patterns (Fernandez, 2004). Our intended target is the construction of complex applications. These include medical systems, inancial applications, legal applications, operating systems, and others. These applications are typically implemented in systems having additional non-functional requirements such as reliability or fault tolerance. Often they are composed of a variety of units, some built ad hoc and some bought or outsourced. In these systems, the security of the application software itself cannot be separated from the security of the rest of the system. Another common aspect of these systems is that they frequently must follow regulatory standards, for example, HIPAA (HIPAA), Gramm-Leach-Bliley (Gramm-Leach-Bliley Act, 1999), or Sarbanes/ Oxley (Sarbanes-Oxley, 2002). These systems may include several databases and usually have Internet access as well as distributed and wireless access. Data is typically accessed using a Web application server (WAS) that integrates Web and database applications and has a global enterprise model, usually implemented using components such as J2EE or .NET. These applications are of fundamental value to enterprises and their security is extremely important. A systematic approach is required to build these applications so they can reach the appropriate level of security. We focus on these applications because they deine worst-case scenarios where to apply our methodology. Patterns provide solutions to recurrent problems and there are several catalogs of patterns. We see the use of security patterns as a useful way to incorporate security principles in the design process even by people having little experience with security practices. We have produced many security patterns. (Delessy-Gassant, Fernandez, Rajput, & Larrondo-Petrie, 2004; Fernandez & Pan, 2001; Schumacher, Fernandez, Hybertson, Buschmann, & Sommerlad, 2005). For building conceptual models, we developed a type of pattern called semantic analysis pattern (SAP), which implements a set of basic use cases (Fernandez & Yuan, 2000). We can combine SAPs and security patterns in a natural way to create authorized SAPs, which can be converted into models for secure designs where security constraints are deined Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Methodology to Develop Secure Systems Using Patterns

0

(Fernandez, 2003). We have also addressed how to carry over the security model of the analysis stage into the design stage (Fernandez, Sorgente, & Larrondo-Petrie, 2005). We developed a UML (uniied modeling language)-based model to represent complex policies (Fernandez, Larrondo-Petrie, Sorgente, & VanHilst, 2005). Our latest work is about security requirements (Fernandez, VanHilst, Larrondo-Petrie, & Huang, 2006). In this chapter, we present an overview of our methodology. The next section deines some context for our work. The two subsequent sections provide a summary of the methodology; consider the requirements phase and discuss how to relate threats to use cases. The following section shows how security patterns can be added to conceptual models in the analysis phase. The next section shows how these analysis models are converted into design models with the addition of distribution and multiple architectural levels. The inal section considers related approaches and we end with some conclusions. To present the different aspects of the approach we use two running examples, a inancial institution, and a hospital.

THE. DEVELOPMENT. OF. SECURE. SOFTWARE Early efforts to secure software focused on securing the infrastructure. The risks in an insecure application could be addressed by running it in a secure environment. System administrators were responsible for coniguring and maintaining (i.e., patching) the security of each installation’s networks, ports, and platforms. The most vulnerable applications (e.g., payroll) were to run on machines with little or no connectivity. The trend toward Web and distributed applications has, however, dictated an ever increasing use of, and need for, network connectivity. Moreover, efforts to catalog existing vulnerabilities ind a signiicant and increasing proportion of vulnerabilities are in the applications themselves (Curphey, 2004). In despite of this, there is again interest in some circles on protecting software through the platform where it executes (Trusted Computing Group). An approach to secure software is based on practical experience (Hoglund & McGraw, 2004; Howard & LeBlanc, 2003; OWASP, 2004; Viega & McGraw, 2001). They present hints and rules to help programmers write secure code but their approaches have little conceptual basis and consider only coding, no analysis or design aspects. General principles to build secure systems are given by (Saltzer & Schroeder, 1975; Viega & McGraw, 2001). These are clearly important but too general to be useful when building systems. Risk management is an important aspect needed to decide how much effort to invest in security. Code reviews and code testing are also important to detect security-related laws, but are hard to apply without a conceptual structure. Several works use the concept of misuse cases (for more information see Chapter I). Misuse cases are close to our idea of relating attacks to use cases but are used in a different way. Related to this, Liu, Yu, and Mylopoulos (Chapter IV) discuss requirements for secure systems using the concept of goaloriented requirements. Other authors also have focused on security requirements, Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Fernandez, Larrondo-Petrie, Sorgente, & Vanhilst

including (He & Anton, 2004; Konrad, Cheng, Campbell, & Wassermann, 2003; Zuccato, 2004). More recent guidelines for securing software at the application level have focused on securing assets. Once the design exists, vulnerable resources are identiied and secured (Viega, 2005). Following this development process, security is still addressed in its own, separate phase in the development process or lifecycle. The degree to which a resource must be protected must be based on risk analysis. The analysis of the risks can be further reined by the use of attack analyses (Schneier, 1999; Steffan & Schumacher, 2002; Van Lamsweerde, 2004). Attack trees map attacker goals to scenarios that lead to those goals. However, they are too detailed and do not provide a global view of the attacks. Another drawback of using a separate attack and vulnerability analysis is that the analysis assumes a complete design. Incremental and evolutionary changes to the system invalidate the results of earlier analyses. To contain the scope of required new analyses, the development method should maintain strong traceability among requirements, actors, assets, attacks, defenses, exposures, and vulnerabilities. Security must be addressed in all activities in all phases of the software development process and lifecycle. Any vulnerability can cause, or contribute to, breaches of security. Studies have shown that attacks can come not only from outsiders, but also from insiders. Systems can be compromised or rendered unusable by attacking any control point, even those unrelated to the handling of assets. Vulnerabilities and the need to mitigate loss must be addressed in requirements, design, acquisition, implementation, testing, deployment, operation, maintenance, and every other lifecycle activity. The way software is developed (software process) and the speciic methodology used is very important to produce secure systems. Both Neumann (1993) and Pleeger (2003) emphasize the value of information hiding and encapsulation in the design of secure systems. The importance of these principles and our experience, indicate that the object-oriented approach is to be preferred over a procedural approach. As we shall see, there are other advantages of the object-oriented methodology that are important for security.

OVERVIEW. OF. THE. METHODOLOGY A basic idea in the proposed methodology is that security principles must be applied at every development stage and that each stage can be tested for compliance with those principles. In fact, some approaches to object-oriented development already emphasize tests at every stage (McGregor & Sykes, 2001). We sketch irst a secure software development cycle that we consider necessary to build secure systems and then we discuss each stage in detail. Figure 1 shows a secure software lifecycle. The white arrows show where security can be applied and the black arrows where we can audit compliance with security policies. From the Requirements Stage Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Methodology to Develop Secure Systems Using Patterns



we generate secure use cases. From the Analysis Stage we generate authorization rules that apply to the conceptual model. From the Design Stage we enforce rules through the architecture. In the Implementation, Deployment and Maintenance Stages, language enforcement of the countermeasures and rules is required. Note that security veriication and testing occurs at every stage of development. Table 1 lists the methods that address security at each development stage. These are described in more detail. Requirements.stage: Use cases deine the required interactions with the system. Applying the principle that security must start from the highest levels, it makes sense to relate attacks to use cases and develop what we call secure use cases (UCs). We study each action within a use case and see which attacks are possible (Fernandez, VanHilst, Larrondo-Petrie, & Huang, 2005). We then determine which policies would stop these attacks. From the use cases we can also determine the needed rights for each actor and thus apply a need-to-know policy. Note that the set of all use cases deines all the uses of the system and from all the use cases we can determine all the rights for each actor. The security test cases for the complete system can also be deined at this stage. Risk analysis should be applied at this stage. Analysis.stage:.Analysis patterns, and in particular semantic analysis patterns, can be used to build the conceptual model in a more reliable and eficient way (Fernandez & Yuan, 2000). Security patterns describe security models or mechanisms. We can build a conceptual model where repeated applications of a security model pattern realize the rights determined from use cases. In fact, analysis patterns can be built with predeined authorizations according to the roles in their use cases. Then we only need to additionally specify the rights for those parts not covered by patterns. We can start deining mechanisms (countermeasures) to prevent attacks.

Figure 1. Secure software lifecycle Security verification and testing

Requirements

Secure UCs

Analysis

Design

Implementation

Authorization rules in Rule enforcement Language enforcement conceptual model through architecture

Security test cases Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Fernandez, Larrondo-Petrie, Sorgente, & Vanhilst

Table 1. Summary of our development methods Stage

Method.to.address.security

Requirements

Use case based role identiication and attack analysis

Analysis

Authorized semantic analysis patterns

Design

Coordinated application of patterns to multiple architectural layers

Implementation

Incorporate COTS (commercial off the shelf) security applications

Design. stage: Figure 2 shows some possible attacks to a system. Design mechanisms are selected to stop these attacks. User interfaces should correspond to use cases and may be used to enforce the authorizations deined in the analysis stage. Secure interfaces enforce authorizations when users interact with the system. Components can be secured by using authorization rules for Java or .NET components. Distribution provides another dimension where security restrictions can be applied. Deployment diagrams can deine secure conigurations to be used by security administrators. A multilayer architecture is needed to enforce the security constraints deined at the application level. In each level we use patterns to represent appropriate security mechanisms. Security constraints must be mapped between levels. Implementation.stage:.This stage requires relecting in the code the security rules deined in the design stage. Because these rules are expressed as classes, associations, and constraints, they can be implemented as classes in object-oriented languages. In this stage we can also select speciic security packages or COTS, e.g., a irewall product, a cryptographic package. Deployment. and. maintenance. stages:. Our methodology does not yet address issues in these stages. When the software is in use other security problems may be discovered by users. These problems can be handled by patching, although the amount of patching after applying our approach should be signiicantly smaller compared to current systems. If necessary, the security constraints can be made more precise by using the object constraint language (OCL) (Warmer & Kleppe, 2003), instead of textual constraints. Patterns for security models deine the highest level of the architecture. At each lower level, we apply the model patterns to speciic mechanisms that enforce these models. In this way, we can deine patterns for ile systems, Web documents, J2EE components, etc. We can also evaluate new or existing systems using patterns. If a system does not contain an embodiment of a correct pattern then it cannot support the corresponding secure model or mechanism.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Methodology to Develop Secure Systems Using Patterns



Figure 2. Typical attacks to the layers of a system Metalayer

Application Layer

A

B

a:A

b:B

inference wrong models

wrong operations malformed parameters language attacks unauthorized data access viruses, worms

DBMS Layer

malformed parameters unauthorized access

OS Layer

directory attacks process interference root attacks address space violation unauthorized file access

Hardware

lack of protection

THE. REQUIREMENTS. STAGE An important aspect of security requirements is a systematic and accurate listing of the possible attacks to the system. With this listing, we can decide what speciic defense mechanisms to use. There has been several attempts to consider attacks to deine the system security requirements (Haley, Laney, & Nuseibeh, 2004; van Lamsweerde, 2004). In our approach, we consider each action in each use case and see how it can be subverted by an internal or external attacker. From this list, we can deduce what policies are necessary to prevent or mitigate the attacks. The idea is that all the use cases of an application deine all the possible interactions of actors with the application. It is in these interactions where attackers could try to misuse the system. Use cases are not atomic but imply a set of actions (Larman, 2005). For example, in a use case to borrow a book from the library one must check if the user has a valid account, she is not overdue, etc. As an example, consider a inancial company that provides investment services to its customers. Customers hold accounts and send orders to the company for buying or selling commodities (stocks, bonds, real estate, art). Each customer account is in the charge of a custodian (a broker), who carries out the orders of the customers. Customers send orders to their brokers by email or by phone. Brokers advise their customers about investments. A government auditor visits periodically to check for application of laws and regulations. Figure 3 shows the use case diagram for this institution. Figure 4 shows the activity diagram for the use case “Open account.” Potentially each action (activity) is susceptible of attack, although not necessarily through the

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Fernandez, Larrondo-Petrie, Sorgente, & Vanhilst

computer system. For each potential attack (threat) we can attach a possible goal. For this use case, we could have the following potential attacks: •

•

• •

•

•

• •

A1: The customer is an impostor and opens a spurious account to transfer money at a later time A2:.The customer provides false information and opens an account with false information A3:.The manager is an impostor and collects user information A4:. The (legitimate) manager collects customer information to sell or use illegally A5:.The manager creates a spurious account with the customer’s information A6:. The manager creates a spurious authorization card to access the account A7:.An attacker prevents the customers to access their accounts A8:.An attacker tries to move money from an account to her own (legitimate) account

Relating attacks to use cases provides a systematic and relatively complete list of possible attacks. Each identiied attack can be analyzed to see how it can be accomplished in the speciic environment. The list can then be used to guide the design and to select security products. It can also be used to evaluate the inal design by analyzing whether the system defenses can stop all these attacks. As we indicated earlier since use cases deine all the interactions with the system we can ind from them the rights needed by these roles to perform their work (need to know). In the activity diagram in Figure 4, the threats are shown as misuse actions. Undesired consequences in the form of additional or alternative artifacts created have also been added. With these annotations, the attacks and vulnerabilities presented by the use case become part of our understanding of the use case and are explicit in its analysis. From our analysis, we can now ind out what policies are needed to stop these attacks. For this we can select from the typical policies used in secure systems (Fernandez, Gudes, & Olivier, 2006). This should result in a minimum set of mechanisms instead of an approach where mechanisms are piled up because they might be useful. For example, to avoid impostors we can have a policy of I&A (identiication and authentication) for every subject participating in a use case. To stop the attacks in the example we need the following policies: • • •

A1. A3. Mutual authentication. Every interaction across system nodes is authenticated. A2. Verify source of information. A4. Logging. Since the manager is using his legitimate rights we can only log his actions for auditing at a later time.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Methodology to Develop Secure Systems Using Patterns



Figure 3. Use cases for a inancial institution

UC

Open Account

UC

Close Account

Manager

Customer UC

Receive Trade Order UC

Perform trade Auditor

Broker

UC

Check Trade Info

• • •

A5. A6. Separation of administration from use of data. For example, a manager can create accounts but should have no rights to withdraw or deposit in the account. A7. Protection against denial of service. We need some redundancy in the system to increase its availability. A8. Authorization. If the user is not explicitly authorized he should not be able to move money from any account.

There is a tradeoff between cost, usability, and acceptable level of risk. Finding the right mix for your application involves a risk analysis. In our use case approach, we identify risks as an integral part of use case deinition. Vulnerabilities are combined with speciic actors and their motivations. In the analysis phase we match security breaches with defense strategies using patterns. Because the vulnerabilities, and corresponding defenses, are an integral part of both structural and functional views, the consequences of speciic security failures can be analyzed in the appropriate context. Risk analysis is better supported than in methodologies lacking these views.

THE.ANALYSIS. STAGE In a previous paper, we proposed a new type of analysis pattern, called a semantic analysis pattern (SAP) (Fernandez & Yuan, 2000). A semantic analysis pattern is a pattern that describes a small set of coherent use cases that together describe a basic generic application. The use cases are selected in such a way that the application can it a variety of situations. Using SAPs we developed a methodCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Fernandez, Larrondo-Petrie, Sorgente, & Vanhilst

Figure 4. Activity diagram for use case “Open account” External Attacker

Customer

Manager Imposter

False info

Imposter

Provide Personal Info

:Customer Check Credit

Account1:

Create Account

Disseminate Info Illegally Create Spurious Account

Account2:

Initial Deposit Transfer Money Create Authorization

Account3:

Card1:

Issue Card

Issue Spurious Card

Card2:

ology to build the conceptual model systematically. In order to use the methodology it is necessary to irst have a good collection of patterns. We have developed several analysis patterns (e.g., Fernandez & Yuan, 1999; Schumacher, Fernandez, Hybertson, Buchmann, & Sommerlad, 2006; Sorgente & Fernandez, 2004; Yuan & Fernandez, 2003), and a good number of others exist in the literature (e.g., Fowler, 1997; Hamza & Fayad, 2004). It is possible to superimpose in the SAPs the needed authorizations to apply a least privilege policy. The use cases deine all the ways to use the system and we need to give the involved actors rights to perform their interactions (Fernandez & Hawkins, 1997). We will illustrate these concepts using a medical application. Figure 5 shows a sequence diagram that implements the use case Admit Patient when a medical center gets a new patient. The Admit Patient use case is an interaction with a medical system in the Patient Treatment Records pattern described next. An administrative clerk needs rights to deine a guardian and to create a patient record, Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Methodology to Develop Secure Systems Using Patterns



Figure 5. Sequence diagram to admit a new patient

aG uardian:

an Adm in is trativeClerk :

admitPatient(info)

:G uard ian

:Patie nt

:Pat ien tIn fo :M ed icalHis tory

:T reatmentIn stance

patient information, a medical history, and a treatment instance. We can add authorization rules to perform these functions to the Patient Treatment Records pattern by adding instances of some security policy. One of the most basic security policies is the one deined by the role-based access control (RBAC) pattern (Fernandez & Pan, 2001). In this model, users join roles according to their tasks or jobs and rights are assigned to the roles. In this way, a need-to-know policy can be applied, where roles get only the rights they need to perform their tasks. In Figure 6, classes Role, Protection.Object,.and.Right.deine the authorizations for roles. A right deines an access type indicating in what manner the role can access the object. As an example of our approach, we add RBAC constraints to the SAP mentioned earlier. The patient treatment record pattern describes the treatment or stay instance of a patient in a hospital (Sorgente & Fernandez, 2004). The hospital may be a member of a medical group. Each patient has a primary physician, an employee of the hospital. Upon admission, the patient record is created or information is updated from previous visit(s). Inpatients are assigned a location, nurse team and consulting doctors. This pattern realizes use cases Admit patient, Discharge patient, Assign Assets to an Inpatient, and Assign Nurse to a Location. Assets of the medical group are assigned to a patient through associations. Figure 7 shows associations between classes Doctor, Nurse, and Location and class Patient,.which describe the corresponding assignments. In particular, all patients are assigned a primary doctor while inpatients may also be assigned consulting doctors. Locations include the room assigned to an inpatient or other places for speciic treatments. The.assets of the medical group are organized in a hierarchical arrangement that describes their physical or administrative structure. Speciically, MedicalGroup. includes some Hospitals,.and in turn each hospital includes some Buildings.(we assume Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Fernandez, Larrondo-Petrie, Sorgente, & Vanhilst

Figure 6. The role-based access control pattern User

id name

MemberOf * *

Role

ProtectionObject

isAuthorizedFor

id name

* id name

* Right

accessType

checkRights

Figure 7. Class diagram for patient treatment record pattern TreatmentInstance date financialNumber initialComplaint

*

MedicalHistory insurance

1

MedicalGroup

Patient name address patient number

Employee

*

name main location

name Employee no. address

assignedTo

worksAt

*

1…*

* Hospital

Outpatient

Inpatient

*

name address

* *

Doctor

primary 1

assignedTo

specialty

consulting

*

Nurse

* Building

specialty

*

name location

*

assignedTo

* Location

assignedTo *

assignedTo

number size 1

that hospitals do not share buildings). Each treatment Location is part of a building. The class Employee classiies the types of personnel that are assigned to patients. Figure 8 superimposes RBAC rights on some of the classes of Figure 7, indicating rights for several roles. We have now an “authorized SAP,” that in addition to being a unit for building a conceptual model also indicates the typical roles that would perform its use cases and their rights.

THE. DESIGN. STAGE We can now carry over the security architecture of the analysis stage to the design stage. One approach to enforce security constraints is to use a model view controller (MVC) pattern (Buschmann, Meunier, Rohnert, Sommerlad, & Stal, 1996). Each View corresponds to an interface for a use case and we can enforce role rights at these interfaces. Figure 9 implements the use case Admit a patient Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

A Methodology to Develop Secure Systems Using Patterns



Figure 8. Patient treatment record pattern with RBAC authorizations *

TreatmentInstance

MedicalHistory

date financialNumber initialComplaint

insurance dateRange

create ( ) update ( ) close ( )

open ( ) create ( ) update ( ) close ( )

MedicalGroup 1

name mainLocation

Patient name address patientNumber

*

create(patient info ) update( patient info)

* Employee name idNumber address

Right hospitalAudit

size() < 

This OCL constraint forbids more than one person from the staff assigned to the application domain speciic role Head.

Visual Speciication of Access Control Constraints

Visual speciication languages to specify access control constraints in UML start from the observation that OCL is dificult to understand and does not integrate well with the remaining visual UML diagrams. Therefore, Ray et al. (2004) present a visualization of access control constraints using UML object diagrams. In their approach, object diagram templates describe object structure patterns that are violations of access control constraints. These patterns are used to check for violations of a constraint, as such an object diagram pattern represents a system structure which must not occur in the system state. Figure 8 shows the object diagram for the two example constraints. On the lefthand side, the object diagram for the prerequisite constraint is speciied. It shows the invalid state in which a view is assigned to a role, but there is no permission assigned to the view. On the right-hand side, the cardinality constraint is speciied by the invalid state of two staff objects assigned to the role Head object. The visualization of access control constraints presented in Koch et al. (2002c) also uses object diagrams. Similar to Ray et al. (2004) object diagrams are used to specify invalid system states which must not occur in a system state for the constraint to be satisied. The difference between the approach of Koch et al. (2002c) and that of Ray et al. (2004) are additional object diagrams for required states and a formal semantics based on graph transformations (Rozenberg, 1997) which can be used to apply veriication concepts on access control constraints. The semantics will be explained in more detail in the next section.

Figure 8. Object diagram patterns

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Access Control Speciication in UML

235

Figure 9. A metamodel constraint and an instance of this metamodel constraint in the hospital access control model

An object diagram for a required state speciies an object structure that must occur in a system state. A system state satisies such a constraint if the required object structure occurs as a sub-state. The existence of this object structure may be conditional, i.e., the object structure is required only in certain substates. The object diagrams for required states are called positive constraints and use the stereotype in the following way: all objects and links labeled with this stereotype must exist in a system state when the remaining (i.e., the non labeled) objects and links occur, as well. Figure 9 shows the visual speciication of the viewpermission requirement by a positive constraint. It shows the assignment of a permission p to a view v, which in turn is assigned to a role r. The permission object p and its link to the view v carry the stereotype. Both must exist whenever the view v is assigned to a role r. If no role is assigned to the view, the assigned permission need not exist. The object diagram for the invalid system state of two users in role Head is the same as the one shown in Figure 8.

Access.Control.Metamodel.and.Access.Control.Model.

As previously mentioned, constraints may refer to, and be speciied for, the metamodel level if they must be satisied by all access control models independently of a speciic application, or they may concern only a speciic application and therefore must be valid only in a speciic access control model. Since metamodel constraints must be valid in any access control model, they must be part of a given access control model for a certain application, as well. Therefore, access control model constraints are derived from the access control constraints of the metamodel, as is the case for the policy rules: The metaobjects in the metamodel constraint are instantiated with objects given in the access control model type diagram, so that the resulting object diagram is a valid instance of the ACM type diagram. An example is the specialisation of the VBAC metamodel Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

236 Koch, Parisi-Presicce, & Pauls

constraint in Figure 9 in which the metaobject role is specialized to a Nurse object, the metaobject view is specialized to a CISView object and the permission is a CISPermissiom. An invalid instantiation, according to the ACM type diagram, would be a CISView object for the view and a PatientRecPermission object for the permission, since it would be in conlict with the type diagram. The access control constraints of an access control model, therefore, consist of a) all the object diagrams obtained by instantiating the metamodel constraint diagrams using objects speciied in the access control model (ACM) type diagram, so that the resulting object diagrams are instances of the ACM type diagram and b) a set of object diagrams for information domain speciic constraints.

VERIFICATION. OF. ACCESS. CONTROL. CONSTRAINTS. The access control constraints restrict the possible system states that can be produced by the policy rules. Whether a set of object diagrams for the policy rules of a UML access control speciication satisies all the access control constraints should be checked automatically as much as possible. To have an automatic veriication, it is necessary to have a formal semantics for both the UML access control model and the UML constraints, on which an automatic veriication support can be built. Consider, as an example, the policy rules for the access control metamodel shown in Figure 5 and Figure 6. These object diagrams are specialized to application speciic objects given in the access control model type diagram in Figure 4. One possible specialization is the instantiation of the policy rule assign role in Figure 5 with a Staff instance as subject and Head as role. Applying this rule several times to the same Head role but with different staff member instances, would produce several staffers who play the role Head for the same department. The negative constraint in Figure 8 on the right-hand side, however, forbids more than one subject in the role Head. Therefore, the UML access control speciication is not correct since the policy rules can construct a system state that does not satisfy all the access control constraints. We have developed (Koch et al., 2001) a graph-based, formal semantics for a UML access control speciication which allows us to check statically if the set of object diagrams for the policy rules satisfy the constraints (Koch et al., 2002a; Koch et al., 2002c). To use these veriication concepts we need to transform UML diagrams into graphs, UML object diagrams for policy rules into graph transformation rules and (visual) UML constraints into graphical constraints (for transformation details see (Koch & Parisi-Presicce 2002d). Due to the graphical notation of UML diagrams, the transformation of these diagrams into graphs is natural. Access control constraints are transformed into graphical constraints. The transformation of visually speciied UML constraints can be done in a natural way. The transformation of OCL constraints is more dificult, but possible for a part of the OCL constraints. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Access Control Speciication in UML

237

These are mainly those OCL constraints used to express properties on the object structure of the system state. In Bottoni, Koch, Parisi-Presicce, & Taentzer (2001), the interested reader can ind a more detailed presentation on the visualization of (most) OCL constraints The checking algorithm (Koch et al., 2002c) determines, for each policy rule and access control constraint, whether the policy rule can construct a system state that violates the constraint. In this case, the algorithm modiies the rule by adding an additional condition to the rule, to ensures that the policy rule, whenever it is applied to a valid system state, will always construct a new system state which again satisies the constraint. The policy rule condition forbids the application of the rule to system states that would lead to an invalid new system state. If we consider the example, mentioned above, of the policy rule assign role and the negative constraint which forbids two or more staffer in the role Head, then the checking algorithm adds a condition to the policy rule assign role to prevent its application to the Head role if there is already a staffer assigned to this role. We have built a prototype of an RBAC administration tool, which implements the checking algorithm as well. The tool has been implemented according to the proposed NIST standard for RBAC (Ferraiolo, Sandhu, Gavrila, Kuhn, & Chandramouli, 2001) and is based on the general graph transformation engine AGG (Taentzer, Ermel, & Rudolf, 1999). It allows a security administrator to deine graph-based policy rules and constraints, including several kinds of authorization constraints identiied in the literature (Ahn & Sandhu, 2001) such as various types of separation of duty (SoD) properties (simple static SoD, simple dynamic SoD, sessionbased dynamic SoD, and objectbased static SoD), cardinality constraints, and prerequisite roles and permissions.

ACCESS. CONTROL. REQUIREMENT.ANALYSIS. So far, we have described how to model an access control policy in UML. We use a metamodel for the access control model and reine this metamodel to a model that considers the application speciic access control requirements. To determine the access control requirements (i.e., what to model) is a dificult task, especially since system designer are usually not security experts. Therefore, the designer should be supported in the software development process to obtain the necessary access control requirements. In Koch and Pauls (2005a) and Koch and Pauls (2005b), we have presented a model-driven approach to derive access control requirements from the UML diagrams for the functional system analysis and design. For example, access control roles are based on the actors in the use case diagrams, access rights are based on the class

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

238 Koch, Parisi-Presicce, & Pauls

Figure 10. A sequence diagram

diagrams and the access control permissions are based on the operation calls in the sequence diagrams. The access control information can be automatically extracted from these UML diagrams and is presented in UML diagrams for access control as shown in the previous sections. We present next the generation of views from UML sequence diagrams as an example of this generation process. For a more detailed presentation of the modeldriven approach we refer to Koch et al. (2005a) and Koch and Pauls (2005b). Sequence diagrams contain inherent access information by specifying the access required of actors to call the operations. The sequence diagram in Figure 10 shows the accesses required of a nurse to read a patient record. The nurse role must be able to call the operations list() and getPR() on the class CIS to retrieve the list of all available patient records and a single patient record, respectively. To read the patient records, the nurse role needs the permission to call the operation show() on the class PatientRecord. The algorithm for the generation of access control views from a sequence diagram considers all the objects in the sequence diagram on which operations are called: For each of these objects, a view on the class of the object is generated which contains the permissions to call the operations on the objects of this class. In our example sequence diagram in Figure 10 we generate two views: one on the class CIS with CISPermissions to call the operations list() and getPR() and one view on the class PatientRecord with PatientRecPermission to call the operation show(). The views for all the remaining sequence diagrams are generated in a similar way. The generated views are usually incomplete in the sense that they do not give a complete access control speciication. This is due to the fact that sequence diagrams show only scenarios the designer is interested in. On the other hand, the views may also be redundant in the sense that the same view may be generated from different sequence diagrams. Therefore, the designer uses the generated views as a starting point to be reined into the inal access control speciication. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Access Control Speciication in UML

239

RELATED. WORK. A few authors have addressed the problem of integrating security requirements into UML. Jurjens presents the integration of security into UML in Jurjens (2005), where he shows how to model several security aspects by UML model elements as, for example, stereotypes or tagged values. His approach is more general than ours since it is not restricted to access control but considers, for example, also security protocols. Furthermore, Jurjens considers a wider variety of UML diagrams (e.g., also deployment diagrams) since his concern is with the integration of security into the UML in general. Our approach is focused on access control, and the generation and enforcement of access control policies in distributed systems, and, therefore, we only use the UML diagrams necessary to meet our objective. In contrast to our approach and the one by Basin, Doser, and Lodderstedt (2004), Jurjens does not consider a model-driven approach and does not provide tool support or an infrastructure to generate security policies from UML models or to enforce security policies. Moreover, Jurjens (2002) has extended UML for specifying aspects of multilevel secure systems and security protocols, where he proposes a tailored formal semantics to evaluate UML diagrams and to indicate possible weaknesses. Unlike our approach, there is no model-driven integration of security and the veriication does not provide an automatic consistency construction to resolve unsatisied security constraints. Fernandez-Medina, Martinez, Medina, and Piattini (2002) extend UML to support the design of secure databases. They consider a multilevel database model in which all model elements have a security level and a security role, both modeled by tagged values. They extend the OCL to be able to represent multilevel system constraints. Unlike the approach in Fernandez-Medina et al. (2002) which is developed for multilevel databases, our approach is more general, dealing with any access control model and is not restricted to databases. In contrast to Fernandez-Medina et al. (2002), which extends the OCL by nonstandard features, we use standard OCL for the speciication of constraints. The OCL extension has the advantage of a clearer and more legible speciication in the particular context of multilevel databases, but does not ensure compatibility. Epstein and Sandhu (1999) introduce a UML-based notion for RBAC, but this notion is not suitable for the veriication of security properties and cannot easily be used for the generation of access control speciications. An approach closely related to ours is SecureUML (Lodderstedt et al., 2002). SecureUML is a UML-based modelling language for the model-driven development of secure systems. It provides support for specifying constraints, as well. The security information integrated in the UML models is used to generate access control infrastructures. In contrast to our approach, SecureUML focuses on static design models, which are closely related to implementations. Therefore, there is no support for detecting security requirements (e.g., which roles are needed and Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Koch, Parisi-Presicce, & Pauls

which permissions they need). Unlike our approach, which is suitable for arbitrary access control models, SecureUML is based on RBAC, and does not have a formal semantics to verify security properties. Work related to our model-driven development approach to security engineering is presented by Basin et al. (2004), to describe a model driven approach, called SecureUML, to develop role based access control policies for J2EE applications. A formal basis allows the designer to reason about access control properties, and tool support is given by an integration of SecureUML into the ArcStyler tool (Interactive-Objects, 2005). In contrast to our approach, however, the analysis stage of the software process is not considered and the process starts with the design models. The role based model in (Basin et al., 2004) is more coarse-grained compared with the view based access control model here, in which access rights are ine-grained on the level of operations and operation parameters. Basin et al. use the J2EE infrastructure to enforce the generated policies, but their approach makes it dificult to modify a policy dynamically: the modiied policy must be changed manually in the XML-based EJB descriptor iles. Dynamic changes of the access control policy, however, are an integral part of our approach. On the one hand, the concept of schemas considers the changing of rights already in the model; on the other hand, our proposed infrastructure supports policy changes at runtime, immediately enforced without interrupting the application and the system.

CONCLUSION.

This chapter has presented an approach to the speciication of Access Control policies in UML by means of UML class and object diagrams that can be modelled with existing UML tools. It has been shown how the framework models the access control entities, the rules of the access control policy, and the access control constraints. By using a layered model structure, we have been able to model the different components at an abstract (metamodel) level that is application independent, and at a concrete (model) level that includes application speciic information. A translation of the UML Access Control speciication into a graph-based security framework permits the application of veriication concepts from graph transformations to reason about the coherence of a UML Access Control speciication. In particular, it allows the modiication of the context of application of existing rules to ensure that the new state satisies all the constraints (if the old one did). The chapter closes with an indication of how to extract access control requirements from UML diagrams. The UML Access Control speciication can be modelled using existing UML CASE tools. One possible direction of future work is the transformation of the XMI export (obtained from the CASE tool) into a XML format for graphs (Taentzer, 2001). Then, graph transformation tools (Ehrig, Engels, Kreowski, & Rozenberg, 1999) can be used for the automatic veriication of Access Control requirements.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Access Control Speciication in UML

241

REFERENCES.

Ahn, G. J., & Sandhu, R. (2001). RoleBased authorization constraints speciication. ACM Transactions on Information and System Security, 3(4), 207-226. Ahn, G. J., & Shin, M. (2001). Rolebased authorization constraints speciication using object constraint language. Proceedings of the WETICE’01 (pp. 157-162). Basin, D., Doser, J., & Lodderstedt, T. (2004). Model driven security. In M. Broy, J. Grunbauer, D. Harel, & T. Hoare (Eds.) Engineering Theories of Software Intensive Systems. Springer. Bottoni, P., Koch, M., Parisi-Presicce, F., & Taentzer, G. (2001). A visualization of OCL using collaborations. Proceedings of the UML 2001 (pp. 257-271). The Uniied Modeling Language (LNCS 2185). Springer. Brose, G. (2000). A typed access control model for CORBA. Proceedings of the 6th European Symposium on Research in Computer Security (ESORICS) (LNCS 1895, pp. 88-105). Springer Brose, G. (2001a). Access control management in distributed object systems. PhD thesis, Freie Universität Berlin. Brose, G. (2001b). Raccoon—An infrastructure for managing access control in CORBA. Proceedings of the International Conference on Distributed Applications and Interoperable Systems (DAIS). Kluwer. Brose, G. (2002). Manageable access control for CORBA. Journal of Computer Security, 10(4), 301-337. Brose, G., Koch, M., & Lohr, K. P. (2002). Integrating access control design into the software development process. Proceedings of the 6th International Conference on Integrated Design and Process Technology (IDPT) Brose, G., Koch, M., & Lohr, K. P. (2003, January 3). Entwicklung und Verwaltung von Zugriffsschutz in verteilten Objektsystemen–eine Krankenhausfallstudie. In Praxis der Informationsverarbeitung und Kommunikation (PIK), 26, 1. KG Saur Publishing. D’Souza, D., & Wills, A. (1998). Components and frameworks: The catalysis approach. Boston: Addison Wesley. Devanbu, P. T., & Stubblebine, S. (2000). Software engineering for security: A roadmap. In A. Finkelstein (Ed.), The future of software engineering. New York: ACM Press. Ehrig, H., Engels, G., Kreowski, H. J., & Rozenberg, G. (1999). Handbook of graph grammars and computing by graph transformations. Vol. II: Applications, Languages, and Tools. Singapore: World Scientiic. Epstein, P., & Sandhu, R. (1999). Towards a UML based approach to role engineering. Proceedings of the ACM RBAC. New York: ACM Press. Fernandez-Medina, E., Martinez, A., Medina, C., & Piattini, M. (2002). UML for the design of secure databases: Integrating security levels, user roles, and constraints in the database design process. In J. Jurjens, M. V. Cengarle, E. B.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Koch, Parisi-Presicce, & Pauls

Fernandez, B. Rumpe, & R. Sandner (Eds.), Proceedings of the CSDUML02 (pp. 93-106). Number TUMI0208 in Technical Report TU Munchen. Ferraiolo, D., Sandhu, R., Gavrila, S., Kuhn, D. R., & Chandramouli, R., (2001). Proposed NIST standard for rolebased access control. ACM Transactions on Information and System Security, 4(3), 224-274. Harrison, M., Ruzzo, M., & Ullman, J. (1976). Protection in operating systems. Communications of the ACM, 19(8), 461-471. Interactive-Objects. (2005). Arcstyler. Retrieved from www.interactive-objects. com Jaeger, T., & Tidswell, J. (2001). Practical safety in lexible access control models. ACM Transactions on Information and System Security, 4(2), 158-190. Jurjens, J. (2001). Towards development of secure systems using UMLsec. Proceedings of the FASE’01 (pp. 187-200). (LNCS 2029). Springer. Jurjens, J. (2002). UMLsec: Extending UML for secure systems development. Proceedings of the UML 2002 (pp. 412-425). Number 2460 in Lect. Notes in Comp. Sci., Springer. Jurjens, J. (2005). Secure systems development with UML. Heidelberg: SpringerVerlag. Koch, M., Mancini, L.V., & Parisi-Presicce, F. (2001). Foundations for a graphbased approach to the speciication of access control policies. In F. Honsell & M. Miculan (Eds.), Proceedings of the Foundations of Software Science and Computation Structures (FoSSaCS 2001), (LNCS 2030, pp. 287-302). Springer. Koch, M., Mancini, L.V., & Parisi-Presicce, F. (2002a). Conlict detection and resolution in access control speciications. In M. Nielsen & U. Engberg (Eds.), Proceedings of the Foundations of Software Science and Computation Structures (FoSSaCS 2002) (LNCS 2303, pp. 223-237). Springer Koch, M., Mancini, L.V., & Parisi-Presicce, F. (2002b). Decidability of safety in graphbased models for access control. Proceedings of the 7th European Symposium on Research in Computer Security (ESORICS) (LNCS 2502, pp. 229-243). Koch, M., Mancini, L. V., & Parisi-Presicce, F. (2002c, August). A graph based formalism for RBAC. ACM Transactions on Information and System Security (TISSEC), 5(3), 332-365. Koch, M., & Parisi-Presicce, F. (2002d). Access control policy speciication in UML. In Jurjens, Cengarle, Fernandez, Rumpe, & Sandner (Eds.), Proceedings of CSDUML02 (pp. 63-78). Technical Report TUMI0208, TU Munchen. Koch, M., & Pauls, K. (2005). An access control language for dynamic systems modeldriven development and veriication. Proceedings of the 12th SDL Forum.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Access Control Speciication in UML

243

Koch, M., & Pauls, K. (2005). Modeldriven development of access control aspects. Proceedings of the Sicherheit 2005 (pp. 273-284). Lecture Notes in Informatics. Lodderstedt, T., Basin, D., & Doser, J. (2002). SecureUML: A UML based modeling language for modeldriven security. Proceedings of the 5th International Conference on the Uniied Modeling Language,(LNCS 2460). Springer. OMG. (1999, October). CORBA 3.0 New Components Chapters, TC Document ptc/991004. OMG. OMG. UML 2.0 Speciication. OMG, 2003. Ray, I., Li, N., France, R., & Kim, D. K. (2004). Using UML to visualize rolebased access control constraints. Proceedings of the SACMAT’04 (pp. 115-124). ACM. Rozenberg, G. (1997). Handbook of graph grammars and computing by graph transformation (Vol. 1). Foundations. Singapore: World Scientiic. Sandhu, R., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-based access control models. IEEE Computer, 29(2), 38-47. Sun Microsystems. (2000, October). Enterprise JavaBeans Speciication, Version 2.0, Final Draft. Retrieved from http://java.sun.com/products/ejb/docs.html Taentzer, G (2001). Towards common exchange formats for graphs and graph transformation systems. Proceedings of Uniform Approaches to Graphical Process Speciication Techniques UNIGRA’01, (ENTCS 47). Elsevier. Taentzer, G., Ermel, C., & Rudolf, M. (1999). The AGG approach: Language and tool environment. In H. Ehrig, G. Engels, H.-J. Kreowski, & G. Rozenberg (Eds.), Handbook of graph grammars and computing by graph transformation (Vol. 2). Singapore: World Scientiic.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

Chapter.XI.

Security.Engineering.for. Ambient.Intelligence:. A.Manifesto A. Maña, University of Malaga, Spain C. Rudolph, Fraunhofer Institute for Secure Information Technology, Germany G. Spanoudakis, City University, UK V. Lotz, SAP Research, France F. Massacci, University of Trento, Italy M. Melideo, Engineering Ingegneria Informatica, Italy J. S. López-Cobo, ATOS Origin, Spain

ABSTRACT. The scenarios of ambient intelligence introduce a new computing paradigm and set new challenges for the design and engineering of secure and dependable systems. This chapter describes SERENITY, a comprehensive approach to overcome those problems. The key to success in this scenario is to capture security expertise in such a way that it can be supported by automated means. SERENITY’s integral model of ADD — security and dependability (S&D) considers both static and dynamic aspects by relying in two main innovations: (1) the enhanced notion of S&D patterns and integration schemes; and (2) the computer aided run-time monitoring of Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



the implemented security solutions. The combination of these innovations lays the foundations of an integrated, solid, lexible, and practical S&D framework for AmI ecosystems. The chapter aims at clarifying the challenges introduced in AmI ecosystems and pointing out directions for research in the different areas involved.

INTRODUCTION Well in the past millennium, the typical reaction to questions about “information systems security” would have been another question “what is security?” A decade ago the response to the same concern was “security is an added value service, a non-functional requirement.” Only in the last few years has the response become “security must be designed and built-in from the very start.” Although the latter response acknowledges the need for integrating security into the design and development phases of IT, this integration is still lagging behind in practice (Tryfonas, Kiountouzis, & Poulymenakou, 2001). Security engineering capability maturity models, ISO 17799 and other standards detail a classiication of properties that a secure system must have but do not actually provide any information on how such properties can be achieved. Even landmark textbooks on security engineering (Anderson, 2001) are often a collection of case studies and do not provide a structured methodology for actually engineering secure systems, no more than a dictionary can be called a grammar. Today COTS (components off-the-shelf) security services such as encryption, digital signatures, public key infrastructures, etc. and rather standard attack countermeasures such as irewalls, intrusion detection systems, etc. are selectively employed in the attempt to fulil basic security requirements such as authentication or conidentiality. The usual deployment of those security mechanisms provides an “isolated” functionality, which is not always appropriate for the speciic system to be protected and is usually not effective for addressing the potential threats introduced by emerging environments like grid computing and wireless ad-hoc networks. Experience in the development of cryptographic protocols shows that even for relatively small systems, it is dificult and often error-prone to fulil security requirements by simply combining existing security mechanisms. Even for such a brittle ield, there are few and specialized solutions that supports in an automated way the precise identiication of security requirements and the correct choice of security mechanisms. Their adoption by IETF protocol designers has still a long way to go (interested readers might have a look at the AVISPA EU project effort into introducing the usage of formal methods into standard security protocols design at www.avispa-project.org). Designers and users must also face other sources of complexity: the impact of contextual information (e.g., hardware and software conigurations of the system), external entities interoperating with the system, legal requirements, social behaviour, etc., can be easily overlooked. As a consequence, expert knowledge in IT security Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

is a prerequisite for applying existing security mechanisms. Unfortunately, such expertise is usually not available to average system developers and users and is often too expensive to acquire. Moreover, for large scale systems, the complexity of the current and emerging computing environments and their security requirements has increased to the point where experience is not enough to guarantee adequate security. The new scenarios of ambient intelligence, their underlying pervasive technology, their notion of mobile services, where the IT environment moulds itself around the user’s needs raise the bar for what is a satisfactory security solutions well beyond standard IT security technology. New challenges stemming from identity and privacy protection are appearing at the horizon. These emerging technologies need sophisticated approaches to determine the security requirements and then to provide adequate security solutions. In Ambient Intelligence scenarios, where the interaction with the environment and the human stakeholders is predominant, the overall security depends on a variety of other factors not covered by conventional software engineering processes including social context and human behaviour, IT environments, and even protection of the physical environment of systems (e.g., buildings). It is therefore evident that current “ad-hoc” approaches cannot support a complete and rigorous treatment of security starting from the requirements elicitation process up to system implementation and, above all, system operation. Different factors result in this situation: 1. 2. 3.

4.

Security is a non-functional requirement, thus it is hard to capture with standard software engineering techniques; Security is partly a social and not only a technical problem, thus it is hard to capture in standard design languages; There is no homogeneous way to represent security concerns and security mechanisms at different levels of software description, thus it is hard to trace security issues; and The current practices of security engineering produce solutions that depend heavily on the details of the application context. These practices need to analyse the complete system, including all interacting entities, in order to provide some guarantees of the security of the solutions.

Therefore, in the emerging computing paradigms, where this context is highly dynamic, where systems are not completely under control of one part and where it is not possible to foresee all speciic conigurations that may arise, these design practices are bound to fail. Though the systems designed with current practices might not necessarily be non-secure, the process is likely to still have signiicant weaknesses:

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence

a.

b.

c.



the security requirements of the entire system might not all be satisied by eliminating single, isolated weaknesses in the system and furthermore, their fulilment can not be conirmed since the requirements have not been clearly speciied in the irst place; different implementations of the same system cannot be easily compared with respect to their security properties nor the compositional effect of employing different security measures at different level of network and application development; the security mechanisms introduced are not directly linked to the speciic security requirements of the system. Linking between security mechanisms and requirements is particularly important in case of failures of security mechanisms, when the effects of attacks on the overall security of a system must be determined.

Contribution.of.This.Chapter In this chapter, we present the SERENITY approach to the provision of security and dependability (S&D) in ambient intelligence (AmI) scenarios. This approach is based on the enhanced concepts of S&D patterns and integration schemes and the integration of runtime monitoring techniques. The structure of the chapter is as follows: the next section introduces the speciic characteristics of the AmI scenarios and the challenges associated to the provision of security and dependability in these scenarios; The two subsequent sections present the SERENITY approach and describe the different elements that are part of the SERENITY framework; The following section illustrates the use of SERENITY based on a speciic application scenario and the penultimate section reviews relevant related work; inally, the last section presents the conclusions.

SECURITY. IN.AMBIENT. INTELLIGENCE. SCENARIOS

Deined by the EC Information Society Technologies Advisory Group (ISTAG), ambient intelligence emphasises on greater user-friendliness, more eficient services support, user-empowerment, and support for human interactions. In this vision, people will be surrounded by intelligent and intuitive interfaces embedded in everyday objects around them and an environment recognising and responding to the presence of individuals in an invisible way by year 2010.

Ambient.Intelligence.(AmI) AmI builds on three recent key technologies: ubiquitous computing, ubiquitous communication, and intelligent user interfaces (some of these concepts are barely a decade old and this is relected on the focus of current implementations of AmI). Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

Ubiquitous computing means integration of microprocessors into everyday objects like furniture, clothing, white goods, toys, even paint. Ubiquitous communication enables these objects to communicate with each other and the user by means of adhoc and wireless networking. Intelligence user interfaces enable the inhabitants of the AmI environments to control and interact with these environments in a natural (voice, gestures) and personalised way (preferences, context). Ubiquitous computers will seamlessly enhance the way we work and even the way we live thanks to the access to information technologies that will optimize the environment for people’s needs in different physical spaces. Anytime/anywhere access to information and services will be provided. The ISTAG vision is that AmI applications will be inluenced by the computational, physical and behavioural contexts that surround the user (for instance, because of resource availability and security or privacy requirements). The concepts of system and application as we know them today will disappear, evolving from static architectures with well-deined pieces of hardware, software, communication links, limits, and owners, to architectures that will be sensitive, adaptive, context-aware, and responsive to users’ needs and habits. These AmI ecosystems will offer highly distributed dynamic services in environments that will be heterogeneous, large scale and nomadic, where computing nodes will be omnipresent and communications infrastructures will be dynamically assembled. The combination of heterogeneity, mobility, dynamism, sheer number of devices, along with the growing demands placed on security and dependability (S&D), make application development more complex and the provision of security and dependability for applications increasingly dificult to achieve with existing security engineering mechanisms and tools.

Challenge 1. Dealing with Dynamism In the new AmI scenarios, not only systems as a whole but also individual applications running in or supported by those systems will have to adapt to dynamic changes to hardware and software, and even irmware conigurations, to unpredicted and unpredictable appearance and disappearance of devices and software components. In other words, applications must be able to adapt dynamically to new execution environments. As a consequence, pre-deined trust relationships between components, applications and their system environments can no longer be taken for granted. The increased complexity and unbounded nature of AmI applications make it impossible, even for the most experienced and knowledgeable S&D engineers, to foresee all possible situations and interactions which may arise in AmI environments and therefore create suitable solutions to address the users’ security and dependability requirements. Additionally S&D engineers will be faced with pieces of software, communication infrastructures, and hardware devices not under their control. Thus,

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



approaches based on the application-level security will not be suficient to provide security and dependability to the AmI ecosystem as a whole.

Challenge 2. Dealing with Heterogeneity AmI environments will contain a large number of heterogeneous computing and communication infrastructures and devices that will provide new functionalities, enhance user productivity, and ease everyday tasks. These devices will hold a variety of data with different security and privacy requirements. This information will be used in different ways in different applications and computing contexts and, therefore, different policies (possibly contradicting) will be applied. In such settings, securing the device or the information alone or even each individual application is not suficient, and context information should be integrated in order to be able to choose appropriate security mechanism on-the-ly.

Challenge 3. Need for Supervision Finally, because of their complexity, and because elements will be under the control of different owners, security mechanisms will need to be supervised (monitored) in order to identify potential threats and attacks and decide on recovery actions, if possible. Some existing approaches can provide suitable solutions to support the dynamic evolution of security policies for speciic security mechanisms (e.g., SAC model for access control (Lopez, 2002)) at particular system operation layers (application, networking). However, these approaches cannot be extended to support the dynamic evolution of general security mechanisms (as opposed to security policies for a single mechanism). Furthermore, their results are extremely complicated to integrate, monitor, and dynamically evolve as would be required by AmI ecosystems. For the very same reasons, S&D approaches for AmI ecosystems cannot hope to synthesize new S&D mechanisms or new combinations of these mechanisms fully automatically and dynamically. We can summarize the individual challenges that we have devised so far into a simpler and yet tougher grand challenge:

Challenge 4. Dynamic Application of Security Expertise The provision of S&D in AmI ecosystems requires the dynamic application of the expertise of security engineers in order to dynamically react to unpredictable and ever-changing contexts. The intuitive solution would be to create an “intelligent” system able to analyze the requirements and the context in order to synthesize new solutions. Unfortunately, given the state of the art in both security engineering and intelligent systems, this approach is not a promising one in the foreseeable future. Existing monitoring techniques do not adequately support the diagnosis of the reasons underpinning run-time violations of S&D requirements nor inform system Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

adaptation to ensure that violations will not re-occur. They also fail to support the speciication of end-user personal and ephemeral S&D requirements, the automatic assessment of whether or not such requirements can be monitored at run-time, and the transformation of these requirements onto monitorable events. Furthermore, they fail to address the need for identiication of scenarios of potential security threats and the translation of these scenarios into monitorable events that would allow the development of pro-active techniques for protecting security.

Challenge 5. Capturing the Expertise of Security Engineers Can we take advantage of the recent developments in technologies of security engineering, run-time monitoring, semantic description, and self-coniguration that are able to capture some of the expertise of security engineers and make it available, supported by automated tools, to the AmI ecosystems?

THINKING. THE. SERENITY:.A. MANIFESTO The SERENITY approach aims at integrating the best of the aforementioned approaches in order to overcome the problems that have prevented them to succeed individually.

SERENITY.Claim.1 A S&D engineering framework will be based on the notion of security and dependability pattern. A pattern describes a recurring problem that arises in a speciic context and presents a well-proven generic scheme for its solution. S&D patterns will feature a precise functional description of the underlying security solution; a full semantic description of the security requirements they address; and descriptions of any preconditions or assumptions that govern the deployment of the pattern. We have developed an enhanced concept of security and dependability (S&D) pattern to represent existing security solutions. In fact, the term “security pattern” has been previously used in the literature to denote informal and ad-hoc security measures, mostly at a managerial level. Our semantic-based formal approach facilitates the deinition of speciic proiles and solutions for different environments. The combination of patterns will not be let to users and designers alone: security and dependability integration schemes will be an extension of S&D patterns designed to represent complex security solutions built by combining other solutions.

SERENITY.Claim.2 The second key innovation factor of SERENITY is the support for the run-time pro-active and reactive identiication of potential threats and attacks of implemented security solutions, the timely (where possible) adaptation of attacked or under-threat applications, and the amendment of S&D patterns and integration schemes to adCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



dress weaknesses identiied during their deployment through appropriate evolution mechanisms. One time too often designers have focused on one of their stakeholder: either system developers or end-users. The complexity of AmI scenarios needs an approach that can talk to both of them rather than either of them. We need a dual-interface approach.

SERENITY.Claim.3 The S&D engineering methodologies will support security engineers in the development of formally-proven security solutions, and the speciication of these solutions as S&D patterns. They will also support system engineers and end-users in the speciication of their security requirements, the selection of the most appropriate combination of the available security solutions regarding the security requirements and the context, and the integration of these security solutions in their systems. This dual-interface approach is based on the belief that it is not realistic to expect that system engineers and end users will ever become security experts. Automating the processing of semantic information represents a big challenge and a promising line of work for the resolution of many relevant problems. Existing expertise in the application of semantic information, i.e., formal speciications and reasoning methods, to the ield of information security ensures the suitability of this approach, which will be the basis of many of the SERENITY methods and tools.

SERENITY.Claim.4 A sound solution to S&D engineering will develop semantic models to specify the semantics of security requirements, patterns, and properties. Automated tools for classiication, selection, and composition of security patterns will take advantage of this semantic information allowing the automated integration of security patterns implementing the speciied security and reliability requirements. Semantic descriptions will not only help in the selection of the right pattern, but will be also essential for pattern composition and system analysis. Furthermore, semantic descriptions will provide the foundation for reuse and secure interoperability of these patterns. The SERENITY approach will materialise our claims in an integrated framework to enable end-users, system engineers and security engineers collaborate seamlessly to build and operate dependable software-based systems for AmI environments with inherent and adaptable security capabilities. This framework will be based on an integral model of security, therefore considering not only static issues (related to secure systems development) but also dynamic aspects (related to monitoring and controlling the software at runtime). The different elements composing this framework will foster the development of new applications, computing paradigms supporting services, in current and future complex, heterogeneous and dynamic computing, and communication infrastructures by eliminating the security and dependability problems they bring about. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

SERENITY.Claim.5 Static aspects of the S&D engineering framework deal with the provision of appropriate abstractions of S&D solutions with the objective of capturing the specialized expertise of security engineers and making it available for non-experts, while at the same time providing the basis for automated synthesis and analysis of the security and dependability of systems. An important issue is the ability to include abstractions of the different collaboration schemes and software and hardware architectures that can occur at runtime in very dynamic and heterogeneous scenarios. In this area, SERENITY’s S&D patterns provide the basic building blocks of security and dependability solutions along with a formal characterisation of their behaviour and semantics that will enable the use of these solutions over a wide range of heterogeneous computing and communication infrastructures and devices. On the other hand, SERENITY’s integration schemes provide a framework for systematically instantiating and integrating these building blocks in applications composed of statically or dynamically collaborating components that operate in mobile and highly dynamic ICT infrastructures. Whereas dynamic composition is an important problem, it is only one side of the coin. The need for run-time requirements monitoring has been argued extensively in the scientiic literature (Feather & Fickas, 1995; Feather et al., 1998; Robinson, 2002) and there have been numerous strands of research on broader run-time monitoring of applications without, however, focusing on security issues, with a few exceptions (Ko, 1996; Serban & McMillin, 1996). The need for runtime monitoring and veriication becomes even more important, when it comes to systems that incorporate autonomous collaborating components such as systems that incorporate Web-services or components which collaborate via peer-to-peer architectures (Mahbub & Spanoudakis, 2004, 2005; Robinson, 2004).

SERENITY.Claim.6 A complete S&D engineering framework will be able to cope with dynamic aspects and to provide mechanisms for monitoring of security requirements at run-time and detecting deinite or potential deviations (aka threats) from such requirements. The framework will support the engineers in the process of amending S&D patterns and integration schemes to address weaknesses identiied during their deployment through appropriate evolution mechanisms. Implementing SERENITY As shown in Figure 1, the SERENITY framework that we envisage is a suite of integrated software tools including: •

A security manager supporting the dynamic selection, adaptation, integration, and monitoring of S&D mechanisms that are available in AmI ecosystems in order to address the security requirements which arise in speciic operational settings. Selection, adaptation, and integration are performed as speciied

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



Figure 1. The SERENITY framework

• • •

by the S&D patterns and integration schemes that are applicable in speciic operational settings. The security manager is supported by: Static validation tools supporting the analysis of compliance of S&D solutions offered by the different components of an AmI ecosystem to inform their selection and integration. Dynamic validation tools supporting the monitoring of AmI systems and their active S&D solutions to detect breaches and potential threats of security and inform the reconiguration of S&D solutions to recover from such breaches or prevent them in cases where this is possible. Evolution tools recording and analysing the operational aspects of S&D solutions as identiied by run-time monitoring to identify gaps and ways of improving these solutions and support the amendment of the S&D patterns and integration schemes that underpin them.

Every instance of the SERENITY framework should provide interfaces to allow the use of some of its functionalities by external elements. These external elements might be other instances of the SERENITY framework running in other systems or other types of SERENITY-aware elements. In particular, the framework should support the publication of the security mechanisms used in the speciic instance and also the publication of some of the runtime monitoring results. The following show how the claims in Section 4 can be materialized. The complete Section 5.1 covers claims 3 and 5. Subsections 5.1.1 and 5.1.2 cover claims 1 and 2 respectively. Subsection 5.1.3 relates to claim 4. Finally, Section 5.2 deals with claim 6. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

Static.Aspects:.Abstraction.of.S&D.Solutions The enhanced notion of security and dependability (S&D) pattern, together with the new concept of Integration Schemes provide important advantages over existing solutions, especially in complex, heterogeneous and dynamic scenarios, in the goal of capturing the specialized expertise of security engineers and making it available for non experts, while at the same time providing the basis for automated management and analysis of security aspects. Moreover, these concepts are very appropriate in order to deal with applications where parts of the software, communication infrastructures, and hardware devices are not under the control of one part and all particular combinations of these can not be foreseen by the S&D engineers.

S&D.Patterns S&D patterns represent security and dependability solutions. They are materialised as iles that contain models that could be described using formal and nonformal languages (e.g., XML and logic-based language) to capture the expertise of security engineers with the inal objective of being processed by automated means. These models provide semantics and behavioural indications that are necessary to describe particular security or dependability contexts that could occur in an AmI environment (i.e., public administration, nomadic context, business, etc.) using well deined rules, methods, and speciication. It is important to emphasize that the idea behind the SERENITY approach is that systems will have security requirements and that there will be ways to satisfy these requirements automatically by using the appropriate combination of the available solutions. With this respect Figure 2 shows a partial conceptual diagram of the SERENITY framework operation. Instead of developing a sophisticated “intelligent” mechanism that can “synthesize” a speciic solution for the problem in the given context, the SERENITY approach is to ind a solution within a set of predeined ones. In order to automatically select the most appropriate solution and also to be able to integrate that solution in our system, we need to have on the one hand, very precise descriptions of the solutions, and on the other hand very lexible descriptions, which can be accommodated to our speciic context. The security requirements analysis and the pattern integration modules shown in the igure are used for this purpose. In order to represent the solutions, S&D patterns (but also integration schemes described in the next section) contain precise speciications, which include: • •

The representation of the solution itself (this is the S&D pattern in Figure 2) corresponding to the behavioural description. The pattern semantics, which are related to the semantics of the security properties provided and the restrictions imposed by the solution, including: o The representation of what is achieved by using the pattern (properties provided);

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



Figure 2. SERENITY framework operation (partial) Properties Semantics Pattern Design

Patterns Library

Security Requirements Analysis

AmI Ecosystem with security requirements

Pattern Integration

AmI Ecosystem with integrated security patterns

S&D Patterns Formal Proofs

Pattern Semantics

security engineering paths

o o

o o

o o

Automated tools paths

Automated dynamic engineering path

The proofs done to validate that the description of the pattern is correct. This can be seen as “guarantees” from the provider; The representation of the mechanisms that are used to provide trust in the pattern and the mechanism. At least, we will for sure want to know who developed the mechanism and that the mechanism has not been altered; The representation of the restrictions imposed on the context. That is, in which situations can we use this pattern; The representation of the possible variants or ways to adapt the mechanism. Usually, these will be parameters. For instance, the length of the key used in an encryption mechanism, the sender and recipient of a message in a protocol, etc.; The representation of the ways to monitor the behaviour (this is speciic to theAmI scenarios); Any other context-speciic information (eficiency, legal compliance, etc.).

We recognize the complexity of providing complete and adequate semantic descriptions for software elements. However, it is our view, validated by our early experiments (Maña, Montenegro, Ray, Sánchez, & Yagüe, 2003), that while in the general case it seems unfeasible to deine mechanisms that are able to capture the semantics of a software element (at least with the current state of the art), in the case of security semantics it will be possible to develop a suitable solution. The reason is that security is a much more restricted ield, where we can rely on a limited number of precise descriptions.

Integration.Schemes

S&D patterns, as described above, are assumed to cover only one speciic security or dependability problem (e.g., speciic security issue concerning the netCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

work level), but it is quite usual that more than one solution (and therefore S&D patterns) must be combined in order to fulil a speciic set of requirements. Integration Schemes are the means to overcome and to igure out this problem that is not easy by itself as it is not always possible to foresee the result of merging different security solutions (whatever they are). The approach followed is again a practical one as in the case of S&D Patterns: Integration Schemes will capture proven known ways to securely integrate different solutions. The added value is that they represent a practical and easy approach to facilitate the task of inding the best and more secure way to integrate several solutions (patterns) in order to create complex S&D solutions.

Expressing.Semantics.about.Security.Properties The most important component of the semantic description of a security solution as an S&D Pattern is the reference to the security properties provided by this solution. Therefore, the mechanism used to describe such semantics has to be carefully designed. We start from the assumption that there will be different deinitions for the basic security properties. There are many reasons for this: for instance, legislation, cultural etc. Let’s illustrate this with an example. Assume Willie wants to use a speciic conidentiality solution SConfACME from provider ACME. In order to correctly use this solution, Willie needs to be able to (1) univocally identify the properties (i.e., “conidentiality”) declared by ACME; and (2) to “understand” the meaning of “conidentiality” as deined by ACME. In particular, Willie needs to know if the meaning of “conidentiality” as deined by ACME is enough to fulil the conidentiality requirement as deined by him. The irst point can be easily solved by applying general naming scheme, following the common practice of deining namespaces. For instance, in such scheme properties could be named “Conidentiality.GSM.Mobile.ETSI,” “Conidentiality. Crypto.Java.Sun” “Conidentiality.ISO,” or “Conidentiality.ACME.” The second part is a bit more dificult, but basically, we can use three approaches: • • •

Standardization:. Establishing a standard classiication of properties with ixed and predeined semantics; Implicit.semantics:.Which implicitly describe the properties as changes in the state of the system, usually as a set of pre and post conditions. Explicit.semantics:.Which provide means for the description of the semantics of the properties, therefore representing an open and interoperable solution.

The description of security properties in SERENITY is based on the third approach. S&D pattern creators can deine their own properties or refer to properties that have been semantically described by third parties. In fact, we foresee that stanCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



dardization bodies will semantically deine sets of properties related to their areas of interest. Therefore, when describing their solutions as S&D patterns, security engineers will have to model the semantics of their solutions. It’s at this point when the use of the Ontological Engineering applied to the patterns will make them more reusable and machine understandable. The use of ontologies can help in the description of a “formal, explicit speciication of a shared conceptualization” (Gruber, 1993), and reasoning mechanism can be applied to this model, inferring new knowledge from it. Patterns, and in particular the properties they refer to, will be described using formal ontology languages (like OWL or WSML) to ensure maximizing the automation of the knowledge lifecycle and to achieve semantic interoperability between different patterns as heterogeneous information resources. The most basic form of the explicit semantics approach consists on the deinition of mechanisms to relate the different properties. For instance, in the previous example two properties are involved: on one side Conidentiality.ACME (the one provided by the solution) and on the other side Conidentiality. Willie (the one required by Willie’s system). The relation between properties is harder to express but we can start by using “implication.” Consider the following rules: 1. 2.

Conidentiality.ACME -> Conidentiality.ISO Conidentiality.ISO -> Conidentiality. Willie

Rule 1 means that if a solution provides conidentiality according to ACME, then it also provides conidentiality according to ISO. Informally, we could say that the deinition of conidentiality by ACME is more restrictive than the one by ISO. Rule 2 states that solutions that provide conidentiality according to ISO provide also conidentiality according to Willie. Then, from the analysis of the previous rules we can determine that Willie’s conidentiality requirement can be fulilled using the SConfACME solution from ACME.

Trust.Mechanisms We envisage a scenario where a library composed of several security solutions from different sources, is available to a system. In this regard, and considering the previous example, the owner of the system (ACME) would like to have the following guarantees: • • •

•

That the SConfACME S&D pattern has been created by ACME; That the semantic description of SConfACME has been created by ACME; That the semantic description of SConfACME corresponds exactly to this solution (version, build, etc.); and That Willie can understand the properties provided by SConfACME as described in the previous section.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

Additionally, Willie needs to know how ACME has analysed and tested the pattern and which proofs can ACME provide to support the semantic descriptions of SConfACME. To address these requirements, a trust infrastructure must be in place. This infrastructure will be based on digital certiicates, digital signatures, etc. but also on semantic descriptions, in a similar way to the one used to describe the semantics of attribute certiicates (Yagüe, Maña, & Sanchez, 2004). This approach facilitates interoperability and supports the commercialization of the security solutions described as S&D patterns.

Dynamic.Aspects:.Run-Time.Monitoring

Despite analysis which might have been taken to ensure that the speciication of a system includes a precise model of the security requirements that need to be realised, and that the design of a system includes components that can realise these requirements, it is in principle dificult to guarantee that such an analysis will provide the full proof that is required. This is because requirements and design models cannot be guaranteed to be complete. When present, incompleteness in requirements speciication and design models makes it impossible to prove with certainty that security requirements will be addressed during the operation of a system. Such proofs are also dificult due to the fact that assumptions about the behaviour of actors in system environments cannot be veriied, including assumptions related to security. Furthermore, static veriication of the satisiability of security requirements may be intractable due to either ininite-state system models or the presence of a prohibitively large system state space that must be explored (Bensalem et al., 2004). These limitations are exacerbated by the unbound and dynamic nature of AmI environments and applications. In SERENITY, we envisage that it will be possible to develop a framework for monitoring security requirements building upon existing approaches and expertise on runtime requirements monitoring for highly distributed service centric systems that is available in the consortium (Mahbub et al., 2004, 2005). The extensions and customisations of these approaches will be aimed at introducing capabilities for: (a) specifying monitorable security requirements, (b) identifying conditions that may indicate potential threats to security requirements, (c) monitoring not only deviations from security requirements but also potential threats to them, and (d) recovering from detected deviations or taking dynamically additional protective measures against threats. On the one hand, the development of runtime monitoring will have to address limitations of existing techniques, notably the lack of automatic support for the generation of the events which are used in monitoring, transformation of security requirements into patterns of such events and identiication of conditions that may indicate potential threats. On the other hand, the development of support for recovery will have to address the absence of reasoning mechanisms allowing

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



the identiication of the source of detected security deviations (diagnosis) and the selection of appropriate recovery actions. SERENITY’s runtime monitoring mechanisms will be complemented by reasoning mechanisms that will analyse information about detected deviations from security requirements at run-time in order to identify gaps in the static requirement and design speciications of a system that did not allow the detection of the potential for these deviations by static analysis. The analysis of detected runtime deviations will inform the process of S&D patterns and integration schemes evolution.

AN.APPLICATION. SCENARIO This section describes one of the envisaged application scenarios and shows how the services of the SERENITY framework can be used to support the provision of security at both development time and at runtime. The scenario focuses on business information systems based on Web services. Modern enterprise information infrastructures are characterised by evolving from stand-alone systems supporting a well-deined and static set of business processes and interacting in a controlled way to open system landscapes providing and integrating services that can be lexibly composed to adapt to rapidly changing business needs. The infrastructure is driven by the evolving business processes and tightly integrates a set of services tailored to the situation at hand. Such an enterprise service architecture integrates services and components from different owners, is open to new services, and optimises investment needs by being able to integrate legacy services as well. In such settings, the owner of the business has to rely on the functionality and properties of the components that are not completely under his control. This raises particular challenges when it comes to meeting requirements on auditing, monitoring, and reporting as given by recent regulations (e.g., SarbanesOxley or Basel II: The owner of the business is responsible for compliance to the regulations), but has to enforce the requirements even for components and services not under his control. This application scenario consists on an enterprise software application built through orchestration of set of services that are made available through a serviceoriented architecture. The service architecture is spanning over several organisations (companies), thus the set of services is not centrally controlled. A typical example is a supply chain application, consisting, from a simpliied point of view, of tasks quotation (including subtasks such as request-for-quote, submit-quote, place-order, etc.), order processing (including subtasks such as check-order, schedule-manufacturing, purchase-components, etc.), and order fulilment (including subtasks such as manufacturing, shipping, invoicing, etc.). Each of the subtasks is provided by a service (that might be structured itself, since each subtask represents a complex process (e.g., accessing several databases and performing several actions)), potentially owned by different entities. Distributed ownership occurs, for instance, Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

if subtasks are offered by specialist providers (e.g., invoicing or procurement is outsourced by a company). Let’s assume that the services offering the subtask functionality (functional services) only satisfy basic security properties, like local (from a service point of view) authentication mechanisms — the invoicing service includes a login function — and basic authorisation — a user logging in to the invoicing service has to be assigned to an appropriate role. Let’s further assume that the application owner has advanced security requirements, since, for example, the application may be subject to auditing and reporting requirements. These requirements may include, for instance, a non-repudiable event log containing each invoice issued by the invoicing service, advanced authentication mechanisms for triggering the manufacturing service, or integrity protection for the communication between services.

SERENITY.at.Work.1 The SERENITY framework can be used to implement the advanced security requirements at the time of the design of the application by taking advantage of available advanced patterns and integration schemes or by representing the speciic solutions required by the system as new S&D patterns and integration schemes. The framework will be then used at runtime providing dynamic reaction capabilities and monitoring support. At design time, we assume that the application developer is aware of the functional services he is about to orchestrate into his application, and the basic security mechanisms and properties they offer. This is a valid assumption for common development environments. Note that we do not require the security properties being speciied compliant to the SERENITY framework: requirements imposed by integration schemes may later be veriied informally. However, the approach provides stronger results if the security properties of the functional services can be mapped to SERENITY pattern descriptions, since this provides a stronger evidence for the claimed properties. Such a mapping can be achieved through usage of the SERENITY framework in the development of the functional services.

SERENITY.at.Work.2

Application developer speciies the advanced requirements through the SERENITY framework. The framework offers the languages and tools necessary to do so, on different levels of abstraction matching different types of properties. In our example, we have the integrity requirement referring to the communication (i.e., network and devices level) and the event log and non-repudiation requirement referring to a worklow and service level. The SERENITY framework then assists the application developer in selecting those patterns out of the available library that are likely to satisfy the requirements. For each requirement, the framework may suggest several patterns: for integrity protection, it might suggest using an integrity-preserving communication protocol or applying digital signatures to the Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



messages that are communicated. Formal speciications attached to the patterns allow analysing their properties (e.g., environment assumptions) and matching them with the application speciic requirements. For instance, a pattern for event logging might assume a reliable clock. Patterns also indicate dependencies: a digital signature pattern requires a PKI pattern and the properties of the digital signature pattern depend on properties of the PKI pattern selected. The patterns selected through the framework result in the design of a security architecture (i.e., a set of security services and their properties). The example shows that typically patterns are selected for each property in isolation.

SERENITY.at.Work.3 In order to avoid undesired interference between the patterns, the resulting architecture has to satisfy restrictions imposed by integration schemes. An application can only be considered secure if all applying integration schemes are satisied. Indeed integration schemes may also impose assumptions on trustworthiness. For example, if we choose an “SSL pattern” for integrity protection and a “signature pattern” for non-repudiation, an integration scheme will require the use of different cryptographic keys for the two patterns. If we choose to implement the event log pattern locally attached to the invoicing service, this will only be allowed if the invoicing service is owned by the application owner (because the application owner is responsible for reporting, and obviously trusts himself). If the invoicing service is run by a different owner (in case of outsourcing), the integration scheme either requires a trust establishment mechanism (again represented by different patterns) or a non-repudiation mechanism (another pattern).

SERENITY.at.Work.4 If the solutions suggested by the system are not considered appropriate by the application designer, there are several actions that can be taken: • • •

Enter an iteration loop in the framework, by selecting a different architecture (e.g., by choosing a “trusted third party pattern”) subject to different restrictions, dependencies, and integration schemes; Acquire new solutions (patterns and/or integration schemes) from third parties; or The developers can even create new security solutions and then use the “security engineering” interface of the SERENITY framework to validate their solutions and to specify them as S&D patterns and integration schemes. After these are incorporated into the library of available solutions, they can go back to the “system engineering” interface in order to analyse their system in the light of the new solutions developed.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

The example above illustrates the use of the SERENITY framework in the design of a secure service-oriented business application. An advanced instantiation of the framework will provide service implementations realising the patterns, enabling the dynamic coniguration of application-speciic security architectures. The process at design time remains the same, with the framework additionally offering the security services described by the patterns used and integrating them through the service infrastructure. Through such architecture, the framework additionally offers the necessary runtime support. A variant of the previous scenario consisting on the establishment and execution of virtual organisations illustrates the runtime support aspects of the framework. A virtual organisation consists of entities dynamically setting up business relationships to follow a common goal that the individual entities cannot achieve by themselves. In order to set up the organisation, the entities negotiate properties, including security functionalities, policies, and conigurations. The SERENITY framework supports virtual organisations by establishing an appropriate security solution according to the security capabilities of the different entities involved and the environment of the virtual organisation, and by adapting it, if necessary, to changes within the lifetime of the virtual organisation.

SERENITY.at.Work.5 The runtime validation mechanisms of SERENITY can monitor a range of security issues dynamically. SERENITY monitors can, for instance, be used to monitor the satisiability of the assumptions made by speciic security patterns about the behaviour of the parties involved in them. Consider, for instance, a pattern realising an interaction of fair-exchange where a service A places an order for digital goods that can be delivered electronically (e.g., a business report) to a supplier service B with a partial signature of it as proof and, following the receipt of the goods from B, it is expected to deliver its full signature to B that can be used to obtain payment. In this case, SERENITY monitors can check the behaviour of the involved parties that guarantee fairness. They can, for instance, check that B does not produce a valid signature of A without having received it from A earlier and that A does send the expected signature to B following the dispatch of the goods. Run-time monitoring can be also deployed to detect attacks that can lead to denial of service by the parties involved (e.g., crashing suppliers by sending them extremely large inputs on purpose, looding suppliers with a huge number of fake requests from a speciic “manufacturer”, etc). The supply chain use case above can be extended to virtual organisations as follows. Consider the different roles taking part in the scenario, including supplier, manufacturing, invoicing, administration, notary etc., being virtualised through services within the SERENITY framework embedded in a service architecture. The manufacturer service, as the coordinator of the virtual organisation to be established, issues a request for quotes that can be answered by all supplier services available. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



The incoming quotes are evaluated by the manufacturer according to several criteria, including the security properties offered by the respective supplier. The manufacturer selects the best offer and establishes the organisation with its providing service. During lifetime of the virtual organisation the manufacturer might decide to add an additional supplier, giving rise to additional or modiied security requirements (e.g., keeping the conidentiality of the quotes of the individual suppliers). The SERENITY framework supports the setup of the initial security architecture and its adaptation to evolving requirements. In its initial phase, with only one supplier given, the main security requirement of the manufacturer is the provision of a non-repudiable event log from the supplier (cf. design time use case above). If the services are equipped with SERENITY compatible speciications of their security abilities (e.g., through references to security patterns applying), the framework can decide (through the use of integration schemes) whether the required security properties can be met with the given service orchestration. In our example, the following cases may happen (we only consider security and assume that all other criteria applying to the supplier service are met): 1.

2.

3.

4.

The supplier provides a non-repudiable event log on its own, according to the appropriate S&D pattern of the library. Through the framework, the manufacturer detects that the pattern is suficient to meet his requirement, and engages with the supplier in the virtual organisation. The supplier provides an event log according to an event log pattern, but no non-repudiation mechanism. The framework offers an integration pattern expressing that a non-repudiable event log can be achieved through the integration of a trusted third party service. If such a service is part of the service universe, it can be integrated, conigured according to the integration scheme, and virtual organisation establishment continued. The SERENITY framework can support in detecting and integrating such a service by providing service references, or even offering such a service on its own. The supplier provides no logging mechanism at all. Then, another integration scheme may apply (e.g., requesting an advanced trusted third party mechanism). If no patterns and integration schemes offered by the SERENITY framework apply, the manufacturer service can conclude that his security requirements cannot be met (at least not through the given framework instantiation) and reject the quote.

The runtime monitoring mechanisms of SERENITY can further address non repudiation in cases (2)-(4). The basic capability offered by monitors in these cases would be the recording and provision of an event log (e.g., by intercepting and logging inter-service communication events (order placing and order acceptance events)). This task may be carried out by monitors acting on behalf of the manufacCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

turer in case (2) in order to provide information that can be cross-checked against the event log provided by a supplier, or by monitors acting a trusted third parties in case (3). The provision of this capability can be deemed suficient for engaging in interactions that would have normally been avoided, as in case (4). If a second supplier enters the virtual organisation, additional security requirements apply: the individual quotes issued by the suppliers should be kept conidential. The virtual organisation host is aware of the additional requirement either through this being encoded as part of the manufacturer service, or through the framework. In the latter case, the manufacturer signals the change in the organisational structure to the framework, which checks for integration schemes applying. Such integration scheme is likely to suggest a modiication of the security architecture (e.g., by adding additional services, or changing conigurations of existing services). The modiication is executed as indicated above, either through the virtual organisation itself, or through the SERENITY framework. In order to show the applicability of the SERENITY approach and framework to the broad spectrum of systems appearing in the AmI ecosystem realm, the e-business application scenario is complemented by three additional scenarios showing different characteristics: (1) mobile communications, with absence of central control and emphasising on the need to adapt security polices with respect to location and communication infrastructure context, (2) sensor networks, having to deal with limited capabilities of devices and their public exposure, (3) e-government, with applications subject to laws and regulations, and the demand to integrate in existing platforms showing the scalability of the SERENITY approach.

RELATED. WORK Even if the provision of appropriate S&D mechanisms for AmI ecosystems remains an unsolved issue, several approaches have been introduced with the goal of capturing the specialized expertise of security engineers and making it available for automated processing, thus providing the basis for automated synthesis and analysis of the security and dependability solutions of systems (Schmidt, 2003): Components capture expertise in the form of reusable software elements having a set of well-deined interfaces and an associated description of their behaviour (Llewellyn-Jones, Merabti, Shi, & Askwith, 2004; Mantel, 2002; Shi & Zhang, 1998). This concept is not appropriate to represent general security solutions because security mechanisms can not always be represented as units that can be connected to the rest of the system by well deined interfaces. Many security mechanisms are not about what but how. In fact, software components are good abstractions of functional elements, but security and dependability are non-functional aspects. Frameworks capture expertise in the form of reusable algorithms, extensible architectures, and component implementations. Application frameworks (BEA, 2003; Fayad, Johnson, & Schmidt, 1999; Llewellyn-Jones, 2004) have emerged Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



as a powerful technology for developing and reusing middleware and application software. In line with the general deinition, the concept of security framework is frequently used to refer to system architectures, infrastructures, algorithms or even methodologies and processes that are used to provide security in certain scenarios. Also related to security, conceptual frameworks have been proposed as a means to describe security properties. Because frameworks are application templates, they are not well suited to cope with scenarios with high degrees of heterogeneity, dynamism, and unpredictability. Likewise, this approach does not support secure interoperation with external (and not trusted) elements. Middleware capture expertise in the form of standard interfaces & components that provide applications with a simpler facade to access the powerful and complex capabilities of frameworks. Some of the most successful techniques and tools devised to enhance the reuse of software focus on distributed computing middleware that helps manage the complexity and heterogeneity of distributed applications. Although the lexibility, eficiency and interoperability with external elements of middleware-based systems are not optimal, some research has been carried out on the application of this approach to ubiquitous computing (Banavar & Bernstein, 2002; Román, Hess, Cerqueira, & Ranganathan, 2002). An important problem with middleware-based approaches is that the computational cost of the middleware components is far too high for computing devices with limited capabilities. Finally, the security infrastructure of middleware systems is usually restricted to authorization and access control issues (BEA, 2003; OMG, 2004). Patterns capture expertise in the form of reusable architecture design themes and styles, which can be reused even when algorithms, components implementations, or frameworks cannot. The concept of security pattern as “a well-understood solution to a recurring information security problem” was introduced to support the system engineer in selecting appropriate security or dependability solutions. However, most security patterns are expressed in a textual form, as informal indications on how to solve some (usually organizational) security problem (Blakley & Heath, 2004; Cheng, Konrad, Campbell, & Wassermann, 2003; IBM, 2004; Kienzle & Elder, 2003; Romanosky, 2002; Schumacher, 2003; Wimmel & Wisspeintner, 2001; Yoder & Barcalow, 2000). Some of them use more precise representations based on UML diagrams, but no rich semantic descriptions are included in order to automate their processing and to extend their use. Furthermore, there is no guarantee of the correct application of a pattern because the description does not consider the effects of interactions, adaptation, and combination. This makes them not appropriate for automated processing. Finally, because this type of patterns is not designed to be integrated into the users’ systems but to be implemented manually, the problem of incorrect implementation (the most important source of security problems) remains unsolved. Aspect.Oriented.Development.is another paradigm investigated by researchers in an attempt to capture the specialized expertise of security engineers and to make Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

it available for non-expert developers. The popularity of aspect-oriented approaches has originated research on its application to the ield of security. Unfortunately, aspects are mainly an implementation technique and not suitable to provide and manage security solutions as a whole. The dynamic.validation and adaptation of S&D mechanisms is another necessary activity when breaches or threats are detected. The need for run-time monitoring has been argued extensively in the scientiic literature (Feather et al., 1995, 1998; Robinson, 2002) and there have been several strands of research focusing on different system aspects. Research in run-time security monitoring has produced techniques focusing on monitoring security policies (Damianou, Dulay, Lupu, & Sloman, 2001; English, Terzis & Nixon, 2004; Ko, 1996; Serban, 1996). Typically, these policies refer to security conditions at an infrastructure layer (e.g., network connections) and fail to relect application level and context speciic security requirements. Furthermore, techniques in this area monitor security conditions in isolation and, therefore, are unable to detect security breaches and threats which arise due to interactions between different functional and dependability requirements and security requirements, or breaches and threats which arise due to violations of conditions that relate to non infrastructural system aspects (e.g., negligence at the level of system users). Research in general requirements monitoring (Cohen et al., 1997; Feather et al., 1995, 1998; Robinson, 2002; Robinson, 2004) has been concerned with the speciication of requirements for monitoring, the transformation of these requirements into events that can be monitored at run-time, and the development of mechanisms to support the generation and monitoring of these events. Most of the existing techniques express requirements in some high level formal speciication language and assume the manual transformation of requirements onto monitorable events (Feather et al., 1995; Robinson, 2004). Due to the lack of systematic support for it, however, this manual transformation has a large cost that prohibits the wide use of the relevant techniques. Furthermore, existing techniques provide limited support for system adaptation following the identiication of requirement breaches. Research in dynamic program veriication has focused on the development of generic components for program monitoring platforms including program instruments that can generate the events required for monitoring (e.g., jMonitor) (Karaorman, 2004) and general monitoring algorithms (e.g., algorithms for checking formulas expressed in temporal logics) (Thati & Rosu, 2004) but does not directly support the monitoring of higher level system requirements such as security and dependability requirements.

CONCLUSION In the future and especially in a society where information and other digital assets are seen as a high-value commodities, the security and dependability chalCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



lenges will arise from complexity, ubiquity, and autonomy of computing and communications, as well as from the need for mobility, dynamic content and volatile environments. In the next 10 to 15 years, the communication frameworks will have to support operating scenarios where it will not be possible to rely on a-priori welldeined systems having a pre-established security manager. We have given the challenges ahead to the development of an S&D Engineering framework that will release expertise and solutions to allow people to build secure and dependable applications for AmI environments, and to monitor the security and dependability of these applications in different operational contexts. The different methods and tools constituting that we have advocated will be consistently incorporated into an integrated framework that considers real-world requirements as the drivers for more secure and dependable systems. Surprisingly enough this is not just a research manifesto. Our ideas are backed up by a concrete R&D project proposed by a number of leading academic partners (City University of London, Fraunhofer Institute for Secure Information Technology, Katholieke Universiteit Leuven, Università di Trento, University of Aegean and University of Málaga) and key industry players (Engineering Ingegneria Informatica S.p.A, Athens Technology Center, ATOS Origin, Deep Blue, NOKIA, SAP AG, Security Technology Competence Centre, Stratégies Telecoms & Multimedia and Thales) and supported by the European Commission (Unit: ICT Trust and Security, Area: Towards a global dependability and security framework) under the grant IST27587. Time will tell whether such efforts and expertise will be well invested. We are conident it will be so.

ACKNOWLEDGMENT The authors wish to express their gratitude to all members of the SERENITY Consortium and the European Commission for the support and the contributions provided for the deinition of this chapter. This work is partially supported by the E. U. through project IST-02758.

REFERENCES Anderson, R. (2001). Security engineering: A guide to build dependable systems. New York: Wiley & Sons. Banavar, G., & Bernstein, A. (2002, December). Software infrastructure and design challenges for ubiquitous computing applications. Communications of the ACM, 45(12), 92-6. BEA. (2003). BEA WebLogic security framework: Working with your security ecosystem. Retrieved May 2003, from http://www.bea.com Bensalem S., Bozga, M., Krichen, M., & Tripakis, S. (2004). Testing conformance of real-time software by automatic generation of observers. Proceedings of Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

the 4th Workshop on Runtime Veriication (RV’04). Retrieved January 2005, from http://ase.arc.nasa.gov/rv2004 Blakley, B., Heath, C., & members of The Open Group Security Forum (2004). Security design patterns (SDP) technical guide. Retrieved from http://www. opengroup.org/security/gsp.htm Cheng, B. H. C., Konrad, S., Campbell, L. A., & Wassermann, R. (2003, September). Using security patterns to model and analyze security requirements. High Assurance Systems Workshop (RHAS03), Monterey Bay, CA. Cohen, D., Feather, M., Narayanaswamy, K, & Fickas, S. (1997). Automatic monitoring of software requirements. Proceedings of the 19th International Conference on Software Engineering. Damianou, N., Dulay, N., Lupu, E., & Sloman, M. (2001). The ponder policy speciication language. POLICY 2001 (pp. 18-38). LNCS. Berlin Heidelberg: Springer-Verlag. English, C., Terzis, S., & Nixon, P. (2004). Towards self-protecting ubiquitous systems monitoring trust-based interactions. Proceedings of UbiSys ’ 04. Fayad, M., Johnson, R., & Schmidt, D. C. (1999). Building application frameworks: Object-oriented foundations of framework design. Wiley & Sons. Feather, M., et al. (1998). Reconciling system requirements and runtime behaviour. Proceedings of the 9th International Work on Software Speciication & Design. Feather, M., & Fickas, S. (1995). Requirements monitoring in dynamic environments. Proceedings of International Conference on Requirements Engineering. Focardi, R., & Rossi, S. (2002). Information low security in dynamic contexts. Proceedings of the 15th IEEE Computer Security Foundations Workshop. CSFW 15. Gruber, T. R. (1993). Toward principles for the design of ontologies used for knowledge sharing. In N. Guarino & R. Poli (Eds.), Formal ontology in conceptual analysis and knowledge representation. Dordrecht, The Netherlands: Kluwer Academic Publishers. IBM’s Security Strategy team (2004). Introduction to business security patterns. An IBM White Paper. Retrieved from http://www-3.ibm.com/security/patterns/intro.pdf Karaorman, M., & Freeman, J. (2004). jMonitor: Java runtime event speciication and monitoring library. Proceedings of the 4th Workshop on Runtime Veriication (RV ’04). Retrieved January 2005, from http://ase.arc.nasa.gov/rv2004 Kienzle, D. M., & Elder, M. C. (2003). Final technical report: Security patterns for Web application development. Retrieved March 2005, from http://www. scrypt.net/~celer/securitypatterns/inal%20report.pdf Ko, C. (1996). Execution monitoring of security-critical programs in a distributed system: A speciication-based approach. PhD Thesis, University of California at Davis. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Security Engineering for Ambient Intelligence



Llewellyn-Jones, D., Merabti, M., Shi, Q., & Askwith, B. (2004, April). An extensible framework for practical secure component composition in a ubiquitous computing environment. Proceedings of International Conference on Information Technology, Las Vegas, USA. López, J., Maña, A., Pimentel, E., Troya, J. M., & Yagüe, M. I. (2002). Access control infrastructure for digital objects. International Conference on Information and Communications Security 2002. LNCS. 2513. Singapore: Springer-Verlag. Mahbub, K., & Spanoudakis, G. (2004). A framework for requirements monitoring of service based systems. Proceedings of the 2nd International Conference on Service Oriented Computing, ICSOC 2004. New York. Mahbub, K., & Spanoudakis, G. (2005). Run-time monitoring of requirements for systems composed of Web-services: Initial implementation and evaluation experience. The 3rd International IEEE Conference on Web Services (ICWS 2005). Maña, A., Montenegro, J. A., Ray, D., Sánchez, F., & Yagüe, M. I. (2003). Integrating & automating security engineering in UML. IASTED International Conference on Communication, Network and Information Security (CNIS’03). New York: Acta Press. Mantel, H. (2002). On the composition of secure systems. Proceedings of the 2002 IEEE Symposium on Security and Privacy. Object Management Group. (OMG). Common Object Request Broker Architecture (CORBA) Core Speciication. Retrieved July 2004, from http://www.omg. org Robinson, W. (2002). Monitoring Software requirements using instrumented code. Proceedings of the Hawaii International Conference on Systems Sciences. Robinson, W. (2004). Monitoring Web service requirements. Proceedings of the 4th Workshop on Runtime Veriication (RV ’04). Retrieved January 2005, from http://ase.arc.nasa.gov/rv2004/ Román, M., Hess, C. K., Cerqueira, R., Ranganathan, A., Campbell, R. H., & Nahrstedt, K. (2002, October-December). Gaia: A middleware infrastructure to enable active spaces. Proceedings of IEEE Pervasive Computing (pp. 74-83). Romanosky, S. (2002). Enterprise security patterns. Proceedings of the 7th European Conference on Pattern Languages of Programs. Schmidt, D. C. (2003, May 3-10). Patterns, frameworks, and middleware: Their synergestic relationships. Invited talk at IEEE/ACM International Conference on Software Engineering, Portland, Oregon. Schumacher, M. (2003). Security engineering with patterns: Origins, theoretical model and new applications. Springer. Serban, C., & McMillin, B. (1996). Run-time security evaluation (RTSE) for distributed applications. IEEE Symposium on Security and Privacy. Shi, Q., & Zhang, N. (1998, November). An effective model for composition of secure systems. Journal of Systems and Software, 43(3), 233-44. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 Maña, Rudolph, Spanoudakis, Lotz, Massacci, Melideo, & López-Cobo

Thati, P., & Rosu, G. (2004). Monitoring algorithms for metric temporal logic speciications. Proceedings of the 4th Workshop on Runtime Veriication (RV ’04). Retrieved January 2005, from http://ase.arc.nasa.gov/rv2004/ Tryfonas, T., Kiountouzis, E., & Poulymenakou, A. (2001). Embedding security practices in contemporary information systems development approaches. Information Management & Computer Security, 9(4), 183-197. Wimmel, G., & Wisspeintner, A. (2001). Extended description techniques for security engineering. In M. Dupuy & P. Paradinas (Eds.), Trusted information: The new decade challenge, IFIP TC11. The 16th International Conference on Information Security (IFIP/Sec’01) (pp. 470-485). Paris: Kluwer Academic Publishers. Yagüe, M., Maña, A., & Sanchez, F. (2004). Semantic interoperability of authorizations. Security in information systems. Proceedings of the 2nd International Workshop on Security In Information Systems, WOSIS 2004. Yang, H., Luo, H., Ye, F., Lu, S., & Zhang, L. (2004, February). Security in mobile ad hoc networks: Challenges and solutions. IEEE Wireless Communications, 11(1), 38-47. Yoder, J., & Barcalow, J. (2000). Architectural patterns for enabling application security: Pattern languages of program design 4 (pp. 301-336). Reading, MA: Addison Wesley.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering 

Chapter.XII.

Integrating.Security.and. Software.Engineering: Future.Vision. and.Challenges H. Mouratidis, University of East London, UK P. Giorgini, University of Trento, Italy

ABSTRACT The previous chapters of this book have presented promising approaches in the secure software engineering ield. However, the ield is still in its infancy and a number of challenges still need to be answered. The main aim of this chapter is to list and discuss nine challenges that we ind important for the advance of the secure software engineering ield. The main idea behind each challenge is presented in a short sentence followed by a discussion, which indicates why the challenge is important. In some cases, the discussion provides some ideas of how the challenge could be met.

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

INTRODUCTION It has been widely argued in the literature, and throughout this book, that although the need to integrate security within software engineering practises has been identiied at least for the last three decades, up to few years ago most of the efforts to solve such problem were random approaches initiated from individual researchers. However, and as it is evidence from the chapters of this book, the last few years the number of researchers working towards approaches to solve this problem has increased substantially. This evolving situation is the result of two main factors. Firstly, the broad awareness of the need to secure software systems has resulted in the identiication of the situation as a key challenge for software and security engineers. Secondly, the appearance of specialised research events, which emphasise the need to integrate security issues within the software system development practice (see for example www.sreis.org and http://www.jmu.edu/iiia/issse/). Most of the researchers and practitioners involved in such research and/or events mainly have the same future vision. The maturity of secure software engineering in such a degree that software developers will be able to model, construct, test, deploy, and maintain secure software systems through well deined and structured processes and with the aid of appropriate modelling languages. In such a vision, development is made even easier with the aid of computer-aided tools that enable to accurately track the security solution to the initial system requirements and therefore validate it against the security goals of the organisation where the system is deployed. The previous chapters of this book have discussed work that brings us closer to that vision. In particular, the previous chapters have presented approaches and frameworks that allow reasoning about security requirements, methodologies, and pattern languages to model security requirements and support the development of secure software systems. However, many challenges still need to be answered by researchers and practitioners working in the ield. The rest of this chapter list and discusses nine challenges that we ind important for the advance of the secure software engineering ield.

THE. CHALLENGES Challenge.1:.Unify.Efforts.to.Integrate.Security.and. Software.Engineering

Although the need for such uniication has been recognised by various researchers (see for example the literature review presented in Chapter I or the discussions in the previous chapters of this book), work on integrating security and software engineering is mainly carried out independently either by members of the security research community or by members of the software engineering community. It is important to unify the efforts on the two ields. Only then we will be able to precisely Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering 

identify the technical as well as the social issues that surround the development of secure information systems and produce solutions that truly work.

Challenge.2:.Consider.the.Social.Dimension.of.Security Security is mainly considered as a technical issue by software and security engineers alike. However, it is now widely accepted that a technical only approach in the development of secure software systems will not produce the expected results, since security is a multidimensional issue that cannot be considered in isolation. Especially, with the advances on software systems and the transition towards open and autonomous systems, issues such as sociality, trust, privacy, and delegation of responsibilities are closely related to the security of software systems. This argument is also supported by recent research, which has shown that the human factor has a signiicant impact on security. For example, one of the main threats to medical private records is social engineering. Social engineering is a non-technical kind of intrusion that relies on human interaction and involves tricking other people (doctors, or nurses in the case of medical records) to break normal security procedures. A mature solution that integrates security and software engineering should consider not only the technical dimension of security but also the social dimension. It is only when we consider both dimensions that we will be able to develop secure enough information systems.

Challenge.3:.Develop.Complete.Security.Ontology The need for sound and complete security ontology is well recognized as an important issue for the development of widely accepted solutions on secure software engineering. Such ontology will provide a irm and well-understood foundation to support the development of appropriate methods, processes, and methodologies. At present, work on deining such ontology is carried out independently by the software engineering and security engineering research communities. This separation of work has resulted in an abstraction gap, which makes the integration and practical application of security issues on software engineering practices dificult. As an example, consider the term “security requirement.” Although this term is fundamental; so far, it is used and interpreted differently by various researchers and practitioners (see Chapter II by Haley et al.).

Challenge 4: Deine a Suitable Exemplar Typically, in software engineering, various approaches will be demonstrated using case studies, which are tailored to emphasise the key characteristics of the approach. However, such case studies often focus on speciic problems. It is important, therefore, to deine a suitable example problem (in software engineering community the term exemplar is widely used when referring to an example problem) which will emphasize the problems faced by the community and it will serve as a focal point for discussion and exchange of research ideas and results. In choosing Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Mouratidis & Giorgini

such an exemplar various criteria should be considered. For instance, the exemplar should be broad enough to cover all the possible issues, technical or social, that are associated with the development of secure software systems. Moreover, it should be generic enough as well as rich and complex enough to test the limits of any proposed approach.

Challenge.5:.Evaluate.the.Different.Software.Engineering. Paradigms.with.Respect.to.their.Appropriateness.to. Integrate.Security Various software engineering paradigms exist such as model-driven, aspectoriented, and agent-oriented. All these treat software system development differently, using their own set of concepts and techniques. It is very important to identify the strengths and weaknesses of each of these paradigms when integrating security into the development process.

Challenge.6:.Development.of.New.Techniques,.Methods,. Processes.that.Consider.Security.as.Part.of.the.Software. System.Development.Lifecycle At present, most existing methodologies and models concentrate only on speciic stages of the development process, such as security requirements engineering, or security design. It is vital, however, that security is considered throughout the development process and it is considered alongside the functional requirements and other non-functional requirements of the system-to-be. It is only then that we can consider security as part of the development process and not an isolated concept of the system. Therefore, it is important to develop new methods and techniques. These should support the formal (and simultaneous) modelling, reasoning and analysis of security and functional requirements, and the transformation of such (security and functional) requirements to a design that will satisies them. Moreover, one of the main problems of considering security during the development stages of an information system is the lack of methods and techniques to trace the provided functionality to security requirements and also test the solution before the implementation of the system. Therefore, it is crucial to develop new methods and techniques to support traceability and validation of the proposed solution.

Challenge.7:.Tool.Support Integrating security in the development process means adding extra activities in an already dificult task. Therefore, it is of paramount importance to produce tools to support the development process. A tool should not only support developers in modelling and reasoning about security (and functional requirements) during the analysis stage, but it should help to transform the requirements to design, check the

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Integrating Security and Software Engineering 

consistency of the proposed solution and also validate the security functionalities of the proposed solution against the security requirements of the system.

Challenge.8:.Transfer.of.Security.Knowledge Many system developers do not always have a strong background in computer security and lack expertise in secure software system development. Nevertheless, in practice, they are asked to develop information systems that require security features. Secure software engineering methodologies should consider that issue and provide methods and processes that allow even developers with minimum security expertise to analyse and design a system with security in mind. At present, security patterns seem to provide a right step into this direction, as also argued in some of the chapters of this book. However, there is a need to enhanced current pattern languages and provide a better integration with software engineering processes and methods.

Challenge.9:.Transit.Research.Results.to.Mainstream. System.Development An important, long-term, challenge is the successful transfer of research knowledge and best practice on developing secure software systems to industry. To achieve this, there is a need to make secure software engineering practice widely known (research and industry), standardize them, and provide an agreed set of techniques, models and methodologies. This will ensure trust in the proposed methods and industrial conidence.

CONCLUSION As discussed throughout this book, to adequately support the development of secure software systems, security should not be considered as a pure technical issue added as an afterthought, but security considerations must be integrated into the software engineering practice. However, the latter is not an easy task, and this chapter has presented and discussed a list of challenges faced by everyone working towards this goal. We do not argue that the above list is neither complete nor exhaustive. A careful study of the above challenges might generate some extra challenges or more precise ones. We believe, however, that the above list of challenges provides a good indication of the future direction of the secure software engineering ield. Moreover, the above challenges should not be considered in isolation. In fact, most of them are highly associated with each other. Take as an example the development of a complete security ontology (challenge 3). An important ingredient of such ontology is the inclusion of concepts related to the social issues that surround security (challenge 2).

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 About the Authors

About.the.Authors

Haralambos.Mouratidis received his BEng (Hons) in electronics with computing science from the University of Wales, Swansea; his MSc in data communications and PhD in computer science from the University of Shefield, UK. He is currently a lecturer at the University of East London, UK, where he (co)-founded the Security Engineering and Intelligent Systems (SEIS) research group. His research interests lie in the areas of security engineering, software engineering and multiagent systems and the results of his research work have been published in international refereed journals and conferences such as Information Systems, AAMAS, AOSE, and CAiSE. Haralambos has (co) initiated the International Workshop Series on Safety and Security in Multiagent Systems, and he has served on the programme committee of many international and national conferences and workshops such as CaiSE, IEEE/WI, IEEE/IAT, AOSE, SASEMAS, and AOIS. Paolo.Giorgini is a researcher at the University of Trento, Italy. He received his PhD from the Computer Science Institute of University of Ancona (Italy) in 1998. Between March and October 1998 he worked at the University of Macerata and the University of Ancona as research assistant. In November 1998, he joined the Mechanized Reasoning Group (MRG) at the University of Trento as a pos-doc researcher. In December 1998, he was a researcher visiting the Computer Science Department of the University of Toronto (Canada). More recently, he was a visiting professor with Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

About the Authors



the Software Engineering Department of the University of Technology, Sydney. Dr. Giorgini has worked on the development of requirements and design languages for agent-based systems, and the application of knowledge representation techniques to software repositories and software development. He is one of the founders of Tropos, an agent-oriented software engineering methodology. His publication list includes more than 100 refereed journal and conference proceedings papers and ive edited books. He has contributed to the organization of international conferences as chair and program committee member, such as CoopIS, ER, CAiSE, AAMAS, EUMAS, AOSE, AOIS, and ISWC. He is co-editor-in-chief of the International Journal of Agent-Oriented Software Engineering (IJAOSE).

*.*.*

R..Baskerville is the chairman and a professor with the Department of Computer Information Systems, J. Mack Robinson College of Business, Georgia State University (USA). His research specializes in security of information systems, methods of information systems design and development, and the interaction of information systems and organizations. His interests in methods extend to qualitative research methods. Baskerville is the author of Designing Information Systems Security (J. Wiley) and more than 100 articles in scholarly journals, practitioner magazines, and edited books. He is an editor of The European Journal of Information Systems, and associated with the editorial boards of The Information Systems Journal and The Journal of Database Management. Baskerville’s practical and consulting experience includes advanced information system designs for the U.S. Defense and Energy Departments. He is the former chair of the International Federation for Information Processing Working Group on Information Systems and Organizations, a chartered engineer under the British Engineering Council, a member of The British Computer Society and certiied computer professional by the Institute for Certiication of Computer Professionals. Baskerville holds degrees from the University of Maryland (BS, summa cum laude, management), and the London School of Economics, University of London (MSc, analysis, design and management of information systems, PhD, systems analysis). E..B..Fernandez (Eduardo Fernandez-Buglioni) is a professor with the Department of Computer Science and Engineering at Florida Atlantic University in Boca Raton, Florida (USA). He has published numerous papers on authorization models, object-oriented analysis and design, and fault-tolerant systems. He has written three books on these subjects. He has lectured all over the world at both academic and industrial meetings. He has created and taught several graduate and undergraduate courses and industrial tutorials. His current interests include security patterns and Web services security. He is currently the leader of a project on wireless Web serCopyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 About the Authors

vices security for the Department of Defense. He holds an MS degree in electrical engineering from Purdue University and a PhD in computer science from UCLA. He is a senior member of the IEEE, and a member of ACM. He is an active consultant for industry, including assignments with IBM, Allied Signal, Motorola, Lucent, and others. He wrote the irst book on database security (Addison-Wesley, 1981) and is now completing two books on security. For more information, visit http://www. cse.fau.edu/~ed. R..France.(Robert France).is a professor with the Department of Computer Science at Colorado State University (USA). His research interests are in the area of software engineering, in particular formal speciication techniques, software modelling techniques, design patterns, and domain-speciic modelling languages. He is editorin-chief of the Springer journal, Software and System Modeling (SoSyM). G..Georg.(GeriGeorge).receivedherbachelor’sdegreeinbiomedicalengineeringfromthe University of New Mexico, and her master’s and PhD degrees in computer science from Colorado State University. She has more than 20 years of experience in software engineering and research at Hewlett Packard Company and Agilent Technologies. She is currently pursuing research in aspect-oriented modelling and techniques needed to bring about its widespread application in industrial software systems development. C..B..Haley (Charles Haley) is a lecturer with the Department of Computing of The Open University. Before re-entering the academic community in 1999, he worked for 25 years in the software industry at companies including Bell Laboratories Computing Science Research Center, Rational Software, Bell Northern Research, and Sun Microsystems, holding positions ranging from software researcher to director of development. Haley joined The Open University in 2003, where his research is in the representation of security requirements, their validation through formal and informal argumentation, and their relationship to system speciications. He holds a BA and MS in computer science from the University of California at Berkeley. For more information, visit http://mcs.open.ac.uk/cbh46/. S..H..Houmb (Sive Hilde Houmb) is a research scientist at Telenor Research and Development in Norway and is currently working on her PhD on techniques for combining disparate information sources for quantifying parameters in security solution design trade-off analysis (computer science) at the Norwegian University of Science and Technology and Colorado State University. Her main research interests are in the area of techniques for secure systems development, security management, design trade-off analysis, software evaluation, risk-driven development (RDD) and model-driven development (MDD). She received a research award for her master thesis, “Stochastic models and mobile e-commerce: Are stochastic models usable Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

About the Authors



in the analysis of risk in mobile e-commerce?” from the Norwegian computer magazine Elektronikk in 2002. J.. Jürjens. (Jan Jürjens) is a researcher at Munich University of Technology, Germany. He is the author of a book on secure systems development with UML (Springer-Verlag, 2004). His main research interests are in the area of security software engineering, formal methods and safety critical systems. He is the initiator and current chair of the working group on Formal Methods and Software Engineering for Safety and Security (FoMSESS) within the German Society for Informatics (GI), and a member of the executive board of the Division of Safety and Security of the GI. He is also on the advisory board for the Bavarian Competence Center for Safety and Security (KoSiB). T..Kuivalainen (Tapio Kuivalainen) is a doctoral student in information systems at the University of Oulu, Finland, where he earned his MSc. His research interests include the methods for the development of security systems, and development of information systems security policies. M..Koch (Manuel Koch) is a researcher in the software engineering and system software group, Computer Science Department, Freie Universität, Berlin. His research interests include security, formal speciication, model-driven development, and distributed systems. He received an MS (Dipl.-Inform.) and a PhD in computer science from Technical University of Berlin and held a research grant in the group of Francesco Parisi-Presicce, Rome. R..Laney (Robin Laney) is a senior lecturer in the Computing Department, Open University, UK. His research interests include requirements engineering, lexible approaches to software architecture, and music computing. His research mission is to focus on activities that bridge the gap between theoretical advances and the experience and problems of working software practitioners, in both directions. He has industrial experience as a software engineer working on programming language technology and graphics. He holds a First Class Honours BSc in microcomputers and applications from Westield College, University of London, and a PhD in computing from King¹s College, University of London. M..M..Larrondo-Petrie.(Maria M. Larrondo Petrie), professor of computer science and engineering and associate dean of academic & international affairs at Florida Atlantic University (USA), has teamed with Dr. Fernandez for more than 10 years in research projects and publications in the area of network and data security. She has been trained at NIST in Common Criteria Protection Proiles. Her position as vice president for research collaboration of the Latin American and Caribbean Consortium of Engineering Institutions will assist in the dissemination of the information to this Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

0 About the Authors

region. She has extensive experience in curriculum writing, having served on ACM SIGGRAPH’s Education Board and as chair of its Computer Science Curriculum Committee. She currently is also on the board of directors of the American Society of Engineering Education’s Minority Division. L..Liu (Lin Liu) is an associate professor of School of Software, Tsinghua University, China. Before joining Tsinghua in 2004, She was a postdoctoral research associate in the Department of Computer Science, University of Toronto. Liu received her PhD in computer science from the Chinese Academy of Sciences (1999). Her research interests include requirements engineering, knowledge management, software engineering methodologies for new Internet-based applications, and modeling techniques for system security, privacy and trust. She contributed to the investigation using i* strategic modeling framework for reasoning about security requirements of enterprise information systems. J..S..López-Cobo received a degree in computer engineering from the University of Málaga and is currently pursuing his PhD in the ield of the Semantic Web services. He worked in iSOCO for four years, being the local manager of two IST projects, SWWS and DIP and involved in other related projects like iBROW. He currently works for Atos Origin, managing the InfraWebs project and collaborating in other projects like SeCSE. He is the technical manager of the Software & Services Unit of the STREAM Department in Atos Origin, mainly focused in the provision of Semantic Web technologies for the whole structure of the department. V..Lotz (Volkmar Lotz) received his diploma in computer science from the University of Kaiserslautern (1988). He is currently the research program manager for security and trust at SAP Research, France. His responsibilities include managing and roadmapping SAP’s security research as well as aligning security research to SAP’s business needs. From 1989 to 2004, he was afiliated with Siemens Corporate Technology, where he was heading the Formal Methods in Security Analysis group between 1999 and 2004, emphasizing on security requirements engineering, evaluation and certiication, cryptographic protocol veriication, and mobile code security. He has published numerous scientiic papers in his area of interest. A..Maña.(Antonio Maña).received his PhD degrees in computer engineering from the University of Malaga (2003). He is currently associate professor of software engineering in the Computer Science Department, University of Malaga, Spain. His current research activities include security and software engineering, information and network security, application of smart cards to digital contents commerce, software protection, DRM and mobile applications. He has participated in several national and international research projects. He is member of different professional

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

About the Authors



and scientiic societies and workgroups and is actively involved in the organization of research and educational activities. F..Massacci.(Fabio Massacci) received a PhD in computer science and engineering at University of Rome “La Sapienza” (1998). In 2001, he joined the University of Trento (Italy) as an associate professor and then full professor, where he chairs the computing and telematic services of the university. In 2001 he received the Intelligenza Artiiciale award, a young researchers career award from the Italian Association for Artiicial Intelligence. He is member of AAAI, ACM, IEEE Computer Society and a chartered engineer. His research interests are in automated reasoning at the crossroads between artiicial intelligence and computer security. N..R..Mead.(Nancy R. Mead).is a senior member of the technical staff in the Networked Systems Survivability Program at the Software Engineering Institute (SEI). The CERT® Coordination Center is a part of this program. Mead is also a faculty member in the Master of Software Engineering and Master of Information Systems Management programs at Carnegie Mellon University (USA). Her research interests are in the areas of software requirements engineering, software architectures, and software metrics. Mead has more than 100 publications and invited presentations. She is a senior member of the Institute of Electrical and Electronic Engineers, Inc. (IEEE) and the IEEE Computer Society and is also a member of the Association for Computing Machinery (ACM). Dr. Mead received her PhD in mathematics from the Polytechnic Institute of New York, and received a BA and an MS in mathematics from New York University. M.. Melideo (Matteo Melideo) received his Diploma di Maturità Scientiica in 1990. He has been in the R&D Department of Engineering since 1997. He has since then been involved in different national and international research projects. Since 2000 he was responsible for the Broker Development Workpackage of the CLARiFi Project. In 2001, he became project manager for engineering in the IST Component+ project. Since 2002, he has been project manager and technical coordinator for engineering of the Italian research project MAIS co-funded by MIUR. He is currently the deputy of coordinator and project manager for engineering in the SeCSE integrated project. J..D..Moffett (Jonathan Moffett) is a visiting senior research fellow in the Department of Computing at The Open University (UK), and an honorary visiting fellow in the Computer Science Department at the University of York, UK, where he was a senior lecturer until his retirement. He acted as advanced MSc course organiser there from 1994-2001. He was a member of the distributed systems engineering group at Imperial College, London from 1986-1992. His previous experience has been as a systems consultant on large commercial systems, including acting as computer controls and security adviser at Esso Europe Inc, and as consultant to one of the Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 About the Authors

London Clearing Banks, for whom he wrote their computer security standards. Dr. Moffett received his bachelor’s degree in mathematics and theoretical physics in 1961 at Trinity College, Cambridge, and his PhD in computing in 1990 at Imperial College, University of London. He is a chartered engineer, a fellow of the Association of Certiied Accountants and a member of the British Computer Society. J.. Mylopoulos (John Mylopoulos) received his PhD degree from Princeton in 1970, the year he joined the faculty of the University of Toronto, Canada. His research interests include information modelling techniques, covering notations, implementation techniques and applications, knowledge based systems, semantic data models, information system design and requirements engineering. Mylopoulos is the recipient of the irst Outstanding Services Award given by the Canadian AI Society (CSCSI), a co-recipient of the best-paper award of the 1994 International Conference on Software Engineering, a fellow of the American Association for AI (AAAI) and the elected president of the VLDB Endowment (1998-01, re-elected for the period 2002-05). He is co-editor of the Requirements Engineering Journal (Springer-Verlag). He is currently leading a number of research projects and is principal investigator of both a national and a provincial Centre of Excellence. B..Nuseibeh (Bashar Nuseibeh) is a professor and director of research with the Department of Computing at The Open University, UK. Previously, he was a reader at Imperial College London and head of the Software Engineering Laboratory. His research interests are in software requirements engineering and design, and technology transfer. His research has been recognised through a number of awards, including a 2002 Philip Leverhulme Prize for outstanding international research achievements, a ICSE-2003 Most Inluential Paper award, and a 2005 Senior Research Fellowship of the UK Royal Academy of Engineering. He is chair of IFIP Working Group 2.9 and editor-in-chief of the Automated Software Engineering Journal. He is a fellow of the British Computer Society and a chartered engineer. For more information, visit http://mcs.open.ac.uk/ban25/. F.. Parisi-Presicce (Francesco Parisi-Presicce) has been a professor of computer science with the Dipartimento di Informatica of the University of Rome “La Sapienza” since 1993, currently on leave to the Department of Information and Software Engineering of George Mason University. He received his PhD and MS in mathematics from the University of Connecticut (1981 and 1977, respectively), and the degree of “Dottore in Matematica” summa cum laude at the University of Rome “La Sapienza” (1975). He is the (co)-author of more than 100 papers that appeared in international journals, books and refereed conference proceedings. His research interests include formal methods in secure system developments, access control models, visual modelling techniques, information system security, and theory and applications of graph transformations. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

About the Authors



K.. Pauls (Karl Pauls) is a PhD candidate and researcher at Klaus-Peter Löhr’s Software Engineering and System Software Group, Computer Science Department, Freie Universität, Berlin, Germany. His research interests include security and access control in distributed systems, component-based software engineering, model-driven development, and distributed systems. Pauls received an MS (Dipl.-Inform.) in computer science from Freie Universität, Berlin. C..Rudolph (Carsten Rudolph) received his PhD in computer science at Queensland University of Technology, Brisbane (2001). He is working as a scientist at the Fraunhofer Institute for Secure Information Technology, Germany. His research concentrates on information security, formal methods, and cryptographic protocols and includes work on tool-supported analysis and design of security protocols, development of formal security models and methods for speciication and reinement of security properties. M..Siponen (Mikko Siponen) is a professor with the Department of Information Processing Science at the University of Oulu, Finland. He received his PhD in information systems at the University of Oulu, Finland, and his DSc in philosophy at the University of Joensuu, Finland. His research focus is on IS security, IS development and ethical aspects of IS. His research work has been published in journals such as Information & Organization, European Journal of Information Systems, Communications of the ACM, Information Systems Journal. Dr. Siponen has received several academic awards, including the outstanding paper award in the 2000 volume of Information Management & Computer Security. T..Sorgente (Tami Sorgente) is a visiting instructor, undergraduate advisor, and PhD student with the Department of Computer Science and Engineering at Florida Atlantic University (USA). She is an active member of the Secure Systems Research Group (SSRG) at Florida Atlantic University. Her research interests include software engineering, data security, object-oriented patterns, and healthcare information management. She has published and co-authored publications on these topics. She earned irst prize at the First IEEE Graduate Student Research Showcase representing the SSRG and her work on Analysis Patterns for Patient Medical Record Contents and the use of OO patterns for secure software development. Sorgente received a master’s degree in computer science from FAU. G..Spanoudakis (George Spanoudakis) is the head of the Department of Computing of City University (UK), a reader in computer science, and leader of the Software Engineering Group in the department. He has more than 10 years of experience in collaborative research and development projects and has been the principal investigator of EU, EPSRC and industry funded projects in this area. His principal research interests are in the area of software engineering. He has more than 50 peer-reviewed publications. He has served on the program and organizing committees of more than Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 About the Authors

20 international conferences and workshops in the area of software engineering and currently is a program co-chair of the 19th International Conference on Software Engineering and Knowledge Engineering. He is also an associate editor of the International Journal of Software Engineering and Knowledge Engineering. M..Vanhilst (Michael Vanhilst) is an assistant professor with the Department of Computer Science and Engineering at Florida Atlantic University (USA). He has published numerous articles in the area of sofware engineering. Prior to coming to FAU, he was a staff member at HP Labs where he worked in the Software Technology Lab with Martin Griss and Mary Loomis. He holds bachelor’s and master’s degrees from the Massachusetts Institute of Technology and a PhD from the University of Washington, where he studied under David Notkin and Nancy Leveson. He currently conducts research for Motorola on advanced development processes, and processes for secure application development for the DoD. Dr. VanHilst is a participant in the NSF funded SWeNET and a member of the executive committee of the Florida IT Center of Excellence. M..Weiss (Michael Weiss) is an assistant professor at Carleton University, Canada, which he joined in 2000 after spending ive years in industry following the completion of his PhD in computer science in 1993 (University of Mannheim, Germany). In particular, he led the Advanced Applications Group within the Strategic Technology Group of Mitel Corporation. His research interests include Web services, software architecture and patterns, security engineering, business model design, and open source. E..Yu (Eric Yu) has been an associate professor of faculty of information studies at University of Toronto (Canada) since 1994. Dr. Yu received his BS in EE and PhD in CS from the University of Toronto. His research interests include information systems analysis and design, software engineering, and knowledge management, and the strategic modelling of social processes and technical systems. He has authored or co-authored more than 50 articles in journals, and conference and workshop proceedings. He contributed to the design of i* strategic modeling framework for reasoning about early requirements of enterprise information systems. He is a principal investigator in research projects on agent-oriented software engineering, network computing, and knowledge management. N..Zannone (Nicola Zannone) received an MS degree in computer science from the University of Verona in 2003. He is currently a PhD student with the Department of Information and Communication Technology at the University of Trento, Italy. He visited the Center for Secure Information Systems, George Mason University, in 2005. His research interests is in formal methods and automated reasoning techniques for computer security. He focuses on the deinition of a formal framework Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

About the Authors



for modeling and analyzing security, privacy and trust requirements on during the early phases of the software development process. Other activities focus on the negotiation of personal information among customers and enterprises and access control frameworks preserving privacy. He has also worked on system security and protocol veriication.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Index

Index

Symbols

B

.NET 112

Bayesian belief nets 191 behavior 21 belief 76 budget constraint 192

A access control 4,220 access control metamodel 224, 226 accountability 134, 195 Acme 57, 61 ACTIVE 197 actor 75 agent 81 agile security method 146 agile software development method 143 ambient intelligence (AmI) 244, 247 analysis stage 111 architecture trade-off analysis method 194 argumentation 18 artifact 19 aspect-oriented modelling 192 aspect model 194, 200 attacker 85 attack tree 6, 49, 59 authentication 4, 114 authenticity 195 automation 35 availability 134, 195

C Carnegie Mellon 43 commercial off-the-shelf 45 components off-the-shelf (COTS) 245 conidentiality 4, 36, 134, 195, 256 contribution link 79 Coplien form 130 core artifact 19 cost beneit analysis method 194 countermeasure analysis 88 customer 72, 145

D decomposition link 79 dependency 77 dependency vulnerability analysis 86 deployment stage 112 design stage 95, 112, 118 digital stored value card 91

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Index

discretionary access control (DAC) 6 domain requirement 82 dynamism 248, 265



e-commerce 192, 197, 209

misuse impact 192, 202 model-driven development 193 modelling language 3, 161, 221, 239 model for automated proile speciication 96 model view controller 118

F

N

feature driven development 143, 149 irewall 120 Foundation for Intelligent Physical Agents (FIPA) 7

network connectivity 109 non-functional requirement 132 non-repudiation 195

G

object constraint language 112, 233 object management group 193

E

gang-of-four (GoF) 130 goal dependency 77

H heterogeneity 249

I i* agent 71 i* modelling framework 162 identiication and authentication (I&A) 114 implementation stage 112 information system 144 information systems modelling 96 information systems Security 245 inner argument 34 integrated security veriication 190 integration scheme 244, 255 integrity 4, 36, 135, 195, 261 Internet 26, 149

J Java 112 joint application design 52

M maintainability 134 maintenance stage 112 mandatory access control (MAC) 6 misuse frequency 192

O

P patient treatment record pattern 117 patterns 107, 129 patterns of software architecture (POSA) 131 pattern representation 132 permission modelling 166 personnel information 27 position 81 prepaid phone card system 92 privacy 272

Q qualitative goal-reasoning mechanism 89

R reliability 195 requirements analysis 150 requirements change 145 requirements engineering 44 requirements stage 111, 113 resource 76 resource dependency 77 return on security investment 192 risk analysis 148 risk assessment 52 role 81 role-based access control 117, 223 role base access control (RBCA) 6

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

 Index

run-time monitoring 244, 253, 258, 266

S S&D pattern 254 satisfaction argument 18 SecureUML 122 secure access point 134 secure entities 164 secure software 109 secure software engineering 2 secure system 46, 96, 107 secure Tropos 160 security 129, 143, 160, 245, 272 security and dependability (S&D) 247 security constraint 164 security constraint modelling 166 security engineering 1, 6, 70, 127, 244, 270 security goals 24, 53 security knowledge 274 security manager 252 security model 92 security pattern 107, 127, 131 security policy 4 security requirement 15, 18, 146 security risk 144, 193, 202, 208 security solution cost 192 security solution effect 192 security veriication 196 semantic analysis pattern 115 SERENITY 244, 247 single access point 135 smart-card system 82 softgoal 76, 80, 84, 163 softgoal dependency 77 software cost reduction 48 software developer 143 software development 144 software engineering 1, 70, 270 software lifecycle 76, 107, 111 software process 110 software requirements speciication 48 software system 1 solution design trade-off analysis 190 SQUARE method 43, 54 stakeholder 9, 44

standardization 256 stereotype 196 strategic dependency model 77 strategic rationale model 79, 83 supervision 249 support artifact 19 system coniguration 90 system design speciication 48 system requirements speciication 48

T task 76 task dependency 77 Tropos 160 trust 22, 90, 160, 272

U UMLsec 196 uniied modelling language (UML) 3, 9, 95, 109, 169, 200, 220

V view-based access control 223 virus 27, 46 visual speciication language 234

W Web application server 108 Web server 198 Web services protocol 74 worm 27, 113

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Experience the latest full-text research in the fields of Information Science, Technology & Management

InfoSci-Online InfoSci-Online is available to libraries to help keep students, faculty and researchers up-to-date with the latest research in the ever-growing field of information science, technology, and management. The InfoSci-Online collection includes:
Scholarly and scientific book chapters
Peer-reviewed journal articles
Comprehensive teaching cases
Conference proceeding papers
All entries have abstracts and citation information
The full text of every entry is downloadable in .pdf format

InfoSci-Online features:
Easy-to-use
6,000+ full-text entries
Aggregated
Multi-user access

Some topics covered:
Business Management
Computer Science
Education Technologies
Electronic Commerce
Environmental IS
Healthcare Information Systems
Information Systems
Library Science
Multimedia Information Systems
Public Information Systems
Social Science and Technologies

“…The theoretical bent of many of the titles covered, and the ease of adding chapters to reading lists, makes it particularly good for institutions with strong information science curricula.” — Issues in Science and Technology Librarianship

To receive your free 30-day trial access subscription contact: Andrew Bundy Email: [email protected] • Phone: 717/533-8845 x29 Web Address: www.infosci-online.com

A PRODUCT OF Publishers of Idea Group Publishing, Information Science Publishing, CyberTech Publishing, and IRM Press

infosci-online.com

i ng c u d Int r o

IGI Teaching Case Collection The new IGI Teaching Case Collection is a full-text database containing hundreds of teaching cases related to the fields of information science, technology, and management.

Key Features • Project background • • • • •

• • • •

information Searches by keywords and categories Abstracts and citation information Full-text copies available for each case All cases are available in PDF format with instructor files Cases are written by IT educators, researchers, and professionals worldwide

View each case in full-text, PDF form. Hundreds of cases provide a real-world edge in information technology classes or research!

The Benefits of the IGI Teaching Case Collection Frequent updates as new cases are available Instant access to all full-text articles saves research time No longer necessary to purchase individual cases Password-protected case instructor files included in the database

For More Information Visit

www.igi-online.com Recommend to your librarian today! A Product Of