Computer Safety, Reliability and Security: 21st International Conference, SAFECOMP 2002, Catania, Italy, September 10-13, 2002. Proceedings

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen

2434

3

Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo

Stuart Anderson Sandro Bologna Massimo Felici (Eds.)

Computer Safety, Reliability and Security 21st International Conference, SAFECOMP 2002 Catania, Italy, September 10-13, 2002 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Stuart Anderson Massimo Felici The University of Edinburgh, LFCS, Division of Informatics Mayfield Road, Edinburgh EH9 3JZ, United Kingdom E-mail: {soa, mas}@dcs.ed.ac.uk Sandro Bologna ENEA CR Casaccia Via Anguillarese, 301, 00060 Rome, Italy E-mail: [email protected] Cataloging-in-Publication Data applied for Die Deutsche Bibliothek - CIP-Einheitsaufnahme Computer safety, reliability and security : 21th international conference ; proceedings / SAFECOMP 2002, Catania, Italy, September 10 - 13, 2002. Stuart Anderson ... (ed.). - Berlin ; Heidelberg ; New York ; Hong Kong ; London ; Milan ; Paris ; Tokyo : Springer, 2002 (Lecture notes in computer science ; Vol. 2434) ISBN 3-540-44157-3

CR Subject Classification (1998):D.1-4, E.4, C.3, F.3, K.6.5 ISSN 0302-9743 ISBN 3-540-44157-3 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag Berlin Heidelberg New York a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.de © Springer-Verlag Berlin Heidelberg 2002 Printed in Germany Typesetting: Camera-ready by author, data conversion by DA-TeX Gerd Blumenstein Printed on acid-free paper SPIN 10870130 06/3142 543210

Preface

Welcome to SAFECOMP 2002, held in Catania, Italy. Since its establishment SAFECOMP, the series of conferences on Computer Safety, Reliability, and Security, has contributed to the progress of the state of the art in dependable applications of computer systems. SAFECOMP provides ample opportunity to exchange insights and experiences in emerging methods and practical experience across the borders of different disciplines. Previous SAFECOMPs have already registered the need for multidisciplinarity in order better to understand dependability of computer-based systems in which human factors still remain a major criticality. SAFECOMP 2002 further addresses multidisciplinarity by collaborating and coordinating its annual activities with the Eleventh European Conference on Cognitive Ergonomics (ECCE-11). This year, SAFECOMP 2002 and ECCE-11 jointly organized an industry panel on Human-Computer System Dependability. The cross-fertilization among different scientific communities and industry supports the achievement of long-term results contributing to the integration of multidisciplinary experience in order to improve the design and deployment of dependable computer-based systems. SAFECOMP 2002 addressed the need to broaden the scope of disciplines contributing to dependability. The SAFECOMP 2002 program consisted of 27 refereed papers chosen from 69 submissions from all over the word. The review process was possible thanks to the valuable work of the International Program Committee and the external reviewers. SAFECOMP 2002 also included three invited keynote talks, which enhanced the technical and scientific merit of the conference. We would like to thank the International Program Committee, the organizing committee, the external reviewers, the keynote speakers, the panelists, and the authors for their work and support for SAFECOMP 2002. We would also like to thank the ECCE-11 people, who collaborated with us in organizing this week of events. We really enjoyed the work and we hope you appreciate the care that we put into organizing an enjoyable and fruitful conference. Finally, we will be glad to welcome you again to SAFECOMP 2003 in Edinburgh, Scotland.

July 2002

Sandro Bologna Stuart Anderson Massimo Felici

General Chair Sandro Bologna, I

Program Co-chairs Stuart Anderson, UK Massimo Felici, UK

EWICS TC7 Chair Udo Voges, D

International Program Committee Stuart Anderson, UK Liam J. Bannon, IRL Antonia Bertolino, I Helmut Bezecny, D Robin Bloomfield, UK Andrea Bondavalli, I Helmut Breitwieser, D Peter Daniel, UK Bas de Mol, NL Istvan Erenyi, HU Hans R. Fankhauser, S Massimo Felici, UK Robert Garnier, F Robert Genser, A Chris Goring, UK Janusz Gorski, PL Erwin Grosspietsch, D Michael Harrison, UK Maritta Heisel, D Erik Hollnagel, S Chris Johnson, UK

Mohamed Kaˆ aniche, F Karama Kanoun, F Floor Koornneef, NL Vic Maggioli, US Patrizia Marti, I Odd Nordland, NO Alberto Pasquini, I Gerd Rabe, D Felix Redmill, UK Antonio Rizzo, I Francesca Saglietti, D Erwin Schoitsch, A Meine van der Meulen, NL Udo Voges, D Marc Wilikens, I Rune Winther, NO Stefan Wittmann, D Eric Wong, US Janusz Zalewski, US Zdzislaw Zurakowski, P

Organizing Committee Stuart Anderson, UK Antonia Bertolino, I Domenico Cantone, I Massimo Felici, UK Eda Marchetti, I

Alberto Pasquini, I Elvinia Riccobene, I Mark-Alexander Sujan, D Lorenzo Vita, I

Organization

External Reviewers Claudia Betous Almeida, F Iain Bate, UK Giampaolo Bella, I Stefano Bistarelli, I Linda Brodo, I L. H. J. Goossens, NL Bjørn Axel Gran, NO Fabrizio Grandoni, I Silvano Chiaradonna, I Andrea Coccoli, I Felicita Di Giandomenico, I Juliana K¨ uster Filipe, UK

Marc-Olivier Killijian, F Frank Koob, D Martin Lange, UK Eckhard Liebscher, D Eda Marchetti, I Marc Mersiol, F Stefano Porcarelli, I Andrey A. Povyakalo, UK Thomas Santen, D Mark-Alexander Sujan, D Konstantinos Tourlas, UK

VII

VIII

Organization

Scientific Sponsor

in collaboration with the Scientific Co-sponsors AICA – Associazione Italiana per l’Informatica ed il Calcolo Automatico ARCS – Austrian Research Centers Seibersdorf Interdisciplinary Research Collaboration in Dependability of Computer-Based Systems EACE – European Association of Cognitive Ergonomics ENCRESS – European Network of Clubs for Reliability and Safety of Software GI – Gesellschaft f¨ ur Informatik

IFAC – International Federation of Automatic Control IFIP – WG10.4 on Dependable Computing and Fault Tolerance IFIP – WG13.5 on Human Error, Safety and System Development ISA-EUNET OCG – Austrian Computer Society SCSC – Safety-Critical Systems Club SRMC – Software Reliability & Metrics Club

Organization

SAFECOMP 2002 Organization

SAFECOMP 2002 Management Tool

IX

List of Contributors

K. Androutsopoulos Department of Computer Science King’s College London Strand, London WC2R 2LS United Kingdom

Sandro Bologna ENEA CR Casaccia Via Anguillarese, 301 00060 - Roma Italy

Christopher Bartlett BAE SYSTEMS United Kingdom

R.W. Born MBDA UK Ltd. Filton, Brstol, United Kingdom

Iain Bate Department of Computer Science University of York York YO10 5DD United Kingdom M. Benerecetti Dept. of Physics University of Naples ”Federico II” Napoli Italy Helmut Bezecny Dow Germany Peter G. Bishop Adelard and Centre for Software Reliability, City University Northampton Square London EC1V 0HB United Kingdom Robin Bloomfield Adelard and Centre for Software Reliability, City University Northampton Square London EC1V 0HB United Kingdom A. Bobbio DISTA Universit` a del Piemonte Orientale 15100 - Alessandria Italy

Jan Bredereke Universit¨ at Bremen FB 3 · P.O. box 330 440 D-28334 Bremen Germany Jos´e Carlos Campelo Departamento de Inform´ atica de Sistemas y Computadoras, Universidad Polit´ecnica de Valencia, 46022 - Valencia Spain Luping Chen Safety Systems Research Centre Department of Computer Science University of Bristol Bristol, BS8 1UB United Kingdom E. Ciancamerla ENEA CR Casaccia Via Anguillarese, 301 00060 - Roma Italy D. Clark Department of Computer Science King’s College London Strand, London WC2R 2LS United Kingdom

List of Contributors

XI

Tim Clement Adelard Drysdale Building Northampton Square London EC1V 0HB United Kingdom

Thomas Droste Institute of Computer Science, Dept. of Electrical Engineering and Information Sciences, Ruhr Univ. Bochum, 44801 Bochum Germany

Paulo S´ergio Cugnasca Escola Polit´ecnica da Universidade de S˜ ao Paulo, Dept of Computer Engineering and Digital Systems, CEP 05508-900 - S˜ ao Paulo Brazil

G. Franceschinis DISTA Universit` a del Piemonte Orientale 15100 - Alessandria Italy

Ferdinand J. Dafelmair ¨ S¨ TUV uddeutschland Westendstrasse 199 80686 M¨ unchen Germany Dino De Luca NOKIA Italia S.p.A. Stradale Vincenzo Lancia 57 95121 Catania Italy ´Italo Romani de Oliveira Escola Polit´ecnica da Universidade de S˜ ao Paulo, Dept of Computer Engineering and Digital Systems, CEP 05508-900 - S˜ ao Paulo Brazil S. D. Dhodapkar Reactor Control Division Bhabha Atomic Research Centre Mumbai 400085 India Theo Dimitrakos CLRC Rutherford Appleton Laboratory (RAL) Oxfordshire United Kingdom

Rune Fredriksen Institute For Energy Technology P.O. Box 173 1751 Halden Norway R. Gaeta Dipartimento di Informatica Universit` a di Torino 10150 - Torino Italy Bjørn Axel Gran Institute For Energy Technology P.O. Box 173 1751 Halden Norway M. Gribaudo Dip. di Informatica Universit` a di Torino 10149 - Torino Italy Sofia Guerra Adelard Drysdale Building Northampton Square London EC1V 0HB United Kingdom Mark Hartswood School of Informatics University of Edinburgh United Kingdom

XII

List of Contributors

Denis Hatebur ¨ TUViT GmbH System- und Softwarequalit¨ at Am Technologiepark 1, 45032 Essen Germany Klaus Heidtmann Departement of Computer Science Hamburg University Vogt-K¨ olln-Str. 30 D-22527 Hamburg Germany Monika Heiner Brandenburgische Technische Universit¨ at Cottbus Institut f¨ ur Informatik 03013 Cottbus Germany Maritta Heisel Institut f¨ ur Praktische Informatik und Medieninformatik Technische Universit¨ at Ilmenau 98693 Ilmenau Germany Bernhard Hering Siemens I&S ITS IEC OS D-81359 M¨ unchen Germany Erik Hollnagel CSELAB, Department of Computer and Information Science University of Link¨ oping Sweden A. Horv´ ath Dept. of Telecommunications Univ. of Technology and Economics Budapest Hungary

Gordon Hughes Safety Systems Research Centre Department of Computer Science University of Bristol Bristol, BS8 1UB United Kingdom Jef Jacobs Philips Semiconductors, Bld WAY-1, Prof. Holstlaan 4 5656 AA Eindhoven The Netherlands Tim Kelly Department of Computer Science University of York York YO10 5DD United Kingdom Tai-Yun Kim Department of Computer Science & Engineering, Korea University Anam-dong Seungbuk-gu Seoul Korea John C. Knight Department of Computer Science University of Virginia, 151, Engineer’s Way, P.O. Box 400740 Charlottesville, VA22904-4740 USA Monica Kristiansen Institute For Energy Technology P.O. Box 173 1751 Halden Norway Axel Lankenau Universit¨ at Bremen FB 3 · P.O. box 330 440 D-28334 Bremen Germany K. Lano Department of Computer Science King’s College London Strand, London WC2R 2LS United Kingdom

List of Contributors

XIII

Bev Littlewood Centre for Software Reliability City University, Northampton Square, London EC1V 0HB United Kingdom

Yiannis Papadopoulos Department of Computer Science University of Hull Hull, HU6 7RX United Kingdom

John May Safety Systems Research Centre Department of Computer Science University of Bristol Bristol, BS8 1UB United Kingdom

Bernard Pavard GRIC – IRIT Paul Sabatier University Toulouse France

M. Minichino ENEA CR Casaccia Via Anguillarese, 301 00060 - Roma Italy Ali Moeini University of Tehran n. 286, Keshavarz Blvd 14166 – Tehran Iran MahdiReza Mohajerani University of Tehran n. 286, Keshavarz Blvd 14166 – Tehran Iran Tom Arthur Opperud Telenor Communications AS R&D Fornebu Norway Frank Ortmeier Lehrstuhl f¨ ur Softwaretechnik und Programmiersprachen Universit¨ at Augsburg D-86135 Augsburg Germany M. Panti Istituto di Informatica University of Ancona Ancona Italy

S.E. Paynter MBDA UK Ltd. Filton, Brstol, United Kingdom Peter Popov Centre for Software Reliability City University Northampton Square, London United Kingdom L. Portinale DISTA Universit` a del Piemonte Orientale 15100 - Alessandria Italy Rob Procter School of Informatics University of Edinburgh United Kingdom S. Ramesh Centre for Formal Design and Verification of Software IIT Bombay, Mumbai 400076 India Wolfgang Reif Lehrstuhl f¨ ur Softwaretechnik und Programmiersprachen Universit¨ at Augsburg D-86135 Augsburg Germany

XIV

List of Contributors

Yoon-Jung Rhee Department of Computer Science & Engineering, Korea University Anam-dong Seungbuk-gu Seoul Korea Francisco Rodr´ıguez Departamento de Inform´ atica de Sistemas y Computadoras, Universidad Polit´ecnica de Valencia, 46022 - Valencia Spain Thomas Rottke ¨ TUViT GmbH System- und Softwarequalit¨ at Am Technologiepark 1, 45032 Essen Germany Mark Rouncefield Department of Computing University of Lancaster United Kingdom Job Rutgers Philips Design The Netherlands Titos Saridakis NOKIA Research Center PO Box 407 FIN-00045 Finland Gerhard Schellhorn Lehrstuhl f¨ ur Softwaretechnik und Programmiersprachen Universit¨ at Augsburg D-86135 Augsburg Germany Juan Jos´e Serrano Departamento de Inform´ atica de Sistemas y Computadoras, Universidad Polit´ecnica de Valencia, 46022 - Valencia Spain

Andrea Servida European Commission DG Information Society C-4 B1049 Brussels Belgium Babita Sharma Reactor Control Division Bhabha Atomic Research Centre Mumbai 400085 India Roger Slack School of Informatics University of Edinburgh United Kingdom L. Spalazzi Istituto di Informatica University of Ancona Ancona Italy Ketil Stølen Sintef Telecom and Informatics, Oslo Norway S.Tacconi Istituto di Informatica University of Ancona Ancona Italy Andreas Thums Lehrstuhl f¨ ur Softwaretechnik und Programmiersprachen Universit¨ at Augsburg D-86135 Augsburg Germany Helmut Trappschuh Siemens I&S ITS IEC OS D-81359 M¨ unchen Germany

List of Contributors

Jos Trienekens Frits Philips Institute Eindhoven University of Technology Den Dolech 2 5600 MB Eindhoven The Netherlands E. Tronci Dip. di Informatica Universit` a di Roma ”La Sapienza” 00198 - Roma Italy Alexander Voß School of Informatics University of Edinburgh United Kingdom

XV

Robin Williams Research Centre for Social Sciences University of Edinburgh United Kingdom Wenhui Zhang Laboratory of Computer Science Institute of Software Chinese Academy of Sciences P.O.Box 8718, 100080 Beijing China

Table of Contents

Human-Computer System Dependability (Joint ECCE-11 & SAFECOMP 2002) Human-Computer System Dependability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Panel moderators: Sandro Bologna and Erik Hollnagel Dependability of Joint Human-Computer Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Erik Hollnagel

Keynote Talk Dependability in the Information Society: Getting Ready for the FP6 . . . . . . 10 Andrea Servida

Human Factors A Rigorous View of Mode Confusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Jan Bredereke and Axel Lankenau Dependability as Ordinary Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Alexander Voß, Roger Slack, Rob Procter, Robin Williams, Mark Hartswood, and Mark Rouncefield

Security Practical Solutions to Key Recovery Based on PKI in IP Security . . . . . . . . . . 44 Yoon-Jung Rhee and Tai-Yun Kim Redundant Data Acquisition in a Distributed Security Compound . . . . . . . . . .53 Thomas Droste Survivability Strategy for a Security Critical Process . . . . . . . . . . . . . . . . . . . . . . . 61 Ferdinand J. Dafelmair

Dependability Assessment (Poster Session) Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms for Reliability and Safety Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Klaus Heidtmann

XVIII Table of Contents

Safety and Security Analysis of Object-Oriented Models . . . . . . . . . . . . . . . . . . . .82 Kevin Lano, David Clark, and Kelly Androutsopoulos The CORAS Framework for a Model-Based Risk Management Process . . . . . 94 Rune Fredriksen, Monica Kristiansen, Bjørn Axel Gran, Ketil Stølen, Tom Arthur Opperud, and Theo Dimitrakos

Keynote Talk Software Challenges in Aviation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 John C. Knight

Application of Formal Methods (Poster Session) A Strategy for Improving the Efficiency of Procedure Verification . . . . . . . . . 113 Wenhui Zhang Verification of the SSL/TLS Protocol Using a Model Checkable Logic of Belief and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Massimo Benerecetti, Maurizio Panti, Luca Spalazzi, and Simone Tacconi Reliability Assessment of Legacy Safety-Critical Systems Upgraded with Off-the-Shelf Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Peter Popov

Reliability Assessment Assessment of the Benefit of Redundant Systems . . . . . . . . . . . . . . . . . . . . . . . . . .151 Luping Chen, John May, and Gordon Hughes Estimating Residual Faults from Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Peter G. Bishop

Design for Dependability Towards a Metrics Based Verification and Validation Maturity Model . . . . . 175 Jef Jacobs and Jos Trienekens Analysing the Safety of a Software Development Process . . . . . . . . . . . . . . . . . . 186 Stephen E. Paynter and Bob W. Born Software Criticality Analysis of COTS/SOUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Peter Bishop, Robin Bloomfield, Tim Clement, and Sofia Guerra

Table of Contents

XIX

Safety Assessment Methods of Increasing Modelling Power for Safety Analysis, Applied to a Turbine Digital Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212 Andrea Bobbio, Ester Ciancamerla, Giuliana Franceschinis, Rossano Gaeta, Michele Minichino, and Luigi Portinale Checking Safe Trajectories of Aircraft Using Hybrid Automata . . . . . . . . . . . . 224 ´ Italo Romani de Oliveira and Paulo S´ergio Cugnasca Model-Based On-Line Monitoring Using a State Sensitive Fault Propagation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Yiannis Papadopoulos

Keynote Talk On Diversity, and the Elusiveness of Independence . . . . . . . . . . . . . . . . . . . . . . . . 249 Bev Littlewood

Design for Dependability (Poster Session) An Approach to a New Network Security Architecture for Academic Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 MahdiReza Mohajerani and Ali Moeini A Watchdog Processor Architecture with Minimal Performance Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Francisco Rodr´ıguez, Jos´e Carlos Campelo, and Juan Jos´e Serrano

Application of Formal Methods Model-Checking Based on Fluid Petri Nets for the Temperature Control System of the ICARO Co-generative Plant . . .273 M. Gribaudo, A. Horv´ ath, A. Bobbio, E. Tronci, E. Ciancamerla, and M. Minichino Assertion Checking Environment (ACE) for Formal Verification of C Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 B. Sharma, S. D. Dhodapkar, and S. Ramesh Safety Analysis of the Height Control System for the Elbtunnel . . . . . . . . . . . 296 Frank Ortmeier, Gerhard Schellhorn, Andreas Thums, Wolfgang Reif, Bernhard Hering, and Helmut Trappschuh

XX

Table of Contents

Design for Dependability Dependability and Configurability: Partners or Competitors in Pervasive Computing? . . . . . . . . . . . . . . . . . . . . . . . . 309 Titos Saridakis Architectural Considerations in the Certification of Modular Systems . . . . . 321 Iain Bate and Tim Kelly A Problem-Oriented Approach to Common Criteria Certification . . . . . . . . . .334 Thomas Rottke, Denis Hatebur, Maritta Heisel, and Monika Heiner Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347

Human-Computer System Dependability Panel moderators: Sandro Bologna and Erik Hollnagel Panellists: Christopher Bartlett, Helmut Bezecny, Bjørn Axel Gran, Dino De Luca, Bernard Pavard and Job Rutgers

Abstract. The intention of this cross-conference session is to bring together specialists of cognitive technologies and ergonomics, with software developers, dependability specialists and, especially, endusers. The objective of the session is to provide a forum for the sharing of practical experiences and research results related to safety and dependability of human-computer systems.

1

Rationale

While a computing device from an isolated perspective is a technological artefact pure and simple, practice has taught us that humans always are involved at some time and in some way. Humans play a role as developers, designers, and programmers of systems. They may be end-users, or they may be the people who service, maintain, repair, and update the systems. Unless we restrict our perspective to a narrow slice of a system’s life cycle, the central issue must be the dependability of human-computer systems. This issue cannot be reduced to a question of fallible humans affecting perfect computers. Indeed, we cannot consider the functioning of a computer without at the same time consider the functioning of humans. In that sense the issue is not one of either-or, but of both – of human-and-computer seen as a single system. The problem of dependability therefore cannot be reduced to the dependability of one part or the other, but must address the system as a whole. This requires a close collaboration of people with different kinds of expertise and a realisation that no single discipline can provide the whole answer. It is in that spirit that cognitive ergonomics community and the safety & reliability community meet in this session – and hopefully will continue to meet afterwards.

2

Position Statements

Christopher Bartlett is Chief Technologist in the Capability Management Group, Bae Systems, UK. Abbreviated position statement: A major reason for retaining the man-in-the-loop is that we do not have totally integrated systems yet. Pilots still have a task to analyse what else is happening within and without the cockpit and it is this integration S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 1-3, 2002.  Springer-Verlag Berlin Heidelberg 2002

2

Sandro Bologna and Erik Hollnagel

attribute to which all their training is directed. We simply do not have sensors with sufficient resolution nor decision-making algorithms as powerful as the human brain. We may achieve such system integration eventually but the larger and more complex the system the more difficult it is to grasp the potential failure modes when we try to formalise it. Until then the best we can do is to recognise both human fallibility alongside our ability to make innovative decisions and to make our systems robust enough to cope. Helmut Bezecny is “Global Process Automation Safety Technology Leader” with Dow Chemical in Stade, Germany. Abbreviated position statement: Human-computer issues are created by the divers capabilities of both, if misapplied. Human can prevent hazardous situations from turning into accidents by identifying and classifying safety relevant information that cannot be measured and engaging in activities that have not been planned but would help in the specific scenario. The strategy for human-computer systems should be to combine the best of both - let the computer do whatever can be automated and the human interact intelligently, creative and with low stress. Bjørn Axel Gran is member of the section on software verification and validation, at the OECD Halden Reactor Project, Norway. Abbreviated position statement: In the operation of complex systems such as nuclear power plants, aircraft, etc., humans and advanced technology interact within a dynamic environment. The dependability of such systems requires that the interplay between humans and technology be addressed for every lifecycle phase of the system. This creates a need for research to formulating new methodologies that ensure a common and uniform platform for the experts from different fields. Dino De Luca is Chief Solution Engineer and Team Leader for MAG (Middleware & Applications Group) in the South Europe hub of Nokia. Abbreviated position statement: Although the possibility to pay interacting with a mobile terminal opens new and interesting scenarios, it is very important that the customer and the service are able to fully trust each other, including all the communication services in-between. Firstly, mutual authentication, privacy and integrity of the communication must be provided for both parties. Secondly, in addition to the secured communications pipe, a higher level of assurance can be achieved by applying digital signatures to a business transaction. The proposed solution is to have the customer’s mobile phone act as a Personal Trusted Device (PTD). Bernard Pavard is professor at the Cognitive Engineering Research Group (GRIC – IRIT) at the Paul Sabatier University, Toulouse, France. Abbreviated position statement: I want to consider how can we design dependability into complex work settings. The paradox of dependability is that the more complex the situation, the more it is necessary to involve humans decisions, immersive and invisible technologies and the less it is possible to carry out traditional safety &

Human-Computer System Dependability

3

reliability analysis. Designers need to tackle non-deterministic processes and answer questions such as: how can controlled (deterministic) processes and distributed noncontrollable interactions be managed optimally to improve the robustness of a system, and how can the risks of such a system be assessed? Job Rutgers is member of the Strategic Design Team at Philips Design in the Netherlands. Abbreviated position statement: Designers engage in the development process by means of scenario’s, such as visual and textual descriptions of how future products and services will enable users to overcome certain problems or will address certain needs. Often, these scenarios are characterized by a simple narration but lack a realistic modelling of everyday life activities into ‘real stories’. To achieve this, we need both to integrate better the complex information collected by social scientist, but also make use of a wider vocabulary of story telling than ‘happy ending’ mainstream Hollywood offers. The detailed modelling of users’ everyday life activities need to result in ‘real life’ scenarios that incorporate a fuller and richer blend of people’s behaviour.

Dependability of Joint Human-Computer Systems Erik Hollnagel CSELAB, Department of Computer and Information Science University of Linköping, Sweden [email protected]

Abstract. Human-computer systems have traditionally been analysed and described in terms of their components – humans and computers – plus the interaction. Several contemporary schools of thought point out that decomposed descriptions are insufficient, and that a description on the level of the system as a whole is needed instead. The dependability of human-computer systems must therefore refer to the performance characteristics of the joint system, and specifically the variability of human performance, not just as stochastic variations but also as purposeful local optimisation.

1

Introduction

In any situation where humans use artefacts to accomplish something, the dependability of the artefact is essential. Quite simply, if we cannot rely or depend on the artefact, we cannot really use it. This goes for simple mechanical artefacts (a hammer, a bicycle), as well as complex technological artefacts (ranging from cars to large-scale industrial production systems), and sociotechnical artefacts (distribution systems, service organisations). In order for an artefact – or more generally, a system – to be dependable it is a necessary but not sufficient condition that the parts and subsystems are dependable. In addition, the interaction between the parts must also be dependable. In pure technological systems this does not constitute a serious problem, because the interaction between the parts usually is designed together with the parts. Take, for instance, an automobile engine. This consists of hundreds (or even thousands?) of parts, which are engineered to a high degree of precision. The same precision is achieved in specifying how the parts work together, either in a purely mechanical fashion or as in a modern car engine with extensive use of software. Compared to the engine in a Ford T, a modern car engine is a miracle of precision and dependability, as are indeed most other technological systems. Since the dependability of a system depends on the parts and their interaction, it makes sense that the design tries to cover both. While this can be achieved for technological systems which function independently of users, the situation is radically different for systems where humans and technology have to work together, i.e., where some of the parts are hardware – or hardware + software – and others are humans. I shall refer to the latter as joint systems, for instance joint human-computer systems or S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 4-9, 2002.  Springer-Verlag Berlin Heidelberg 2002

Dependability of Joint Human-Computer Systems

5

joint cognitive systems (Woods, 1986). Although an artefact may often be seen as representing technology pure and simple, practice has taught us that humans always are involved at some time and in some way. Humans play a role as developers, designers, and programmers of systems. They may be end-users, or they may be the people who service, maintain, repair, and update the systems. Since the dependability cannot be isolated to a point in time, but always must consider what went before (the system’s history), it follows that the issue of system dependability always is an issue of human-system dependability as well. The crucial difference between pure and joint systems is that humans cannot be designed and engineered in the manner of technological components, and furthermore that the interaction cannot be specified in a rigorous manner. This is certainly not because of a lack of trying, as shown by the plethora of procedures and rules that are a part of many systems. There also appears to be a clear relation between the level of risk in a situation and the pressure to follow procedures strictly, where space missions and the military provide extreme examples. Less severe, but still with an appreciable risk, are complex public systems for commerce, communication and transportation, where aviation and ATM are good examples. At the other end of the scale are consumers trying to make use of various devices with more or less conspicuous computing capabilities, such as IT artefacts and everyday machines (household devices, kiosks, ATMs, ticket machines, etc). Although the risks here may be less, the need of dependability is still very tangible, for instance for commercial reasons. It is therefore necessary seriously to consider the issue of dependability of joint humancomputer systems at all levels and especially to pay attention to the dependability of the interaction between humans and machines.

2

Human Reliability

One issue that quickly crops up in this endeavour is that of human reliability, and its not too distant cousin “human error”. Much has been written on these topics, particularly in the aftermath of major accidents (nuclear, aviation, trains, trading, etc). In the 1970-80s it was comme il faut to consider humans as being unreliable and error prone by themselves, i.e., considered as systems in isolation. This leads to several models of “human error” and human reliability, and to the concept of an inherent human error probability (Leplat & Rasmussen, 1987; Miller & Swain, 1987; Reason, 1990). From the 1990s and onwards this view has been replaced by the realisation that human performance and reliability depends on the context as much as on any psychological predispositions (Amalberti, 1996; Hollnagel, 1998). The context includes the working conditions, the current situation, resources and demands, the social climate, the organisational safety culture, etc. Altogether this has been expressed by introducing a distinction between sharp-end and blunt-end factors, where the former are factors at the local workplace and the latter are factors removed in space and time that create the overall conditions for work (Reason, 1997; Woods et al., 1994). The importance of the sharp-end, blunt-end framework of thinking is that system dependability – or rather, the lack thereof – is not seen as a localised phenomenon which can be explained in terms of specific or unique conditions, but rather as

6

Erik Hollnagel

something which is part and parcel of the system throughout its entire existence. Human-computer dependability therefore cannot be reduced to a question of human reliability and “human error”, but requires an appreciation of the overall conditions that govern how a system functions.

3

Automation

One of the leading approaches to automation has been to use it as a way of compensating for insufficient human performance. The insufficiency can be in terms of speed, precision, accuracy, endurance, or – last but not least – reliability and “error”. Automation has been introduced either to compensate for or support inadequate human performance or outright to replace humans in specific functions. From a more formal point of view, automation can be seen as serving in one of the following roles (Hollnagel, 1999): • Amplification, in the sense that the ability to perform a function is being improved. If done inappropriately, this may easily led to a substitution of functions. • Delegation, in which a function is transferred to the automation under the control of the user (Billings (1991; Sheridan, 1992). • Substitution or replacement. Here the person not only delegates the function to the automation but completely relinquishes control. • Extension, where new functionality is being added. Pure cases of extension are, however, hard to find. In relation to the dependability of joint human-computer systems, automation can be seen as an attempt to improve the interaction by replacing the human with technology, hence taking a specific slice of the interaction away from the human. Despite the often honourable intentions, the negative effects of automation across all industrial domains have, on the whole, been larger than the positive ones. Among the welldocumented negative effects are that workload is not reduced but only shifted to other parts of the task, that “human errors” are displaced but not eliminated, that problems of safety and reliability remain and that the need for human involvement is not reduced, and that users are forced into a more passive role and therefore are less able to intervene when automation fails. The shortcomings of automation have been pointed out by many authors (e.g. Moray et al., 2000; Wiener & Curry, 1980) and have been elegantly formulated as the Ironies of Automation (Bainbridge, 1983). From a joint systems perspective, the main problem with automation is that it changes existing working practices. After a system has been in use for some time, a stable condition emerges as people learn how to accomplish their work with an acceptable level of efficiency and safety. When a change is made to a system – and automation certainly qualifies as one – the existing stable condition is disrupted. After a while a new stable condition emerges, but this may be so different from the previous one that the premises for the automation no longer exist. In other words, by making a change to the system, some of the rationale for the change may have become obsolete. Solutions that were introduced to increase

Dependability of Joint Human-Computer Systems

7

system dependability may therefore have unsuspected side-effects, and perhaps not even lead to any improvement at all.

4

Local Optimisation – Efficiency-Thoroughness Trade-Off

In designing complex human-machine systems – as in transportation, process control, and e-commerce – the aim is to achieve a high degree of efficiency and reliability so that we can depend on the system’s functioning. In practice all human-machine systems are subject to demands that require a trade-off between efficiency and thoroughness on the part of the users and a dependable joint system is one that has developed a safe trade-off. In other words, the people who are part of the system at either the sharp or the blunt end have learned which corners to cut and by how much. The trade-off of thoroughness for efficiency is, however, only viable as long as the conditions conform to the criteria implied by the trade-off. Sooner or later a situation will occur when this is not the case – if for no other reason then because the environment is made up of other joint systems that work according to the same principles. It will be impossible to make significant improvements to system dependability if we do not acknowledge the reality of system performance, i.e., that there must be an efficiency-thoroughness trade-off. The basis for design is inevitably a more or less well-defined set of assumptions about the people who are going to use the system – as operators, end-users, maintenance staff, etc. If, for the sake of the argument, we only consider the end-users the design usually envisions some kind of exemplary end-user. By this I mean a user who has the required psychological and cognitive capacity, who is motivated to make use of the system, who is alert and attentive, who is “rational” in the sense that s/he responds the way the designer imagined, and who knows how the system works and is able to interpret outputs appropriately. While such end-users certainly may exist, the population of users will show a tremendous variety in every imaginable – and unimaginable – way (Marsden & Hollnagel, 1996). Apart from differences in knowledge and skills, there will also be differences in needs (reasons for using the system), in the context or working conditions, in demands, in resources, etc. If system design only considers the exemplary user, the result is unlikely to be a dependable joint system. In order for that to come about, it is necessary that designers (programmers, etc.) take into account how things may go wrong and devise ways in which such situations may be detected and mitigated. System designers and programmers are, however, subject to the same conditions as end-users, i.e. a diversity of needs and working conditions. They are therefore prone to use the same bag of tricks to bring about a local optimum, i.e., to trade off thoroughness for efficiency in order to achieve a result that they consider to be sufficiently safe and effective. This means that the dependability of a joint system must be considered from beginning to end of the system’s life cycle. The formal methods that are used for requirement specification and programming are themselves artefacts being used by humans, and therefore subject to the same problems as the final systems. Thus, the diligence by which we scrutinise the dependability of the system-in-use should also be directed at the system as it is being built.

8

Erik Hollnagel

Diversity of needs

Diversity of needs

Diversity of contexts

Population of users Artefact Artefact ++ interaction interaction (HW+SW) (HW+SW)

System designer

Exemplary user

Requirements, tools, technology, …

Diversity of contexts

Fig. 1. User types and design diversity

5

Conclusions

In this presentation I have tried to argue that the issue of joint human-computer dependability cannot be reduced to a question of fallible humans corrupting otherwise perfect computing artefacts. Indeed, we cannot consider the functioning of a computing system without at the same time consider the functioning of humans. In that sense the issue is not one of either-or, but of both – of human-and-computer seen as a single system. Although there is no easy way to solve the problems we see all around, one solution would be to build systems that are resilient in the sense that they are able to detect variations in overall performance and compensate for them at an early stage, either by a direct compensation-recovery capability or by defaulting to a safe state. To do this there is a need for better methods to analyse and assess the dependability of joint human-machine systems. The bottom line is that the problem of dependability cannot be reduced to the dependability of one part or the other, but must address the joint system. This requires a close collaboration of people with different kinds of expertise and a realisation that no single discipline can provide the whole answer. It is in that spirit that cognitive ergonomics community and the safety & reliability community meet in this session – and hopefully will continue to meet afterwards.

References 1. 2.

Amalberti, R. (1996). La conduite des systèmes à risques, Paris: PUF. Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775-779.

Dependability of Joint Human-Computer Systems

3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

9

Billings, C. E. (1991). Human-centered aircraft automation: A concept and guidelines (NASA Technical Memorandum 103885). Moffett Field, CA: NASA Ames Research Center. Hollnagel, E. (1998). Cognitive reliability and error analysis method – CREAM. Oxford: Elsevier Science. Hollnagel, E. (1999). From function allocation to function congruence. In S. Dekker & E. Hollnagel (Eds.), Coping with computers in the cockpit. Aldershot, UK: Ashgate. Leplat, J. & Rasmussen, J. (1987). Analysis of human errors in industrial incidents and accidents for improvement of work safety. In J. Rasmussen, K. Duncan & J. Leplat (Eds.), New technology and human error. London: Wiley. Marsden, P. & Hollnagel, E. Human interaction with technology: The accidental user. Acta Psychologica, 91, 345-358. Miller, D. P. & Swain, A. D. (1987). Human Error and Human Reliability. In G. Salvendy (Ed.) Handbook of Human factors. New York: Wiley. Moray, N., Inagaki, T. & Itoh, M. (2000). Adaptive automation, trust, and selfconfidence in fault management of time-critical tasks. Journal of Experimental Psychology: Applied, 6(1), 44-58. Reason, J. T. (1990). Human error. Cambridge, U.K.: Cambridge University Press. Reason, J. T. (1997). Managing the risks of organizational accidents. Aldershot, UK: Ashgate. Sheridan, T. B. (1992). Telerobotics, automation, and human supervisory control. Cambridge, MA: M. I. T Press. Wiener, E. L. & Curry, R. E. (1980). Flight deck automation: Promises and problems. Ergonomics, 23(10), pp. 995-1011. Woods, D. D. (1986). Cognitive technologies: The design of joint humanmachine systems. The AI Magazine, 6(4), 86-92. Woods, D. D., Johannesen, L. J., Cook, R. I. & Sarter, N. B. (1994). Behind human error: Cognitive systems, computers and hindsight. Columbus, Ohio: CSERIAC.

Dependability in the Information Society: Getting Ready for the FP6 Andrea Servida European Commission, DG Information Society C-4 B1049 Brussels, Belgium [email protected] http://deppy.jrc.it/

Abstract. The dependable behaviour of information infrastructures is critical to achieve trust & confidence in any meaningful realisations of the Information Society. The paper briefly discusses the aim and scope of the Dependability Initiative under the Information Society Technologies Programme and presents the activities that have recently being launched in this area to prepare the forthcoming Framework Programme 6 th of the European Commission.

1 Introduction The Information Society is increasingly dependent on largely distributed systems and infrastructures for life-critical and business-critical functions. The complexity of systems in Information Society is rapidly increasing because of a number of factors like the size, unboundness and interdependency as well as the multiplicity of actors involved, the need to pursue more decentralised control and growing sophistication in functionality. This trend together with the increasing use of open information infrastructures for communications, freeware software and common application platforms expose our society to new vulnerabilities and threats that would need better understanding, assessment and control. The dependable and predictable behaviour of information infrastructures provides the basis for Trust & Confidence (T&C) in any meaningful realisations of the global Information Society and, in particular, in Electronic Commerce. However, the expectation and perception of T&C are dramatically changing under the pressures new business, technological and societal drivers among which are:
the deregulation in telecommunications, which has led to the emergence of new players, actors and intermediaries inter-playing in new added value chains, multi-national consortiums, services and applications but also to the blurring of sector and jurisdictional boundaries;

1

Disclaimer: The content of this paper is the sole responsibility of the author and in no way represents the view of the European Commission or its services

S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 10-18, 2002. c Springer-Verlag Berlin Heidelberg 2002

Dependability in the Information Society: Getting Ready for the FP6

11




the convergence of communications and media infrastructures together with the interoperability of systems and services, which has boosted the deployment of unbounded network computing and communication environments;
the realisation of information as an asset, which has facilitated the transition of companies from a manufacturing-centred to an information/knowledge management centred model with quality met production at the lowest point of global cost;
the globalisation of services, markets, reach-ability of consumers and companies with virtual integration of business processes;
the emergence of new threats and vulnerabilities, which are mostly connected with the increased openness and reach-ability of the infrastructures;
the realisation by a number of nations that ‘information superiority’ brings strategic gains;
the increased sophistication and complexity of individual systems;
the changes in the traditional chain of trust which is affected by blurring of geographic border and boundaries. The European Dependability Initiative, called in short DEPPY [1], is a major R&D initiative under the Information Society Technologies Programme [2] to develop technologies, systems and capability to tackle the emerging dependability challenges in the Information Society. The experience gained in DEPPY has shown that to attain these new challenges objectives there is a need to foster the integration of research efforts and resources coming from a number of areas such as security, fault tolerance, reliability, safety, survivability but network engineering, psychology, human factor, econometrics, etc. In the following we would present how DEPPY has developed and discussed the new dependability challenges which could be tackled in the forthcoming 6th Framework Programme [3] of the European Commission (called in short FP6).

2 The European Dependability Initiative DEPPY was launched 1997/1998 as an initiative of the IST Programme with the primary objective of addressing dependability requirements in tightly connected systems and services, which are at the basis of the Information Society. The mission statement for the DEPPY was: “to contribute towards raising and assuring trust and confidence in systems and services, by promoting dependability enabling technologies”. This mission statement embraces the main goals, precisely:
fostering the development of new dependability technologies, and
using better the available dependability technologies.

12

Andrea Servida

2.1 The DEPPY Objectives Five key objectives were identified as qualifying the success of DEPPY, precisely:
fostering a dependability-aware culture, which would include promoting innovative approaches to dependability, disseminating industrial best pra ctice and training to promote the ability to work in multi-disciplinary teams;
providing a workable characterisation of affordable dependability, which would support the integration and layering of services, the assurance of quality of intangible assets and the certification of both new distributed architectures and massively deployed embedded systems;
facilitating global interoperable trust frameworks, that would also consider mediation and negotiation along chains of trust, dependable business process integration and guidance on issues of liability that might arise from system failures in large-scale distributed and embedded settings and;
mastering heterogeneous technical environments, including the integr ation of COTS and legacy systems software into Internet based applications, rapid recovery strategies and mechanisms to preserve essential services and business continuity, systems composability, dependability assurance and verification in dynamic environments;
managing dependability and risk in largely distributed and open systems-of-systems environments, including dependability assurance and ver ification, united frameworks for modelling and validation, flexible business driven models of dependability. In the following, we will briefly discuss the main element of the DEPPY research agenda as it developed through the years.

2.2 The DEPPY Research Agenda The DEPPY research agenda was determined on an early basis in line with the overall approach taken to define the Workprogramme for the IST Programme in which DEPPY was present as a Cross-Programme Action [4]. In 1999, the research agenda for DEPPY focussed on dependability in services and technologies and, in partic ular on:
technologies, methods and tools to meet the emerging dependability requirements stemming from the ubiquity and volume of embedded and networked systems and services,
the global and complex nature of large-scale information and communication infrastructures,
risk and incident management tools as well as on privacy enhancing tec hnologies,
self-monitoring, self-healing infrastructures and services.

Dependability in the Information Society: Getting Ready for the FP6

13

Seven R&D projects were funded covering technical areas like intrusion tolerance paradigm in largely distributed systems, the dependable composition of systems-ofsystems and advance tools for embedded system design. In 2000, the technical focus was on promoting research and industrially oriented projects in areas like:
large scale vulnerabilities in multi-jurisdictional and unbounded systems;
information assurance;
survivable systems relying on self organising and self-diagnostic capabilities;
dependability of extensively deployed and tightly networked embedded systems;
risk management of largely distributed and open systems-of-systems;
methods for workable characterisation of affordable dependability. Beside these technical objectives, we also tried to stimulate the international collaboration in particular with the US. Six projects were funded on areas like depen dability benchmarks for COTS, security of global communication networks, methods and tools for assuring dependability and, last but not least, management and control systems for electrical supply and for telecommunications networks. The objectives set for the year 2001, which were logically built on the work of the previous years, were also closely related to the action on dependability of information infrastructures which was part of the “Secure networks and smart cards” objective of the eEurope 2002 Action Plan [3]. Such an action aimed to “stimulate public/private co-operation on dependability of information infrastructures (including the development of early warning systems) and improve co-operation amongst national 'computer emergency response teams'”. In this respect, the technical objectives for 2001 focussed on developing:
innovative and multidisciplinary approaches, methods and technologies to build and manage dependability properties of large-scale infrastructures composed of tightly networked embedded systems.
methods and technologies to model and manage dependability and survivability of globally interdependent systems and highly interconnected critical infrastructures.
technologies to measure, verify and monitor dependability properties and behaviours of large-scale unbounded systems. Of the three projects funded one, called Dependability Development Support Initiative [6] contributes to raise awareness that making the information infrastructure dependable would mean protecting our industry wealth and investments in inform ation and communication technologies as well as in other intangible assets.

3 The Future: Towards FP6 The experience gained with DEPPY shows that we just start to understand what is the scope of the technological, economic and social implications and challenges connected with the increasing reliance of our economy and society on digital communication networks and systems. Such a reliance is developed through an unprec e-

14

Andrea Servida

dented scale of integration and interconnectedness of highly heterogeneous systems that are, individually and collectively, “emergent”, that is, the result of the casual or intentional composition of smaller and more homogeneous components. These aspects are critical in the area networked embedded systems and components where the large volume of deployed networked devices bring to the surface novel and unique system challenges. Lastly, this scenario is made even more complex by the large variety of patterns of use, user profiles and deployment environments. In the following, are some of the issues that we believe may characterise the context for future activities on dependability:
In the area of open information infrastructure and unbounded networks there is a growing demand for "working and affordable dependability" which leads to the need to holistically address issues of safety, security, availability survivability, etc. This could only be accomplished by both stimulating innovative multidisciplinary approaches as well as facilitating the convergence of diverse scientific cultures and technical communities.
In the network security arena there is a clear shift from "resist to attack" to “survive and adapt”. The target of "absolute security & zero risk" is unfeasible in domains where openness and interconnectivity are vital elements for successful operations. In this respect, the notion of "adaptable environment" (which would have a level of “self awareness”), within which security performance, quality of services and risks should be managed, is becoming the key element of any operational strategy.
There is no language to describe dependability of unbounded systems and infrastructures, nor there are global dependability standards. Hence, novel mult idimensional models (which also cover behaviour, composition, physical elements, thermal properties, etc.) and approaches should be developed.
In the area of survivability and dependability, the R&D often drives the Policy activity, but Policy must also drive R&D. There is a need to ensure dependability of critical infrastructures across Nations. In this respect, the meaning of "critical" varies because of Trans-national dependencies. A common knowledge base for this purpose does not exist. Pooling R&D resources across nations can build such knowledge.
We are just at the beginning of distributed computing and the pace of its change is dramatic. Very monolithic platforms would disappear to be replaced by new computing platforms/fabric whose impact on dependability is to be ascertained.
The next dependability challenge would be related to networks bandwidth and latency.
It is anticipated that both the global and the local (intimately related to emerging short-scale interaction/communication means and capability) dime nsions and aspects of cyberspace deserve a fundamental paradigm shift in conceiving and realising a globally (including the time dimension) trustworthy and secure Information Society.

Dependability in the Information Society: Getting Ready for the FP6









15

Software is still the big problem. Achieving the automated (similarly to what is an automated banking process) production and evolution of software seems to be the good target, but we are still very far away from it. In the e-commerce environment software is getting more and more a “utility” for which “scalability” is more important than “features”. From a business perspective there is no difference between "intentional" (normally dealt with in the "security" context) and "unintentional" (normally dealt with in the safety context) disruptive events. From a business perspective there is no difference between a virus and a bug or from a bomb and a quake. The human component is still a very critical to the dependability of systems and organisations.

For the future, the overall goal of pursuing dependability and interdependencies in Information Society would have to support innovative and multidisciplinary RTD to tackle scale issues of dependability connected with new business and everyday life application scenarios such as (i) the increasing volatility and growing heterogeneity of products, applications, services, systems and processes in the digital environment as well as (ii) the increasing interconnection and interdependency of the information and communication infrastructure and with other vital services and systems for our society and our economy. This would lead to new areas for research on dependability aiming at
building robust foundations for Information Society through novel multidisciplinary and innovative system-model approaches, architectures and technologies to realise dependable, survivable and evolvable systems, platforms and information infrastructures;
understanding, modelling and controlling the interdependencies among largescale systems and infrastructures resulting from the pervasiveness and inte rconnectedness of information and communication technologies.

3.1 Towards FP6: The Roadmap Projects In order to prepare the ground for research initiatives in the FP6 [7], with particular attention to the new instruments of Integrated Projects (IP) and Networks of Excellence (NoE) [8], seven Roadmap projects on security and dependability have recently been launched with the goals:
to identify the research challenges in the respective area, to assess Europe’s competitive position and potential, and to derive a strategic roadmaps for a pplied research driven by visionary scenarios;
to build constituencies and reach consensus by means of feedback loops with the stakeholders at all relevant levels. The projects address issues around securing infrastructures, securing mobile ser vices, dependability, personal trusted devices, privacy and basic security technologies. Below is a short summary of the three Roadmap projects on dependability, precisely

16

Andrea Servida

AMSD, which focuses on a global and holistic view of dependability; ACIP, which tackles the are of simulation and modelling for critical infrastructure protection; WGALPINE, which looks at survivability and loss prevention aspects. These roadmaps would nicely complement and enrich the work of DDSI that tackles the area of dependability from a policy support angle.

AMSD - IST-2001-37553: Accompanying Measure System Dependability This project addresses the need for a coherent major initiative in FP6 encompas sing a full range of dependability-related activities, e.g. RTD on the various aspects of dependability per se; (reliability, safety, security, survivability, etc.), education and training; and means for encouraging and enabling sector-specific IST RTD projects to use dependability best practice. It is aimed at initiating moves towards the creation of such an Initiative, via road- mapping and constituency and conse nsus building undertaken in co-operation with groups, working in various depen dability-related topic areas, who are already undertaking such activities for their domains. The results will be an overall dependability roadmap that considers d ependability in an adequately holistic way, and a detailed roadmap for dependable embedded systems. ACIP - IST-2001-37257: Analysis & Assessment for Critical Infrastructure Protection Developed societies have become increasingly dependent on ICT and services. Infrastructures such as IC, banking and finance, energy, transportation, and others are relying on ICT and are mutually dependent. The vulnerability of these infr astructures to attacks may result in unacceptable risks because of primary and cascading effects. The investigation of cascading and feedback effects in highly complex, networked systems requires massive support by computer-based tools. The aim of ACIP is to provide a roadmap for the development and application of modelling and simulation, gaming and further adequate methodologies for the fo llowing purposes:
identification and evaluation of the state of the art of CIP;
analysis of mutual dependencies of infrastructures and cascading effects;
investigation of different scenarios in order to determine gaps, deficiencies, and robustness of CIS;
identification of technological development and necessary protective measures for CIP. WG-ALPINE - IST-2001-38703 : Active Loss Prevention for ICT-enabled Enterprise Working Group The main objective of this project is the creation, operation and consolidation of an Active Loss Prevention Working Group to address the common ICT Security problems faced by users, achieve consensus on their solutions across multiple disciplines, and produce a favourable impact in the overall eBusiness market. The Working Group approaches the problems from an ICT user perspective, with spe-

Dependability in the Information Society: Getting Ready for the FP6

17

cial emphasis on the view of small/medium systems integrators (SMEs), while establishing liaisons with all players, including representatives from the key European professional Communities that must collaborate to achieve a more effective approach to ICT Security. These include legal, audit, insurance, accounting, commercial, government, standardisation bodies, technology vendors, and others. DDSI – IST-2001-29202 : Dependability Development Support Initiative The goal of DDSI is to support the development of dependability policies across Europe. The overall aim of this project is to establish networks of interest, and to provide baseline data upon which a wide spectrum of policy-supporting activities can be undertaken both by European institutions and by public and private sector stakeholders across the EU and in partner nations. By convening workshops, bringing together key experts and stakeholders in critical infrastructure depen dability, DDSI facilitates the emergence of a new culture of Trans-national collaboration in this field, which is of global interest, and global concern. In order to make rapid progress in the area, the outcomes of the workshops as well as the i nformation gathered in order to prepare for the workshops will be actively disseminated towards a wider, but still targeted community of interest, including policy makers business, decision makers, researchers and other actors already actively contributing to this field today.

4 Conclusions The construction of the Information Society and the fast growing development of ecommerce are making our Society and Economy more and more dependent on computer based information systems, electronic communication networks and information infrastructures that are becoming pervasive as well as an essential part of the EU citizens’ live. Achieving the dependable behaviour of the Information Society means protecting our industry wealth and investments in IT as well as in other intangible assets. Furthermore, achieving the dependable behaviour of the infrastructure would mean ensuring flexible and co-operative management of the large-scale computing and networking resources and providing resources for effective prevention detection, confinement and response to disruptions. The dependable behaviour of the information infrastructure depends, however, on the behaviour of a growing number of players, systems and networks, including the users and the user systems. The interdependency among critical infrastructures that are enabled and supported by the inform ation infrastructure can not be easily mastered by currently available technologies. The dependability approach, which privileges the understanding of the implic ation of our need to rely on systems and, consequently, the adoption of a risk management approach, appears to be instrumental to foster a new culture of social and economic responsibility. However, more innovative and multidisciplinary research

18

Andrea Servida

on dependability is needed to make the Information Society more robust and resilient to technical vulnerability, failures and attacks.

References 1. DEPPY Forum htpp:/deppy.jrc.it/ 2. IST web site www.cordis.lu/ist 3. IST in FP6 http://www.cordis.lu/ist/fp6/fp6.htm 4. Cross Programme Action on dependability http://www.cordis.lu/ist/cpt/cpa4.htm 5. eEurope 2002 Action Plan http://europa.eu.int/information_society/eeurope/index_en.htm 6. DDSI web site http://www.ddsi.org/DDSI/index.htm 7. FP6 http://europa.eu.int/comm/research/fp6/index_en.html 8. FP6 Instruments http://europa.eu.int/comm/research/fp6/networks-ip.html

A Rigorous View of Mode Confusion Jan Bredereke and Axel Lankenau Universit¨ at Bremen FB 3, P.O. box 330 440, D-28334 Bremen, Germany {brederek,alone}@tzi.de www.tzi.de/{~brederek,~alone} Fax: +49-421-218-3054

Abstract. Not only in aviation psychology, mode confusion is recognised as a significant safety concern. The notion is used intuitively in the pertinent literature, but with surprisingly different meanings. We present a rigorous way of modelling the human and the machine in a shared-control system. This enables us to propose a precise definition of “mode” and “mode confusion”. In our modelling approach, we extend the commonly used distinction between the machine and the user’s mental model of it by explicitly separating these and their safety-relevant abstractions. Furthermore, we show that distinguishing three different interfaces during the design phase reduces the potential for mode confusion. A result is a new classification of mode confusions by cause, leading to a number of design recommendations for shared-control systems which help to avoid mode confusion problems. A further result is a foundation for detecting mode confusion problems by model checking.

1

Introduction and Motivation

Automation surprises are ubiquitous in today’s highly engineered world. We are confronted with mode confusions in many everyday situations: When our cordless phone rings while it is located in its cradle, we establish the line by just lifting the handset — and inadvertently cut it when we press the “receiver button” as usual with the intention to start speaking. We get annoyed if we once again overwrite some text in the word processor because we had hit the “Ins”key before (and thereby left the insert mode!) without noticing. The American Federal Aviation Administration (FAA) considers mode confusion to be a significant safety concern in modern aircraft. So, it’s all around — but what exactly is a mode, what defines a mode confusion situation and how can we detect and avoid automation surprises? As long as we have no rigorous definition, we should regard a mode confusion as one kind of an automation surprise. It refers to a situation in which a technical system can behave differently from the user’s expectation. Whereas mode confusions in typical human-computer interactions, such as the word processor example mentioned above, are “only” annoying, they become dangerous if we consider safety-critical systems. S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 19–31, 2002. c Springer-Verlag Berlin Heidelberg 2002


20

Jan Bredereke and Axel Lankenau

Today, many safety-critical systems are so-called embedded shared-control systems. These are interdependently controlled by an automation component and a user. Examples are modern aircraft, automobiles, but also intelligent wheelchairs. We focus on such shared-control systems in this paper and call the entirety of technical components technical system and the human operator user. Note that we have to take a black-box stand, i. e. we can only work with the behaviour of the technical system observable at its interfaces: since we want to solve the user’s problems, we have to take his or her point of view, which does not allow access to internal information of the system. As Rushby points out [1], in cognitive science it is generally agreed upon that humans use so-called mental models when they interact with (automated) technical systems. Since there are at least two completely different interpretations of the notion “mental model” in the pertinent literature, it is important to clarify that we refer to the one introduced by Norman [2]: A mental model represents the user’s knowledge about a technical system, it consists of a na¨ıve theory of the system’s behaviour. According to Rushby [1], an explicit description of a mental model can be derived, e. g., in form of a state machine representation, from training material, from user interviews, or by user observation. We briefly recapitulate the pertinent state of the art here. It remains surprisingly unclear what a mode as such is. While some relevant publications give no [3, 4] or only an implicit definition [5, 6] of the notions “mode” and “mode confusion”, there are others that present an explicit informal definition [7, 8, 9, 10]. Doherty [11] presents a formal framework for interactive systems and also gives an informal definition of “mode error”. Wright and colleagues give explicit but example driven definitions of the notions “error of omission” and “error of commission” by using CSP to specify user tasks [12]. Interestingly, the way of modelling often seems to be influenced significantly by the tool that is meant to perform the final analysis. Degani and colleagues use State Charts to model separately the technical system and the user’s mental model [13]. Then, they build the composition of both models and search for certain states (so-called “illegal” and “blocking” states) which indicate mode confusion potential. Butler et al. use the theorem prover PVS to examine the flight guidance system of a civil aircraft for mode confusion situations [4]. They do not consider the mental model of the pilot as an independent entity in their analysis. Leveson and her group specify the black-box behaviour of the system in the language SpecTRM-RL that is both well readable by humans and processible by computers [10, 14, 15]. In [10], they give a categorisation of different kinds of modes and a classification of mode confusion situations. Rushby and his colleagues employ the Murφ model-checking tool [16, 5, 3]. Technical system and mental model are coded together as a single set of so-called Murφ rules. L¨ uttgen and Carre˜ no examine the three state-exploration tools Murφ, SMV, and Spin with respect to their suitability in the search for mode confusion potential [17]. Buth [9] and Lankenau [18] clearly separate the technical system and the user’s mental model in their CSP specification of the well-known MD88-“kill-the-capture” scenario and in a service-robotics example, respectively.

A Rigorous View of Mode Confusion

21

The support of this clear separation is one reason why Buth’s comparison between the tool Murφ and the CSP tool FDR favours the latter [9, pages 209-211]. Almost all publications refer to aviation examples when examining a case study: an MD-88 [19, 7, 10, 16, 9], an Airbus A320 [3, 6], or a Boeing 737 [5]. Rushby proposes a procedure to develop automated systems which pays attention to the mode confusion problem [1]. The main part of his method is the integration and iteration of a model-checking based consistency check and the mental model reduction process introduced by [20, 3]. Hourizi and Johnson [6, 21] generally doubt that avoiding mode confusions alone helps to reduce the number of plane crashes caused by automation surprises. They claim that the underlying problem is not mode confusion but what they call a “knowledge gap”, i. e. the user’s insufficient perception prevents him or her from tracking the system’s mode. As far as we are aware, there is no publication so far that defines “mode” and “mode confusion” rigorously. Therefore, our paper clarifies these notions. Section 2 introduces to the domain of our case study, which later serves as a running example. Section 3 and 4 present a suitable system modelling approach and clarify different world views, which enables us to present rigorous definitions in Sect. 5. Section 6 works out the value of such definitions, which comprises a foundation for the automated detection of mode confusion problems and a classification of mode confusion problems by cause, which in turn leads to recommendations for avoiding mode confusion problems. A summary and ideas for future work conclude the paper.

2

Case Study Wheelchair

Our case study has a service robotics background: we examine the cooperative obstacle avoidance behaviour of our wheelchair robot. The Bremen Autonomous Wheelchair “Rolland” is a shared-control service robot which realizes intelligent and safe transport for handicapped and elderly people [22, 23]. The vehicle is a commercial off-the-shelf power wheelchair. It has been equipped with a control PC, a ring of sonar sensors, and a laser range finder. Rolland is jointly controlled by its user and by the software. Depending on the active operation mode, either the user or the automation is in charge of driving the wheelchair.

3

Precise Modelling

Before we can discuss mode confusion problems, some remarks on modelling a technical system in general are necessary. The user of a running technical system has a strict black-box view. Since we want to solve the user’s problems, we must take the same black-box point of view. This statement appears to be obvious, but has far-reaching consequences for the notion of mode. The user has no way of observing the current internal state, or mode, of the technical system.

22

Jan Bredereke and Axel Lankenau

Nevertheless, it is possible to describe a technical system in an entirely blackbox view. Our software engineering approach is inspired by the work of Parnas [24, 25], even though we start out with events instead of variables, as he does. We can observe (only) the environment of the technical system. When something relevant happens, we call this an event. When the technical system is the control unit of an automated wheelchair, then an event may be that the user pushes the joystick forward, that the wheelchair starts to move, or an event may as well be that the distance between the wheelchair and a wall ahead becomes smaller than the threshold of 70 cm. The technical system has been constructed according to some requirements document REQ. It contains the requirements on the technical system, which we call SYSREQ, and those on the system’s environment NAT. However, if we deal with an existing system for which no (more) requirements specification is available, it might be necessary to “reverse engineer” it from the implementation. For the wheelchair, SYSREQ should state that the event of the wheelchair starting to move follows the event that the joystick is pushed forward. SYSREQ should also state what happens after the event of approaching a wall. Of course, the wheelchair should not crash into a wall in front of it, even if the joystick is pushed forward. We can describe this entirely in terms of observable events, by referring to the history of events until the current point of time. If the wheelchair has approached a wall, and if it has not yet moved back, it must not move forward further. For this description, no reference to an internal state is necessary. In order to implement the requirements SYSREQ on a technical system, one usually needs several assumptions about the environment of the technical system to construct. For example, physical laws guarantee that a wheelchair will not crash into a wall ahead unless it has approached it closer than 70 cm and has continued to move for a certain amount of time. We call the documentation of assumptions about the environment NAT. NAT must be true even before the technical system is constructed. It is the implementer’s task to ensure that SYSREQ is true provided that NAT holds.

4 4.1

Clarification of World Views Where are the Boundaries?

The control software of a technical system cannot observe physical events directly. Instead, the technical system is designed such that sensor devices generate internal input events for the software, and the software’s output events are translated by actuator devices into physical events, again. Neither sensors nor actuators are perfectly precise and fast, therefore we have a distinct set of software events. Accordingly, the requirements on the technical system and the requirements on the software cannot be the same. For example, the wheelchair’s ultrasonic distance sensors for the different directions can be activated in turns only, resulting in a noticeable delay for detecting obstacles. We call the software

A Rigorous View of Mode Confusion

23

SYSREQ environment events

IN

software events

SOF

software events

OUT

environment events

Fig. 1. System requirements SYSREQ vs. software requirements SOF

requirements SOF, the requirements on the input sensors IN and the requirements on the output actuators OUT. Figure 1 shows the relationships among them. An important consequence is that the software SOF must compensate for any imperfectness of the sensors and actuators so that the requirements SYSREQ are satisfied. When defining SOF, we definitely need to take care whether we refer to the boundary of SOF or of SYSREQ. This becomes even more important when we consider the user who cooperates with the technical system. He or she observes the same variables of the environment as the technical system does. But the user observes them through his/her own set of senses SENS. SENS has its own imperfections. For example, a human cannot see behind his/her back. Our automated wheelchair will perceive a wall behind it when moving backwards, but the user will probably not. Therefore, we need to distinguish what actually happens in reality (specified in REQ, i. e. the composition of SYSREQ and NAT) from the user’s mental model MMOD of it. When making a statement about MMOD, we definitely need to take care whether we refer to the boundary of MMOD or of REQ. When we define the interfaces precisely, it turns out that there is an obvious potential for a de-synchronisation of the software’s perception of reality with the user’s perception of it. And when we analyse this phenomenon, it is important to distinguish between the three different interfaces: environment to machine (or to user), software to input/output devices, and mental to senses. As a result, we are able to establish a precise relation between reality as it is perceived by the user and his/her mental model of it. This relation will be the base of our definition of mode confusion. 4.2

Brief Introduction to Refinement

As will be explained later, we use a kind of specification/implementation relation in the following sections. Such relations can be modelled rigorously by the concept of refinement. There exist a number of formalisms to express refinement relations. We use CSP [26] as specification language and the refinement semantics proposed by Roscoe [27]. One reason is that there is good tool support for performing automated refinement checks of CSP specifications with the tool FDR [27]. This section shall clarify the terminology for readers who are not familiar with the concepts. In CSP, the behaviour of a process P is described by the set traces(P ) of the event sequences it can perform. Since we must pay attention to what can be

24

Jan Bredereke and Axel Lankenau

done as well as to what can be not done, the traces model is not sufficient in our domain. We have to enhance it by so-called failures. Definition 1 (Failure). A failure of a process P is a pair (s, X) of a trace s (s ∈ traces(P )) and a so-called refusal set X of events that may be blocked by P after the execution of s. If an output event o is in the refusal set X of P , and if there also exists a continuation trace s which performs o, then process P may decide internally and non-deterministically whether o will be performed or not. Definition 2 (Failure Refinement). P refines S in the failures model, written S F P , iff traces(P ) ⊆ traces(S) and also failures(P ) ⊆ failures(S). This means that P can neither accept an event nor refuse one unless S does; S can do at least every trace which P can do, and additionally P will refuse not more than S does. Failure refinement allows to distinguish between external and internal choice in processes, i.e. whether there is non-determinism. As this aspect is relevant for our application area, we use failure refinement as the appropriate kind of refinement relation. 4.3

Relation between Reality and the Mental Model

Our approach is based on the motto “The user must not be surprised ” as an important design goal for shared-control systems. This means that the perceived reality must not exhibit any behaviour which cannot occur according to the mental model. Additionally, the user must not be surprised because something expected does not happen. When the mental model prescribes some behaviour as necessary, reality must not refuse to perform it. These two aspects are described by the notion of failure refinement, as defined in the previous section. There cannot be any direct refinement relation between a description of reality and the mental model, since they are defined over different sets of events (i.e., environment/mental). We understand the user’s senses SENS as a relation from environment events to mental events. SENS(REQ) is the user’s perception of what happens in reality. The user is not surprised if SENS(REQ) is a failure refinement of MMOD. As a consequence, the user’s perception of reality must be in an implementation/specification relationship to the mental model. Please note that an equality relation always implies a failure refinement relation, while the converse is not the case. If the user does not know how the system will behave with regard to some aspect, but knows that he/she does not know, then he/she will experience no surprise nevertheless. Such indifference can be expressed mathematically by a non-deterministic internal choice in the mental model. 4.4

Abstractions

When the user concentrates on safety, he/she performs an on-the-fly simplification of his/her mental model MMOD towards the safety-relevant part

A Rigorous View of Mode Confusion system designer’s view safety− relevant abstraction

SENSE

SAFE

(REQ

)

user’s view failure refinement

SAFE

abstraction A R detailed black−box description

SENSE(REQ)

25

MMOD

SAFE

abstraction A M failure refinement

MMOD

Fig. 2. Relationships between the different refinement relations

MMODSAFE . This helps him/her to analyse the current problem with the limited mental capacity. Analogously, we perform a simplification of the requirements document REQ to the safety-relevant part of it REQSAFE . REQSAFE can be either an explicit, separate chapter of REQ, or we can express it implicitly by specifying an abstraction function, i. e., by describing which aspects of REQ are safety-relevant. We abstract REQ out of three reasons: MMODSAFE is defined over a set of abstracted mental events, and it can be compared to another description only if it is defined over the same abstracted set; we would like to establish the correctness of the safety-relevant part without having to investigate the correctness of everything; and our model-checking tool support demands that the descriptions are restricted to certain complexity limits. We express the abstraction functions mathematically in CSP by functions over processes. Mostly, such an abstraction function maps an entire set of events onto a single abstracted event. For example, it is irrelevant whether the wheelchair’s speed is 81.5 or 82 cm/s when approaching an obstacle – all such events with a speed parameter greater than 80 cm/s will be abstracted to a single event with the speed parameter fast. Other transformations are hiding (or concealment [26]) and renaming. But the formalism also allows for arbitrary transformations of behaviours; a simple example being a certain event sequence pattern mapped onto a new abstract event. We use the abstraction functions AR for REQ and AM for MMOD, respectively. The relation SENS from the environment events to the mental events must be abstracted in an analogous way. It should have become clear by now that SENS needs to be rather true, i. e., a bijection which does no more than some renaming of events. If SENS is “lossy”, we are already bound to experience mode confusion problems. For our practical work, we therefore first make sure that SENS is such a bijection, and then merge it into REQ, even before we perform the actual abstraction step which enables the use of the model-checking tool. Figure 2 shows the relationships among the different descriptions. In order that the user is not surprised with respect to safety, there must be a failure refinement relation on the abstract level between SENSSAFE (REQSAFE ) and MMODSAFE , too.

26

5

Jan Bredereke and Axel Lankenau

A Rigorous View of Mode and of Mode Confusion

We will now present our rigorous definitions of mode and mode confusion. We will then motivate and discuss our choices. In the following, let REQSAFE be a safety-relevant black-box requirements specification, let SENSSAFE be a relation between environment events and mental events representing the user’s senses, and let MMODSAFE be a safety-relevant mental model of the behaviour of REQSAFE . Definition 3 (Potential future behaviour). A potential future behaviour is a set of failures. Definition 4 (Mode). A mode of SENSSAFE (REQSAFE ) is a potential future behaviour. And, a mode of MMODSAFE is a potential future behaviour. Definition 5 (Mode confusion). A mode confusion between SENSSAFE (REQSAFE ) and MMODSAFE occurs if and only if SENSSAFE (REQSAFE ) is not a failure refinement of MMODSAFE i.e., iff MMODSAFE F SENSSAFE (REQSAFE ) . After the technical system T has moved through a history of events, it is in some “state”. Since we have to take a black-box view, we can distinguish two “states” only if T may behave differently in the future. We describe the potential future behaviour by a set of failures, such that we state both what T can do and what T can refuse to do. This definition of “state” is rather different from the intuition in a white-box view, but necessarily so. Our next step to the notion of “mode” then is more conventional. We use the notion of “state”, if at all, in the context of the non-abstracted descriptions. Two states of a wheelchair are different, for example, if the steerable wheels will be commanded to a steering angle of 30 degrees or 35 degrees, respectively, within the next second. These states are equivalent with regard to the fact of obstacle avoidance. Therefore, both states are mapped to the same abstracted behaviour by the safety-relevance abstraction function. We call such a distinct safety-relevant potential future behaviour a mode. Usually, many states of the non-abstracted description are mapped together to such a mode. On a formal level, both a state and a mode are a potential future behaviour. The difference between both is that there is some important safety-relevant distinction between any two modes, which need not be the case for two states. We now can go on to mode confusions. The perceived reality and the user’s mental model of it are in different modes at a certain point of time if and only if the perceived reality and the mental model might behave differently in the future, with respect to some safety-relevant aspect. Only if no such situation can arise in any possible execution trace, then there is no mode confusion. This means that the user’s safety-relevant mental model must be a specification of the perceived reality. Expressed the other way around, the perceived reality must be an implementation of the user’s safety-relevant mental model. This specification/implementation relationship can be described rigorously by failure refinement. If we have precise descriptions of both safety-relevant behaviours, we can

A Rigorous View of Mode Confusion

27

rigorously check whether a mode confusion occurs. Since model-checking tool support exists, this check can even be automated. Please note that we referred to the reality, as described by REQ, which not only includes the system’s requirements SYSREQ but also the environment requirements NAT. This restricts the behaviour of SYSREQ by NAT: behaviour forbidden by physical laws is not relevant for mode confusions. Our mathematical description allows for some interesting analysis of consequences. It is known in the literature that implicit mode changes may be a cause of mode confusion. In our description, an implicit mode change appears as an “internal choice” of the system, also known as a (spontaneous) “τ transition”. The refinement relation dictates that any such internal choice must appear in the specification, too, which is the user’s mental model in our case. This is possible: if the user expects that the system chooses internally between different behaviours, he/she will not be surprised, at least in principle. The problem is that the user must keep in mind all potential behaviours resulting from such a choice. If there is no clarifying event for a long time, the space of potential behaviours may grow very large and impractical to handle in practice.

6

Results

Our definitions form a foundation for detecting mode confusions by modelchecking. It has opened new possibilities for a comprehensive analysis of mode confusion problems, which we currently explore in practice. Our clarification of world views in Sect. 4 enables us to classify mode confusion problems into three classes: 1. Mode confusion problems which arise from an incorrect observation of the technical system or its environment. Formally, this is the case when SENS(REQ) is not a failure refinement of MMOD, but where SENS(REQ) would be a failure refinement of MMOD, provided the user’s senses SENS would be a perfect mapping from environment events to mental events. The imperfections of SENS may have physical or psychological reasons: either the sense organs are not perfect; for example eyes which cannot see behind the back. Or an event is sensed, but is not recognised consciously; for example because the user is distracted, or because the user currently is flooded with too many events. (“Heard, but not listened to.”) Please note that our notion of mode confusion problem also comprises the “knowledge gap” discussed in the research critique by Hourizi and Johnson [6, 21] (see Sect. 1). In our work, it appears as a mode confusion problem arising from an incorrect observation due to psychological reasons. 2. Mode confusion problems which arise from incorrect knowledge of the human about the technical system or its environment. Formally, this is the case when SENS(REQ) is not a failure refinement of MMOD, and when a perfect SENS would make no difference.

28

Jan Bredereke and Axel Lankenau

3. Mode confusion problems which arise from the incorrect abstraction of the user’s knowledge to the safety-relevant aspects of it. Formally, this means that SENS(REQ) is a failure refinement of MMOD, but SENSSAFE (REQSAFE ) is not a failure refinement of MMODSAFE . Since the safety-relevant requirements abstraction function AR is correct by definition, the user’s mental safety-relevance abstraction function AM must be wrong in this case (compare Figure 2 above). In contrast to previous classifications of mode confusion problems, this classification is by cause and not phenomenological, as, e.g., the one by Leveson [10]. The above causes of mode confusion problems lead directly to some recommendations for avoiding them. In order to avoid an incorrect observation of the technical system and its environment, we must check whether the user can physically observe all safety-relevant environment events, and we must check whether the user’s senses are sufficiently precise to ensure an accurate translation of these environment events to mental events. If this is not the case, then we must change the system requirements. We must add an environment event controlled by the machine and observed by the user which indicates the corresponding software input event. This measure has been recommended by others too, of course, but our rigorous view now indicates more clearly when it must be applied. Avoiding an incorrect observation also comprises that we check whether psychology ensures that observed safety-relevant environment events become conscious. Our approach points out clearly the necessity of this check. The check itself and any measures belong to the field of psychology, in which we are not expert. Establishing a correct knowledge of the user about the technical system and its environment can be achieved by documenting the requirements of them rigorously. This enables us to conceive user training material, such as a manual, which is complete with respect to functionality. This training material must not only be complete but also learnable. Complexity is an important learning obstacle. Therefore, the requirements of the technical system should allow as little non-deterministic internal choices as possible, since tracking all alternative outcomes is complex. This generalises and justifies the recommendation by others to eliminate “implicit mode changes” [10, 8]. Internal non-determinism may arise not only from the software, but also from the machine’s sensor devices. If they are imprecise, the user cannot predict the software input events. We can eliminate both kinds of non-deterministic internal choice by the same measure as used against an incorrect physical observation: we add an environment event controlled by the machine which indicates the software’s choice or the input device’s choice, respectively. Ensuring a correct mental abstraction process is mainly a psychological question and mostly beyond the scope of this paper. Our work leads to the basic recommendation to either write an explicit, rigorous safety-relevance requirements document or to indicate the safety-relevant aspects clearly in the general requirements document. The latter is equivalent to making explicit the safety-relevance

A Rigorous View of Mode Confusion

29

abstraction function for the machine AR . Either measure facilitates to conceive training material which helps the user to concentrate on safety-relevant aspects.

7

Summary and Future Work

We present a rigorous way of modelling the user and the machine in a sharedcontrol system. This enables us to propose precise definitions of “mode” and “mode confusion”. In our modelling approach, we extend the commonly used distinction between the machine and the user’s mental model of it by explicitly separating these and their safety-relevant abstractions. Furthermore, we show that distinguishing three different interfaces during the design phase reduces the potential for mode confusion. Our proposition that the user must not be surprised leads directly to the conclusion that the relationship between the mental model and the machine must be one of specification to implementation, in the mathematical sense of refinement. Mode confusions can occur if and only if this relation is not satisfied. A result of this insight is a new classification of mode confusions by cause, leading to a number of design recommendations for shared-control systems which help to avoid mode confusion problems. Since tools to model-check refinement relations exist, our approach supports the automated detection of remaining mode confusion problems. For illustration, we presented a case study on a wheelchair robot as a running example. A detailed version of the case study is discussed in [28]. Our work lends itself to extension into several directions. We currently work in our case study on exploiting the new potential for detecting mode confusion problems by model-checking. Furthermore, the recommendations for avoiding mode confusion problems can be tried out. Experts in psychology will be able to implement the non-technical ones of our rules by concrete measures. Finally, we see still more application domains beyond aviation and robotics.

References [1] Rushby, J.: Modeling the human in human factors. In: Proc. of SAFECOMP 2001. Volume 2187 of LNCS., Springer (2001) 86–91 20, 21 [2] Norman, D.: Some observations on mental models. In Gentner, D., Stevens, A., eds.: Mental Models. Lawrence Erlbaum Associates Inc., Hillsdale, NJ, USA (1983) 20 [3] Crow, J., Javaux, D., Rushby, J.: Models and mechanized methods that integrate human factors into automation design. In Abbott, K., Speyer, J. J., Boy, G., eds.: Proc. of the Int’l Conf. on Human-Computer Interaction in Aeronautics: HCI-Aero 2000, Toulouse, France (2000) 20, 21 [4] Butler, R., Miller, S., Pott, J., Carre˜ no, V.: A formal methods approach to the analysis of mode confusion. In: Proc. of the 17th Digital Avionics Systems Conf., Bellevue, Washington, USA (1998) 20 [5] Rushby, J.: Analyzing cockpit interfaces using formal methods. In Bowman, H., ed.: Proc. of FM-Elsewhere. Volume 43 of Electronic Notes in Theoretical Computer Science., Pisa, Italy, Elsevier (2000) 20, 21

30

Jan Bredereke and Axel Lankenau

[6] Hourizi, R., Johnson, P.: Beyond mode error: Supporting strategic knowledge structures to enhance cockpit safety. In: Proc. of IHM-HCI 2001, Lille, France, Springer (2001) 20, 21, 27 [7] Sarter, N., Woods, D.: How in the world did we ever get into that mode? Mode error and awareness in supervisory control. Human Factors 37 (1995) 5–19 20, 21 [8] Degani, A., Shafto, M., Kirlik, A.: Modes in human-machine systems: Constructs, representation and classification. Int’l Journal of Aviation Psychology 9 (1999) 125–138 20, 28 [9] Buth, B.: Formal and Semi-Formal Methods for the Analysis of Industrial Control Systems – Habilitation Thesis. Univ. Bremen (2001) 20, 21 [10] Leveson, N., Pinnel, L., Sandys, S., Koga, S., Reese, J.: Analyzing software specifications for mode confusion potential. In: Workshop on Human Error and System Development, Glasgow, UK (1997) 20, 21, 28 [11] Doherty, G.: A Pragmatic Approach to the Formal Specification of Interactive Systems. PhD thesis, University of York, Dept. of Computer Science (1998) 20 [12] Wright, P., Fields, B., Harrison, M.: Deriving human-error tolerance requirements from tasks. In: Proc. of the 1st Int’l Conf. on Requirements Engineering, Colorado, USA, IEEE (1994) 135–142 20 [13] Degani, A., Heymann, M.: Pilot-autopilot interaction: A formal perspective. In Abbott, K., Speyer, J. J., Boy, G., eds.: Proc. of the Int’l Conf. on HumanComputer Interaction in Aeronautics: HCI–Aero 2000, Toulouse, France (2000) 157–168 20 [14] Rodriguez, M., Zimmermann, M., Katahira, M., de Villepin, M., Ingram, B., Leveson, N.: Identifying mode confusion potential in software design. In: Proc. of the Int’l Conf. on Digital Aviation Systems, Philadelphia, PA, USA (2000) 20 [15] Zimmermann, M., Rodriguez, M., Ingram, B., Katahira, M., de Villepin, M., Leveson, N.: Making formal methods practical. In: Proc. of the Int’l Conf. on Digital Aviation Systems, Philadelphia, PA, USA (2000) 20 [16] Rushby, J., Crow, J., Palmer, E.: An automated method to detect potential mode confusions. In: Proc. of the 18th AIAA/IEEE Digital Avionics Systems Conf., St. Louis, Montana, USA (1999) 20, 21 [17] L¨ uttgen, G., Carre˜ no, V.: Analyzing mode confusion via model checking. In Dams, D., Gerth, R., Leue, S., Massink, M., eds.: SPIN’ 99. Volume 1680 of LNCS., Berlin Heidelberg, Springer (1999) 120–135 20 [18] Lankenau, A.: Avoiding mode confusion in service-robots. In Mokhtari, M., ed.: Integration of Assistive Technology in the Information Age, Proc. of the 7th Int’l Conf. on Rehabilitation Robotics, Evry, France, IOS Press (2001) 162–167 20 [19] Palmer, E.: “Oops, it didn’t arm.” – A case study of two automation surprises. In: Proc. of the 8th Int’l Symp. on Aviation Psychology. (1995) 21 [20] Javaux, D.: Explaining Sarter & Woods’ classical results. The cognitive complexity of pilot-autopilot interaction on the Boeing 737-EFIS. In: Proc. of HESSD ’98. (1998) 62–77 21 [21] Hourizi, R., Johnson, P.: Unmasking mode errors: A new application of task knowledge principles to the knowledge gaps in cockpit design. In: Proc. of INTERACT 2001 – The 8th IFIP Conf. on Human Computer Interaction, Tokyo, Japan (2001) 21, 27 [22] R¨ ofer, T., Lankenau, A.: Architecture and applications of the Bremen Autonomous Wheelchair. Information Sciences 126 (2000) 1–20 21

A Rigorous View of Mode Confusion

31

[23] Lankenau, A., R¨ ofer, T.: The Bremen Autonomous Wheelchair – a versatile and safe mobility assistant. IEEE Robotics and Automation Magazine, “Reinventing the Wheelchair” 7 (2001) 29–37 21 [24] Parnas, D. L., Madey, J.: Functional documents for computer systems. Science of Computer Programming 25 (1995) 41–61 22 [25] van Schouwen, A. J., Parnas, D. L., Madey, J.: Documentation of requirements for computer systems. In: IEEE Int’l. Symp. on Requirements Engineering – RE’93, San Diego, California, USA, IEEE Comp. Soc. Press (1993) 198–207 22 [26] Hoare, C.: Communicating Sequential Processes. Prentice-Hall, Englewood Cliffs, New Jersey. USA (1985) 23, 25 [27] Roscoe, A. W.: The Theory and Practice of Concurrency. Prentice-Hall (1997) 23 [28] Lankenau, A.: Bremen Autonomous Wheelchair “Rolland”: Self-Localization and Shared-Control – Challenges in Mobile Service Robotics. PhD thesis, Universit¨ at Bremen, Dept. of Mathematics and Computer Science (2002) To appear 29

Dependability as Ordinary Action Alexander Voß1 , Roger Slack1 , Rob Procter1, Robin Williams2 , Mark Hartswood1 , and Mark Rouncefield3 1

2

School of Informatics, University of Edinburgh, UK {av,rslack,rnp,mjh}@cogsci.ed.ac.uk Research Centre for Social Sciences, University of Edinburgh, UK [email protected] 3 Department of Computing, University of Lancaster, UK [email protected]

Abstract. This paper presents an ethnomethodologically informed study of the ways that more-or-less dependable systems are part of the everyday lifeworld of society members. Through case study material we explicate how dependability is a practical achievement and how it is constituted as a common sense notion. We show how attending to the logical grammar of dependability can clarify some issues and potential conceptual confusions around the term that occur between lay and ‘professional’ uses. The paper ends with a call to consider dependability in its everyday ordinary language context as well as more ‘professional’ uses of this term.

1

Introduction

In this paper we are concerned with the ways in which people experience dependability. We are interested in explicating in-vivo ethnographic accounts of living with systems that are more or less reliable and the practices that this being ‘more or less dependable’ occasions. The situated practical actions of living with systems (e.g. work arounds and so on) are important to us in that they show how society members1 experience dependability as a practical matter. Drawing on the work of the later Wittgenstein [13], we seek to explicate what dependability means in an ordinary language sense and to provide an analysis of the ways in which systems come to be seen as dependable, and the work involved in making them more or less dependable. Such an analysis of ordinary language uses of terms is not intended as a remedy or corrective to ‘professional’ uses, but to show how we might capitalise on lay uses of the term and thereby secure in part a role for ethnographic analysis of what, following Livingston [7] we call the ‘lived world’ of working with more or less dependable systems. We draw on a case study of practical IT use and development [11] that illustrate how dependability is realised in and as part of peoples’ everyday ordinary activities. 1

This points to the skills persons have, what they know and do competently in a particular setting. In this usage we also stress mundane, banal competence as opposed to professionalised conduct.

S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 32–43, 2002. c Springer-Verlag Berlin Heidelberg 2002


Dependability as Ordinary Action

2

33

The Case Study

The case study organisation, EngineCo, produces mass-customised diesel engines from 11 to 190 kW. Production in its plant was designed to work along a strict production orthodoxy and large parts are automated. Since the plant was built in the early 1990s, significant changes have been made to keep up with changing customer demands and to keep the plant operational in a difficult economic environment. The organisation makes heavy use of a wide range of information technologies and, to a large extent, their operation depends on complex ensembles of these technologies. An ethnographic study of the working practices of control room workers has been conducted over the course of the last two years [10] as a pradicate for participatory design activities. The ethnographic method is dedicated to observing in detail everyday working practices and seeks to explicate the numerous, situated ways in which those practices are actually achieved [4]. Interviews with staff were recorded, and notes made of activities observed and artifacts employed. The data also includes copious notes and transcriptions of talk of ‘members’ (i.e. regular participants in the work setting) as they went about their everyday work. Ethnography is attentive to the ways in which work actually ‘gets done’, the recognition of the tacit skills and cooperative activities through which work is accomplished as an everyday, practical activity and it aims to make these processes and practices ‘visible’. As noted above, the production environment at EngineCo is shaped according to a particular just-in-time (JIT) production orthodoxy. Material is delivered to an external logistics provider that operates a high-shelf storage facility near the plant on EngineCo’s behalf. Upon EngineCo’s order, the logistics provider delivers parts to the plant. Consequently, the plant itself was not designed to store large numbers of parts, containing buffer spaces for only four hours of production. The layout of production is basically linear, with an engine picking up its component parts as it moves from one side of the plant to the other. The production of engines is divided into two main steps: the basic engine is produced on an assembly line while customer-specific configuration is done in stationary assembly workspaces. Central to production is the Assembly Control Host which controls all processes within the plant, interacting with local systems in the various functional units of the plant (e.g., assembly lines) as well as with the company’s ERP system (SAP R3). The Assembly Control Host is custom-built rather than being part of the ERP system. It has been developed and is now operated and maintained by an external IT service provider which has personnel located in the plant. A basic precondition for production to work along the lines of the JIT regime is that all parts are available in time for production. This notion of buildability is the key concept in the production management orthodoxy at EngineCo. Located within the plant, an assembly planning department is responsible for the buildability of engines, assuring that all component parts as well as the various pieces of information needed (such as workers’ instructions) are available before production starts. They are also responsible for scheduling production orders in time to meet the agreed delivery dates. Assembly planners create a schedule for

34

Alexander Voß et al.

production taking into consideration their knowledge about the current status of the plant, upcoming events and the requirements of control room workers.

Doing Dependability: Normal Natural Troubles Instances of undependability in this setting are quite frequent but are not normally catastrophic. Rather, they are ordinary, mundane events that occasion situated practical (as opposed to legal) inquiry and repair. This is in contrast to much of the extant literature which has focused on dependability issues as fatal issues, e.g. studies of such cases as the London Ambulance Service [1] or Therac25 [6]. The study points to some of the worldly contingencies that control room workers routinely deal with as a part of their planning and scheduling work. More precisely we might say that all plans are contingent on what, following Suchman [9], we call ‘situated actions’. Due to problems with the availability of certain parts, especially crankcases and because of ever increasing customer demands, the notion of buildability was renegotiated [10] in order not to let the plant fall idle. Today, there are ‘green’, ‘orange’, and ‘red’ engines in the plant that are respectively: strictly buildable, waiting for a part known to be on its way, or waiting for something that is not available and doesn’t have a delivery date. Control room workers effectively share responsibility for ensuring that engines are buildable with Assembly Planning as is illustrated by the following extract from the control room shiftbook: As soon as crankcases for 4-cylinders are available, schedule order number 56678651 (very urgent for Company X). Engines are red even when only loose material is missing.

The first example shows how control room workers effectively assign material to orders and how their decisions may be influenced by various contingencies. Choosing the order in which to schedule engines is a situated accomplishment rather than a straightforward priority based decision wherein the importance of the engine dictates its order. Control room workers need to attend to the way scheduling an engine might influence the ‘flow’ of other engines through the plant and take into consideration the workload a particular type of engine places on workers on the shop floor, i.e. they have to attend to the ‘working division of labour’ [8]. The second example refers to a problem with the IT systems which does not allow them to start production of engines which are missing loose material (e.g., manuals). Clearly, while a missing crankcase effectively prevents production of the engine, loose material is not needed until the engine is actually shipped to the customer (and perhaps not even then in very urgent cases). By redefining details of the working division of labour [8], EngineCo has effectively addressed a situation that was impossible to predict during the original planning of the plant. This is not to say that the notion of buildability has ceased to exist. Rather, the general notion as originally inscribed in working practices has, by appropriation, been localised to take into consideration the

Dependability as Ordinary Action

35

‘worldly contingencies’ – situations which arise in and as a part of the everyday practical work of the plant and its members and which are not, for example, involved with setting up a new system or introducing new machinery or practices – of production in EngineCo’s plant. Where, previously, buildability was a verifiable property of an engine in relationship to the inventory, now buildability of ‘orange’ and ‘red’ engines is an informed prediction based on members’ knowledge about various kinds of socio-material circumstances. In our research we have found a series of expectable, ‘normal’ or ‘ordinary’ troubles whose solution is readily available to members in, and as a part of, their working practices. That is, such problems do not normally occasion recourse to anything other than the ‘usual solutions’. Usual solutions invoke what we call horizons of tractability. By this we mean that a problem of the usual kind contains within it the candidate (used-before-and-seen-to-work) solution to that problem. These problems and their solutions are normal and natural and putatively soluble in, and as a part of, everyday work. From the shiftbook: SMR [suspended monorail] trouble 14:15 to 16:30, engines not registered into SMR, took 25 engines off the line using emergency organisation. Info for Peter: part no. 04767534, box was empty upon delivery, so I booked 64 parts out of the inventory.

The emergency organisation involved picking up the engines by forklift truck and moving them to a location where they can be picked up by the autonomous carrier system. A number of locations have been made available for this purpose where forklift truck drivers can access the Assembly Control Host to update the location information for the engine they just reintroduced into the system. This is one of many examples where non-automated activity leads to a temporary discrepancy between the representation and the represented, which has to be compensated for. The second example illustrates the same point. Updating the inventory in response to various kinds of events is a regular activity in the control room and the fact that control room workers have acquired authority to effect such transactions is witness to the normality of this kind of problem compensation activity. Workers are also able to assess the potential impacts of seen-before problem situations and they take measures to avoid them: From the shiftbook: Carrier control system broken down 10:45–11:05 resulting in delayed transports, peak number of transports in the system = 110 If in the carrier control system you can’t switch from the list of transport orders to the visualisation, don’t reboot the PC if the number of transport orders is more than about 70.

In the first two lines of the above example, workers report on problems with the system that controls the autonomous carriers that supply material to the workstations in the plant. The recording of a breakdown in the shiftbook is a way

36

Alexander Voß et al.

to make this incident accountable to fellow workers, including those working on another shift. The entry contains a number of statements which, on the surface, seem to be rather uninformative. However, they point to a number of normal, natural troubles that can result from this particular incident such as material being stored in places that are far from the workstations where it’s going to be needed. This will affect the length of transports for some time after the root problem has gone away. The result of this is that since transports take longer, more of them will queue up in the carrier control system. Such ‘ripple effects’ are quite common in this production context. In effect, because of the breakdown of the control system, the ‘transport situation’ might be considered problematic for quite a long time. The next extract can be read in this same kind of context as being part of the process of workers’ making sense of, and responding to the potential undependability of the carrier control system. It has become part of the local practice to avoid certain actions that might result in the breakdown of the carrier system if the ‘transport situation’ is regarded as problematic by control room workers: From a video recording of control room work: Pete: Hey, the carrier control is still not running properly. Let’s not run the optimisation, ok Steve? Steve: We didn’t run it this morning either, because we had 40 transports.

Other problems that are not susceptible to these remedies are also interesting to us in that they demand a solution – members cannot remain indifferent to their presence – but that solution is not a normal or usual one (by definition). In order to keep production running, members have to find and evaluate possible solutions quickly, taking into consideration the present situation, the resources presently available, as well as, ideally, any (possibly long-term and remote) consequences their activities might have: From fieldwork notes: A material storage tower went offline. Material could be moved out of the tower to the line but no messages to the Assembly Control Host were generated when boxes were emptied. Control room workers solved this problem by marking all material in the tower ‘faulty’ which resulted in new material being ordered from the logistics provider. This material was then supplied to the line using forklift trucks. [...] A material requirements planner called to ask why so many parts were suddenly ‘faulty’.

Such situated problem-solving results in work-arounds which are initially specific to the situation at hand but may become part of the repertoire of used-beforeand-seen-to-work candidate solutions. They may be further generalised through processes of social learning [12] as members share them with colleagues or they might get factored into the larger socio-material assemblage that makes up the working environment. This process of problem solution and social learning, however, is critically dependent on members’ orientation to the larger context, their making the problem solution accountable to fellow members and their ability to

Dependability as Ordinary Action

37

judge the consequences. The following fieldwork material illustrates how problem solutions can get factored into ongoing systems development as well as how they can adversely affect the success of the system: From an interview with one of the system developers responsible for the ongoing development of the Assembly Control Host: [Such a complex system] will alway have flaws somewhere but if the user has to work with the system and there’s a problem he will find a work-around himself and the whole system works. [...] The whole works, of course, only if the user really wants to work with it. If he says: “Look, I have to move this box from here to there and it doesn’t work. Crap system! I’ll let a forklift do this, I will not use your bloody system” then all is lost. Then our location information is wrong cause the driver doesn’t always give the correct information; then it will never fly. [... If they come to us and say] that something’s not working, we will say “oh! we’ll quickly have to create a bug fix” and, for the moment, I’ll do this manually without the system, then it works, the system moves on, everything stays correct, the whole plant works and if the next day we can introduce a bug fix the whole thing moves on smoothly.

The plans that members come up with within this horizon of tractability do not usually work one way only – it is our experience that an unexpected problem can become a normal problem susceptible to the usual solutions in, and through, the skillful and planful conduct of members. That is to say, the boundaries between the types of problem are semi-permeable (at least). The order of the potentially problematic universe is not similarly problematic for all members, different members will view different problems in a variety of ways and, through the phenomenon of organisational memory [5], this may lead to the resolution for the problem in, and through, the ability to improvise or to recognize some kind of similarities inherent in this and a previous problem. It is important to note that problem detection and solving is ‘lived work’ [7] and that it is also situated. That is, it is not to be divorced from the plans and procedures through which it is undertaken and the machinery and interactions that both support and realise it. Working practices and the structure of the workplace afford various kinds of activities that allow members to check the proper progress of production and to detect and respond to troubles. These very ‘mundane’ (i.e., everday) activities complement the planned-for, made-explicit and formalised measures such as testing. As in other collaborative work (see e.g., [2]), members are aware of, and orient to, the work of their colleagues. This is supported by the affordances of their socio-material working environment as the following example illustrates: From a video recording of control room work: Oil pipes are missing at the assembly line and Jim calls workers outside the control room to ask if they “have them lying around”. This is overheard by Mark who claims that: “Chris has them”. He subsequently calls Chris to confirm this: “Chris, did you take all the oil pipes that were at the line?” Having

38

Alexander Voß et al. confirmed that Chris has the oil pipes he explains why he thought that Chris had them: “I have seen the boxes standing there”.

Here, the visibility of situations and events within the plant leads to Mark being aware of where the parts in question are. The problem that the location of the parts was not accurately recorded in the information system was immediately compensated by his knowledge of the plant situation. Likewise, Jim’s knowledge of working practices leads him to call specific people who are likely to have the parts. Mark’s observation makes further telephone calls unnecessary2 . Video recording continued: Now that the whereabouts of the oil pipes has been established, the question remains why Chris has them. Mark explains that this was related to conversion work Chris is involved in at the moment. This leads Jim to ask if there are enough parts in stock to deal with the conversion work as well as other production orders. Mark explains how the inventory matches the need.

Having solved the problem of locating the parts, there is the question of how the problem emerged and what further problems may lie ahead. It is not immediately obvious that Chris should have the parts but Mark knows that Chris is involved in some conversion work resulting from a previous problem. Again, awareness of what is happening within the plant is crucial as information about the conversion work is unlikely to be captured in information systems as the work Chris is carrying out is not part of the normal operation of the plant. Rather, it is improvised work done to deal with a previous problem. Jim raises the question whether enough oil pipes are available to deal with the conversion work as well as normal production. Again, it is Mark who can fill in the required information and demonstrate to Jim how the parts in the inventory match the needs. As Jim comments in a similar situation: “What one of us doesn’t know, the other does.” Problem detection and solving is very much a collaborative activity depending on the situated and highly condensed exchange of information between members. By saying that Chris has taken the parts from the line, Mark also points to a set of possible reasons as members are well aware who Chris is, where he works and what his usual activities are. Video recording continued: Since it was first established that parts were missing, production has moved on and there is the question what to do with the engines that are missing oil pipes. Jim and Mark discuss if the material structure of the engine allows them to be assembled in ‘stationary assembly’.

Workers in the plant are aware of the material properties of the engines produced and are thus able to relate the material artefact presented to them to the process of its construction. In the example above, Mark and Jim discuss this relationship 2

Another example of the mutual monitoring that goes on in control rooms and similar facilities is to be found in [3]

Dependability as Ordinary Action

39

in order to find out if the problem of missing oil pipes can be dealt with in stationary assembly, i.e., after the engines have left the assembly line. They have to attend to such issues as the proper order in which parts can be assembled. The knowledge of the material properties of engines also allows members to detect troubles, i.e., the product itself affords checking of its proper progress through production (cf. [2]). From a video recording of control room work: Jack has ‘found’ an engine that, according to the IT system, has been delivered to the customer quite a while ago. It is, however, phyiscally present in the engine buffer and Jack calls a colleague in quality control to find out the reason for this. “It’s a 4-cylinder F200, ‘conversion [customer]’ it says here, a very old engine. The engine is missing parts, screws are loose, ... if it’s not ready yet – I wanted to know what’s with this engine – it’s been sitting in the buffer for quite a while.”

Here, the physical appearance is an indication of the engine’s unusual ‘biography’. This, together with the fact that the engine has “been sitting in the buffer for quite a while” makes the case interesting for Jack. These worldly contingencies are interesting for us since they invite consideration of the ‘seen but unnoticed’ aspects of work – that is, those aspects which pass the members by in, and as a part of, their everyday work but which, when there are problems or questions, are subject to inquiry (e.g., have you tried this or that? Did you do this or that? What were you doing when it happened). The answer to such questions, especially to the latter, illustrates the seen-butunnoticed character of work in that, when called upon to so do, members can provide such accounts, although they do not do so in the course of ordinary work.

3

Dependability as a Society Member’s Phenomenon

A central problem for us is the manner in which the term ‘dependability’ has been used in the ‘professional’ literature to be found at, for example, this conference. We argue that there is a need to complement this with a consideration of the ways in which dependability is realised as a practical matter by members and over time. This is not to say that we reject notions of dependability offered by this literature or that our comments here are incommensurable: the point is that we want to look at dependability and similar terms by doing an ethnography of what it means for a system to be reliable or dependable as a practical matter for society members engaged in using that system with just the resources and the knowledge they have. That is, we are interested in what it means to be dependable or reliable in context. In other words, while we are interested in the notions of dependability invoked in the ‘professional’ literature and these inform our discussions, we find that these definitions are dependability professionals’ objects as opposed to society members’ objects. We feel that we should consider how society members experience dependability in context, and that is what we

40

Alexander Voß et al.

present here. Indeed it is our contention that such lay uses are important for understanding what we could mean by ‘dependability’. Our aim here, then, is to bring forward the lay uses, the practical procedures and knowledges that are invoked in working with more or less dependable systems and to consider this alongside ‘professional’ uses of terms and the metrics that realise them. Think, for instance, of the phrase “Tom is very dependable” – we would not want to say qua lay member that we would want to have some kind of metric testing, for example, how many times Tom had arrived at the cinema at the time specified. We would say that such metrics are not something with which members have to deal – it would be unusual to state apropos of Tom’s dependability: “over the last month Tom has turned up on time in n% of cases, where ‘on time’ means +/– 10 minutes”. Such metrics treat dependability in a sense that we might consider outwith the bounds of everyday language. They are somewhat problematic for the purposes of needing to know if Tom will arrive before we go into the cinema. This is not to suggest that ‘professional’ metrics and definitions of dependability have no value but that their use in everyday language is limited. Our aim here, then, is to focus on what it means to live with more or less dependable systems and to do so in the natural attitude through ordinary language and situated actions such as repair. As for humans, for machines the notion of being dependable is an accountable matter3 . It is also a matter that might well occasion work arounds or other situated actions which we should consider when examining what we call the ‘logical grammar’ of dependability. By this we mean the ways that the concept might be used. Consider “this machine is totally undependable, let’s buy it” – such a use cannot be said to be acceptable except as an ironic utterance. Uses such as “you cannot always depend on the machine but we usually find ways of making it work” point us to the ways people treat notions such as dependability not simply as common understandings but as common understandings intimately related to practical actions. Our study of control room work shows that in a strict sense the system is not 100% reliable but in showing how members make it work, we aim to provide a complement to such metrics and to show the work of making systems dependable. This is also our reason for recommending that one do an ethnography since it is only by so doing that one might see the work arounds in action and come to know just how the system is unreliable or cannot be depended on. As practical matters, dependability is important for members; yet the senses in which members treat such terms seems to be of little consequence for those who write on dependability. We want to argue that if one does examine natural language uses of these terms (and others) the benefit will be in a fuller appreciation of what it means to work with (or around) such systems. Consideration of technology in its (social) context illuminates the practical actions that make technologies workable-with and which realise horizons of dependability as soci3

By this we point to as phenomenon which, if asked, members could give an account of, e.g., in the example given above, Tom might report that he is late because his bus was late. This is an account of his being late. We might then say the same of machines, that this or that job could not be done because the machine broke down.

Dependability as Ordinary Action

41

ety members’ objects. Such an exercise might appear as if it is trivial – playing with words – but we find value in it in that it shifts attention to how people cope with technology and away from metrics and measures that find their use in the technical realm but which have little value on the shop floor. They also show us something of the ‘missing what’ of making technologies reliable or dependable, the practical actions that occur, the work arounds, the procedures adopted and so on – the majority of which we would not expect to find in the literature. In other words, we want to present a consideration of the ways in which dependability is ad hoced into being. It is only by doing the ethnography that such features might be found. We might be seen as providing an outsider’s comment on something that has been professionalised and fine-tuned, yet we would argue that such issues are of merit to professionals and that they should be examined in considering what we mean by ‘dependability’ and that maybe the ethnography together with the consideration of such terms in natural language will, in Wittgenstein’s terms [13], be ‘therapeutic’. Therapeutic in the sense that it opens up some elbow room in which to do the kinds of ethnographic work that illustrates how knowledge is deployed within the working division of labour and how members in settings such as EngineCo treat knowledge as a practical resource for making more or less dependable systems work. This directs our attention to knowledge in and as part of practical action and we would argue forms a complement to the work currently being undertaken in the area of dependability.

4

Conclusions

It is important to us not to be seen as having resorted to some form of social constructivism since we believe that such approaches – with their faux na¨ıf insistence that things could have been otherwise if people had agreed – are at best unhelpful. Social constructivist approaches appear to us to locate their territories and then make claims that there is no ‘there’ there, so to speak, without agreement. We would not wish to be heard to endorse an approach that treats dependability as a contingent matter as ‘how you look at it’. Our approach is to regard these things as worldly achievements that require one to look at the practices that exist in and as part of their achievement. This is why we recommend ‘doing the ethnography’ to show what it means to live with systems that are more or less dependable. Through examination of the ‘lived work’ of working with undependable systems (including the work arounds etc. that this involves) we aim to complement existing work in this area. We also believe that a focus on the grammar of dependability is important – Wittgenstein’s insistence on inquiring into what we mean when we use terms such as ‘dependable’ further focuses our attention on the realisation of dependability as lived work.

42

Alexander Voß et al.

We propose that the study of dependability can only be enhanced and strengthened by attending to lay4 uses of the term and by focussing on the work that goes on to make systems more or less dependable. We do not argue that ethnographic studies or grammatical investigations should replace the work currently undertaken under the rubric of dependability, but that there is what we would call a ’missing how’ that needs to be addressed and that this can be done satisfactorily in and through ethnographic research on the procedures and situated actions involved in making systems dependable. There is also a sense in which the study of dependability can be developed through the securing of a deeper understanding of the practices by which it is constitued. Ethnographies of the making of dependability measures/metrics might be useful in that they afford those involved the opportunity to reflect on their practice. We have instantiated the need to ‘do the ethnography’ and to consider the manner in which a consideration of Wittgensteinian philosophy might assist in clarifying what we mean by dependability. We have provided examples from our own work on the realisation of dependability in the workplace, and shown how such practical actions such as work-arounds contribute to the notion of dependability. It must be kept in mind that dependability is a situated concept and that when one considers the constitution of dependable systems one must keep in mind the settings in which such systems are used and the accompanying work practices. When we look at, for example, the work of the engine plant system we find that the workers engage in a series of situated practical actions in order to have the system be reliable. That is to say, dependability is not simply an inherent property of the system itself but of the work in which it is enmeshed. We can therefore speak of the ‘lived work’ of dependability in that, having done the ethnography, we can see that there is a reflexive relationship between work practice and dependable systems. The aim of this paper has been to demonstrate not that ‘professional’ discourses of dependability have no place in our considerations, but that there is an important practical counterpart to these in lay notions of dependability and the work practice that goes on in and as a part of working with (un-)dependable systems. It is our recommendation that researchers consider this often neglected component when employing these concepts. In addition, we hope to have shown the essentially fragile nature of the JIT system and to have shown how the agility of the work practice, predicated on the autonomy accorded to plant workers, is necessary to keep the system running. The more or less dependable system that comprises the factory requires workers to be accorded autonomy in order to have things work. We have focused attention on the ways that this goes on and how reliability and dependability are practical outcomes of the deployment of knowledge by control room workers in an organisation whose production orthodoxy requires agility to repair its rather fragile nature and to make it work. 4

By ‘lay’ we do not suggest some impoverished version of a term but a necessary complement to the ‘professional’ uses to be found in the literature. Therefore, our use should be seen as a complement rather than an alternative.

Dependability as Ordinary Action

43

The research reported here is funded by the UK Engineering and Physical Sciences Research Council (award numbers 00304580 and GR/N 13999). We would like to thank staff at the case study organisation for their help and participation.

References [1] P. Beynon-Davies. Information systems failure and risk assessment: the case of the London Ambulance Service Computer Aided Despatch System. In European Conference on Information Systems, 1995. 34 [2] Mark Hartswood and Rob Procter. Design guidelines for deadling with breakdowns and repairs in collaborative work settings. International Journal of Human-Computer Studies, 53:91–120, 2000. 37, 39 [3] Christian Heath, Marina Jirotka, Paul Luff and John Hindmarsh. Unpacking collaboration: the interactional organisation of trading in a city dealing room. Journal of Computer Supported Cooperative Work 3, 1994, pages 147-165. 38 [4] John Hughes, Val King, Tom Rodden, Hans Andersen. The role of ethnography in interactive systems design. interactions, pages 56–65, April 1995. 33 [5] J. A. Hughes, J. O’Brien, M. Rouncefield. Organisational memory and CSCW: supporting the ‘Mavis’ phenomenon. Proceedings of OzCHI, 1996. 37 [6] Nancy Leveson and Clark S. Turner. An investigation of the Therac-25 accidents. IEEE Computer, 26(7):18-41, 1993. 34 [7] Eric Livingston. The Ethnomethodological Foundations of Mathematics. Routledge, Kegan, Paul, London, 1986. 32, 37 [8] Wes Sharrock, John A. Hughes. Ethnography in the Workplace: Remarks on its theoretical basis. TeamEthno-Online, Issue 1, November 2001. Available at http://www.teamethno-online.org/Issue1/Wes.html (accessed 14th Feb. 2002) 34 [9] Lucy A. Suchman. Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press, 1987. 34 [10] Alexander Voß, Rob Procter, Robin Williams. Innovation in Use: Interleaving day-to-day operation and systems development. PDC’2000 Proceedings of the Participatory Design Conference, T. Cherkasky, J. Greenbaum, P. Mambrey, J. K. Pors (eds.), pages 192–201, New York, 2000. 33, 34 [11] Alexander Voß, Rob Procter, Roger Slack, Mark Hartswood, Robin Williams. Production Management and Ordinary Action: an investigation of situated, resourceful action in production planning and control. Proceedings of the 20th UK Planning and Scheduling SIG Workshop, Edinburgh, Dec. 2001. 32 [12] Robin Williams, Roger Slack and James Stewart. Social Learning in Multimedia. Final Report of the EC Targeted Socio-Economic Research Project: 4141 PL 951003. Research Centre for Social Sciences, The University of Edinburgh, 2000. 36 [13] Ludwig Wittgenstein. Philosophical Investigations. Blackwell, Oxford 1953 (2001). 32, 41

Practical Solutions to Key Recovery Based on PKI in IP Security Yoon-Jung Rhee and Tai-Yun Kim Dept. of Computer Science & Engineering, Korea University Anam-dong Seungbuk-gu, Seoul, Korea {genuine,tykim}@netlab.korea.ac.kr

Abstract. IPSec is a security protocol suite that provides encryption and authentication services for IP messages at the network layer of the Internet. Key recovery has been the subject of a lot of discussion, of much controversy and of extensive research. Key recovery, however, might be needed at a corporate level, as a form of key management. The basic observation of the present paper is that cryptographic solutions that have been proposed so far completely ignore the communication context. We propose example to provide key recovery capability by adding key recovery information to an IP datagram. It is possible to take advantage of the communication environment in order to design key recovery protocols that are better suited and more efficient.

1

Introduction

Internet Protocol Security (IPSec) is a security protocol suite that provides encryption and authentication services for Internet Protocol (IP) messages at the network layer of the Internet [5,6,7,8]. Two major protocols of IPSec are the Authentication Header (AH) [7], which provides authentication and integrity protection, and the Encapsulating Security Payload (ESP) [8], which provides encryption as well as (optional) authentication and integrity protection of IP payloads. IPSec offers a number of advantages over other protocols being used or proposed for Internet security. Since it operates at the network layer, IPSec can be used to secure any protocol that can be encapsulated in IP, without any additional requirements. Moreover, IPSec can also be used to secure non-IP networks, such as Frame Relay, since operation of many parts of IPSec (E.g., ESP) do not necessarily require encapsulation in IP. Key recovery (KR) has been the subject of a lot of discussion, of much controversy and of extensive research, encouraged by the rapid development of worldwide networks such as the Internet. A large-scale public key infrastructure is required in order to manage signature keys and to allow secure encryption. However, a completely liberal use of cryptography is not completely accepted by governments and companies so that escrowing mechanisms need to be developed in order to fulfill current regulations. Because of the technical complexity of this problem, many rather S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 44-52, 2002.  Springer-Verlag Berlin Heidelberg 2002

Practical Solutions to Key Recovery Based on PKI in IP Security

45

unsatisfactory proposals have been published. Some of them are based on tamperresistant hardware, others make extensive use of trusted third parties. Furthermore, most of them notably increase the number of messages exchanged by the various parties, as well as the size of the communications. Based on these reasons, the widespread opinion of the research community, expressed in a technical report [13] written by well known experts, is that large-scale deployment of a key recovery system is still beyond the current competency of cryptography. Despite this fact, key recovery might be needed at a corporate level, as a form of key management. The basic observation of the present paper is that cryptographic solutions that have been proposed so far, completely ignore the communication context. Static systems are put forward for key recovery at IP layer in the Internet. This paper proposes a method for carrying byte oriented Key Recovery Information in a manner compatible with the IPSec architecture. We design a key recovery protocol that is connection oriented, interactive and more robust than other proposals.

2

Background on Key Recovery

In this section, we describe needs of key recovery and practical key recovery protocols compatible with Internet standards. The history of key recovery started in April 1993, with the proposal by the U.S government of the Escrow Encryption Standard [14], EES, also know as the CLIPPER project. Afterwards, many key recovery schemes have been proposed. To protect user privacy, the confidentiality of data is needed. For this, key recovery seems useless, but there are some scenarios where key recovery may be needed [15,16]: ! !

!

3

When the decryption key has been lost or the user is not present to provide the key Where commercial organizations want to monitor their encrypted traffic without alerting the communicating parties; to check that employees are not violating an organization’s policy, for example When a national government wants to decrypt intercepted data for the investigation of serious crimes or for national security reasons.

Related Protocols

On one hand the Internet Engineering Task Force (IETF) standardization effort has led to Internet Security Association and Key Management Protocol (ISAKMP) [5] and IPSec [7,8] for low layers of the ISO model for all protocols above the transport layer. Each of these protocols splits the security protocol into two phases. The first phase enables communicating peers to negotiate the security parameters of the association (encryption algorithm, Hashed Message Authentication Code (HMAC) [11,12] mechanisms, encryption mode), the session key, etc. Moreover this first phase

46

Yoon-Jung Rhee and Tai-Yun Kim

can be split again in an authentication stage and a negotiation stage but these results are an increase of the exchanges (from 3 to 6), which accordingly decreases the performances (the aggressive mode and main mode [4]). The second phase allows encryption of the transmitted messages by means of cryptographic algorithms defined in during the first phase and adds integrity and authentication services with HMAC methods. On the other hand, publications about key recovery systems come from the cryptography community: cryptographic primitives are used to design high-level mechanisms, which cannot fit easily into standards such as Requests for Comments RFCs. We have studied the Royal Holloway Protocol (RHP) [1] that comes from pure academic research in cryptography and the Key Recovery Alliance (KRA) Protocols. Both schemes are based on the encapsulation mechanism. Additional key recovery data are sent together with the encrypted message enabling the Key Escrow Agent (KEA) to recover the key. These data are included in a Key Recovery Field (KRF). Another possibility is to escrow partial or total information about the secret key such as in CLIPPER. However, this technique requires more cryptographic mechanisms to securely manage the escrowed key (threshold secret sharing, proactive systems, etc.). The main drawback of the first system is that the security relies on one single key owned by the Trusted Third Party (TTP) and that this key may be subject to attacks. The main problem raised by escrowing the user’s secret is the need to keep the key in a protected location. 3.1

RHP Encapsulation

The RHP architecture is based on a non-interactive mechanism with a single exchanged message and uses the Diffie-Hellman scheme. The RHP system allows messages sent to be decrypted using the user’s private receive key. Each user is registered with a TTP denoted TTPA for user A . The notations used in this.

A,B

The communicating peers

TTPA , TTPB p g

A ’s TTP, B ’s TTP

K (TTPA , TTPB ) K pr − s ( A) K pu − s ( A) K pr − r ( A) K pu −r ( A)

TTPA and TTPB an element shared between TTPA and TTPB a secret key shared between TTPA and TTPB A ’s private send key ( random value x , 1 < x < p − 1 ) a prime shared between

A ’s public send key ( g x mod p ) A ’s private receive key ( a , 1 < a < p − 1 , derived from A ’s name and K (TTPA , TTPB ) ) A ’s public receive key ( = g a mod p )

The following is the RHP protocol descriptions.

Practical Solutions to Key Recovery Based on PKI in IP Security

47

Fig. 1. RHP Protocol descriptions

1.

A obtains K pu − r ( B ) ,(= g b mod p ). TTPA can compute K pr − r ( B ) ,(= b ), from

2.

B ’s name and K (TTPA , TTPB ) . A derives a shared key, ( g b mod p ) x mod p = g xb mod p from K pr − s ( A) .

3.

This is the session key, or the encryption key for the session key A transmits K pu − s ( A) signed by TTPA and K pu −r ( B ) . This information serves

4.

both as a KRF and as means of distributing the shared key to B . Upon receipt, B verifies K pu − s ( A) from A ’s public send key and K pr − r ( B ) .

The main advantage of the RHP is to be robust in terms of basic interoperability. But, the drawback of the RHP is to mix key negotiation and key recovery. It is difficult to integrate this scheme inside the security protocols of the ISAKMP since the protocol has only one phase. Another drawback is that the KRF is sent once. In fact, this is a major disadvantage in the system since the session can be long and the KEA can miss the beginning. We refer to this difficulty as the session long-term problem. It is necessary to send the KRF more than once. However, the advantage of this system is to encrypt the session key with the shared key so that the security depends on the communicating peers and not on the TTP. But since the private receive keys depends on the TTP, this advantage disappears. Finally, this solution is hybrid between encapsulation and escrow mechanisms because the private send key is escrowed and the private receive key can be regenerated by both TTPs. 3.2

KRA Encapsulation

The KRA system proposes to encrypt the session key with the public key of the TTPs. Key Recovery Header (KRH) [9] is designed to provide a means of transmitting the KRF across the network so that they may be intercepted by an entity attempting to perform key recovery. The KRH carries keying information about the ESP security association. Therefore, KRH is used in conjunction with an ESP security association. In the ISAKMP, the use of the KRH can be negotiated in the same manner as other IPSec protocols (e.g., AH and ESP) [10]. Figure 1 shows IP packets with the KRH used with IPv4.

48

Yoon-Jung Rhee and Tai-Yun Kim

IP Header

KRH

ESP

Payload

(a) KRH used with ESP

IP Header

AH

KRH

ESP

Payload

(b) KRH used with AH and ESP Fig. 2. IP Packets with KRH in IPv4

Various schemes using this technique have been proposed such as TIS CKE (Commercial Key Escrow) [3], or IBM SKR (Secure Key recovery) [2]. The system is quite simple and allows many variations according to the cryptographic encryption schemes. This proposal separates the key recovery information and the key exchange. The system modularity is also compatible with the IETF recommendation. But, the KRF contains the encryption of the same key under a lot of TTP public key. Thus, the KRF can rapidly grow and one must take proper care against broadcast message attacks. The KRA solution is not necessary to sends a KRF in each IP packet inside the IPSec [9]. The intervals at which the initiator and responder send KRF are established independently [10]. But since the KRF size is big, the KRF cannot be included in the IP Header. So, it can be sent in the IPSec header that is a part of the IP packet data. This leads to decrease the bandwidth. The second drawback is to encrypt the session key under the TTP public key. Finally, this solution is not robust because if this key is compromised, the system collapses.

4

The Proposed Key Recovery for IPSec

In this section, we propose some key recovery solutions for IPSec, which improve on the previous protocols described in Section 3. The main problem with the RHP proposal is that the protocol is connectionlessoriented. Therefore, the protocol is not well suited to IPSec or ISAKMP that are connection-oriented and allow interactivity. The KRA’s proposal seems a better solution than the RHP. Still, the security of the session key depends on a fixed public key of TTPs for all communications. Our solution is based on IETF protocols in order to improve the security of the system, the network communication, and the interoperability for cross-certification. We can integrate modified RHP method in the IETF protocols (ISAKMP, IPSec) if we realize a real Diffie-Hellman key exchange such as in Oakley [4] in order to negotiate a shared key. After this first phase, the KRF is sent with the data. 4.1

Negotiation of Security Association for KRF

In phase 2 of ISAKMP, the negotiation for security association of key recovery arises. The proposed system allows session key sent to be encrypted by the communicating peers using Diffie-Hellman shared key between two peers and time stamp, and

Practical Solutions to Key Recovery Based on PKI in IP Security

49

decrypted by the communicating peers and their TTPs using the each user’s private keys. The notations used in our proposed protocol are shown below.

TT

a time stamp

K pr ( A)

A ’s private key. TTPA escrows it. ( x , 1 < x < p − 1 )

K pu ( A)

A ’s public key. ( g x mod p )

K DH ( A, B )

a Diffie-Hellman shared key between A and B . ( A : ( g y mod p ) x mod p = g xy mod p ,

B : ( g x mod p ) y mod p = g xy mod p ) K ek − sk ( A − > B )

an encryption key for the session key in case A is the initiator and B is the responder. ( f ( g xy mod p, TT ) , where f is a one-way function )

The following is the mechanism used in the proposed protocol.

Fig. 3. Negotiation of Security Association for KRF used in the Proposed Protocol

1.

A obtains K pu (B ) , generates TT , derives K DH ( A, B ) , and calculates K ek − sk ( A − > B ) . B obtains K pu ( A) and derives K DH ( A, B )

2.

A transmits {TT }K

DH ( A , B )

to

B.

3. Upon receipt, B calculates K ek − sk ( A − > B ) from {TT }K DH ( A , B ) . In the proposed protocol, we simplify RHP by reducing required keys. In the step 2, we can improve freshness of encryption key for the session key, K ek − sk ( A − > B ) , by generating different key every time using time stamp and one-way function, and reduce dependency of encryption key for the session key on TTPs. Consequently, this can be more robust than RHP because this reduces the influence affected by escrowing the private receive keys depends on the TTP in RHP.

50

4.2

Yoon-Jung Rhee and Tai-Yun Kim

Transmission of KRF

During the IPSec session, we send the KRF with the encrypted message as KRA does. The Following is our proposed KRH format. The KRH holds key recovery information for an ESP security association. The format of the KRH is shown in figure 2. 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

Next Header

Length

3 3 4 5 6 7 8 9 0 1

Reserved

Security Param eter Index (SPI)

Encrypted Tim e Stam p

KRF Length

Key Recovery Field (KRF), variable length

Validation Field type

Validation Field Length

Validation Field Value, variable length

Fig. 4. Key Recovery Header format

Next Header. 8 bits wide. Identifies the next payload after the Key Recovery Header. The values in this field are set of IP Protocol Numbers as defined in the most recent RFC from the Internet Assigned Numbers Authority (IANA) describing ‘Assigned Numbers’. Length. 8 bits wide. The length of the KRB in 32-bit words. Minimum value is 0 words, which is only used in the degenerate case of a ‘null’ key recovery mechanism. Security Parameters Index (SPI). A 32-bit pseudo-random value identifying the security association for this datagram. The SPI value 0 is reserved to indicate that ‘no security association exists’. Encrypted Time Stamp. The value of {TT } K DH ( A , B ) generated in phase 2 of ISAKMP. It needs to be transmitted with KRF because it is required when the corresponding TTP recovers KRF, but it is not escrowed to the TTP. Key Recovery Field Length. Number of 32-bit words in the Key Recovery Field. Key Recovery Field. The Key Recovery Data. It contains session key of current IPSec session encrypted by encryption key ( K ek − sk ( A − > B ) ) in ISAKMP. Validation Field Type. Identifies the technique used to generate the Validation Field.

Practical Solutions to Key Recovery Based on PKI in IP Security

51

Validation Field Length. Number of 32-bit words in the Validation Field Value. The Validation Field Length must be consistent with the Validation Field Type. Validation Field Value. The Validation Field Value is calculated over the entire KRH. The TTPs can recover the key as well as the user (execute a Diffe-Hellman operation) since they escrow the user’s private key and obtain Time stamp from KRH. Even if we keep the same secret key, a KRF must be sent, since the session key is not escrowed. Hence, the KRF is sent several times according to an accepted degradation bandwidth. We send the KRF in the IPSec packet as a part of IP packet. The KRF only depends upon a specific user. This allows sending the KRF in a single direction according the user’s policy. User A can choose to send (or not) the session key encrypted with his TTP’s public key and user B can do the same. This is an interesting feature compared to the RHP, since in the RHP scheme both TTP can decrypt all messages without communication with each other. 4.3

Comparison of Protocols

Our proposal is a mix of the modified RHP and the KRA solutions that combines the advantages of both systems. This scheme is based on an escrow mechanism. First, we keep the interoperability of the RHP, improve robustness comparing with RHP, and include it in the Internet Protocols. Secondly, the KRA solution is used but we encrypt the session key with a Time Stamp and a shared key by Diffie-Hellman key exchange between communicating users or user’s public key to gain robustness, not with the TTPs public keys. Therefore it can provide a method for carrying byte oriented Key Recovery Information in a manner compatible with the IPSec architecture. We compare existing protocols and our proposed protocol. In Table 1, we show the comparison between proposals of RHP, KRA and our proposed. Table 1. Comparison of protocols (O: high support

Compatibility with IETF

RHP

KRA

The Proposed

X

O

O

X

O

Robustness Reducing overhead of network

5

: low support X: not support)

O

Conclusion and Future Works

We propose example to provide key recovery capability by adding key recovery information to an IP datagram. It is possible to take advantage of the communication

52

Yoon-Jung Rhee and Tai-Yun Kim

environment in order to design key recovery protocols that are better suited and more efficient. We design a key recovery protocol that is suitable for connection oriented and more robust than RHP or KRA proposals by combining the advantages of the modified RHP and the KRA solutions. As future works, we plan for analysis and evaluation of performance of the mechamism. To progress, we apply this by modifying existing IPSec system for exact analysis results.

References 1.

2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

14. 15. 16.

N. Jefferies, C. Mitchell, and M. Walker, “A Proposed Architecture for Trusted Third Party Services”, in Cryptography: Policy and Algorithms, Proceedings: International Conference BrisAne, Lecture Notes In Computer Science, LNCS 1029, Springer-Verlag, 1995 R. Gennaro, P. Karger, S. Matyas, M. Peyravian, A. Roginsky, D. Safford, M. Zollett, and N. Zunic. Two-Phase Cryptography Key Recovery System. In computers & Security, Pages 481-506. Elsevier Sciences Ltd, 1997 D. M. Balenson, C. M. Ellison, S.B. Lipner and S. T. Walker, “A new Approach to Software Key Encryption”, Trusted Information Systems The Oakley Key Determination Protocol (RFC 2412) Internet Security Association and Key Management Protocol (ISAKMP) (RFC 2408) The Internet Key Exchange (IKE) (RFC 2409) IP Authentication Header (AH) (RFC 2402) IP Encapsulating Security Payload (ESP) (RFC 2406) T.Markham and C. Williams, Key Recovery Header for IPSEC, Computers & Security, 19, 2000, Elsevier Science D. Balenson and T. Markham, ISAKMP Key Recovery Extensions, Computers & Security, 19, 2000, Elsevier Science The Use of HMAC-MD5-96 within ESP and AH (RFC 2403) The Use of HMAC-SHA-1-96 whithin ESP and AH (RFC 2404) H. Abelson, R. Anderson, S. Bellovin, J. Benaloh, M. Blaze, W. Diffie, J. Gilmore, P.Neumann, R. Rivest, J. Schiller, and B. Schneirer. The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption. Technical report, 1997. Available from htt://www.crypto.com/key-study NIST, “Escrow Encryption Standard (EES)”, Federal Information Processing Standard Pubilication (FIPS PUB) 185, 1994 J. Nieto, D. Park, C. Boyd, and E. Dawson, “Key Recovery in Third Generation Wireless Communication Systems”, Public Key Cryptography-PKC2000, LNCS 1751, pp. 223-237, 2000 K. Rantos and C. Mitchell. “Key recovery in ASPeCT Authentication and Initialization of Payment protocol”, Proc. Of ACTS Mobile Summit, Sorrento, Italy, June 1999

Redundant Data Acquisition in a Distributed Security Compound Thomas Droste Institute of Computer Science Department of Electrical Engineering and Information Sciences Ruhr-University Bochum, 44801 Bochum, Germany [email protected]

Abstract. This paper introduces a new concept for an additional security mechanism which works on every host inside a local network. It is focussed on the used redundant data acquisition to get the complete net-wide network traffic for later analysis. The compound itself has a distributed structure. Different components act together on different hosts in the security compound. Therefore, the acquisition and analysis are done net-wide by hosts with free resources, parallel to their usual work. Because the hosts, in particular workstations, change dynamical over the day, the compound must adapt to the actual availability of all hosts. It must be guaranteed, that every transferred packet inside the local network is recorded. Each network traffic at one host in the network is recorded by a minimum of two others. The recorded traffic is combined at a node in order to get a single complete stream for analysis. The resulting problems at the different states of the redundant data acquisition are described and used solutions are presented.

1

Introduction

The distributed security compound is implemented on each host in the local network. It works parallel to other security mechanisms like firewalls, or intrusion detection systems (IDS) and intrusion response systems (IRS). The intention for the use is to get an additional security mechanism which works transparent on the established network and on different hosts. The achieved knowledge and analysis depends on the whole net-wide network traffic transferred inside a local network. A security violation or unusual behavior can then be detected in the whole network. An advantage is the use of usual workstations for the compound. No additional hardware is necessary. All functions and components are added to the existing host configuration. Different components for compound detection, network data acquisition, distributed analysis, compound communication, and reaction on security violations act together [3]. A basic component is the compound detection. The whole network is scanned for hosts which have to be integrated into the security compound. Hosts without the S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 53-60, 2002.  Springer-Verlag Berlin Heidelberg 2002

54

Thomas Droste

needed components are detected, too. Therefore, a new host in the network - a new own member or a possible intruder with physically access to the local network - will be identified as such a system. Each host can acquire the network traffic (see Sect. 2), which is used for the later analysis. The analysis of recorded and combined data is splitted and distributed to the compound members. The compound communication is possible among all components. Cryptographic mechanisms are required to encode the communication inside the compound and for the recorded and transferred data. If a local preanalysis process or a distributed analysis recognizes a security violation the reaction component will be activated. Therefore, an internal compromised host is decoupled from the compound and access from/to other hosts are districted. The local reaction component can e.g. shut down the host or log off the local user. All components of the security compound are working as services in the background, i.e. transparent for the local user. They start interacting before the user logs on and remain active all the time the system is up.

2

Acquisition of Network Traffic

The acquisition is realized parallel to the normal network traffic. The complete network traffic inside a collision domain dCD,i (i means number of collision domain) is recorded at the network adapter of a host. Contrary to host based traffic dr,i,j (j means host in collision domain i) all packets are recorded. One assumes that all hosts record the traffic, the resulting traffic in a collision domain is given by

d CD,i =

ni

∑ d r ,i , j .

(1)

j =1

The net-wide traffic dges to record is given by

d ges =

nCD

∑ d CD,i .

(2)

i =1

A recorded data d includes each transmitted frame on the link layer. The data for the higher layers, i.e. header and encapsulated data, are completely included [12]. Each frame is marked with a timestamp. After recording the data, a transformation is done by adding the MAC1 address of the recording host and conversion into a readable packet order (layers are dissolved) for the combining process and the later analysis. This disintegration is done max. up to transport layer. Begin of a converted frame [11]: date;time;mac_source;mac_dest;mac_host;frame_type;... Parallel to the dissolved data dr´ the original frames dr´´ are stored for later requests from analysis processes. 1

Medium access control, the hardware address of the network interface [13].

Redundant Data Acquisition in a Distributed Security Compound

55

The traffic in a collision domain dCD can be recorded at any point inside this physically combined network. Therefore, each host inside the collision domain can record this traffic. A problem is the acquisition in switched networks. There, the traffic is controlled by the switch. Every packet is transferred directly to the station(s) at the corresponding port behind. Other stations can not recognize the traffic. If only one host is connected to a port, it will act as a single collision domain (ni=1). The recorded data at the host dr,i,1 is equal to dCD,i. A detection of hosts which are not part of the compound is still possible because of the administrative traffic (e.g. DNS2-queries). It does not depend on the topology (e.g.. ethernet 10Base-2/10Base-T with CSMA/CD3 or switched network). As soon as communication takes place to any compound member, this host is detected.

3

Generation of Redundancy

For the analysis, it is important to have a maximum of information about the network traffic. To combine the traffic from each host dr´ a filtering of duplicated packets is necessary. The result is the net-wide network data dcombine, given by

d combine = ∪k =1 d r ,k ´, nk = ∑i CD ni nk

n

(3)

nk is the number of hosts in the compound, including all hosts ni in each collision domains nCD. The redundancy degree increases with the number of the compound members. Therefore, it is not necessary to record the complete traffic at all hosts. A reduction from this high redundant level to a smaller one is forced. This is done by distribution of acquiring rules. Each compound member j gets a list of two or more other hosts to monitor (scalable). A recorded traffic dr,j (see Sect. 2) is filtered with the list. Now, the resulting output dr,j´ depends only on the traffic of the hosts in the list (and the own one). A rough estimation of the relation between number of hosts and recorded data is given in Table 1. Table 1. Dependency for recorded and combined data for a special host j

2 3

Number of hosts

Recorded data

low (ni≤3)

dr,j´=dges´

medium (3
dr,j´< dges´

high (ni>15)

dr,j´<< dges´

Combined data

Domain name system [10]. Carrier-sense multiple access with collision detection [13].

d r, j

=1 d combine d r, j 3 ≈ d combine ni d r, j d combine

≈

1 3 " ni ni

56

Thomas Droste

The mentioned relation depends on the traffic, due to the addressing of packets. Three groups are possible: communication between a host and his recording partner, communication inside the network or net-wide requests (see Sect. 2, administration traffic), and communication between an internal and external host (outside the local network, e.g. to the internet). A resulting traffic can not be predicted. It depends on the real network traffic. 3.1

Lost of Packets

The transparent work of the active components is a problem. The goal is to use the distributed compound parallel to the usual work of the local user. Depending on the host (processor speed, actual system load) packets can be lost. This problem occurs if a large data stream is transferred and the system is not able to save the packets on the local hard disk. An example is a transfer of a large file (i.e. in single packets). It can be sent to another system or be received by a host. While sending the file dr,send, the own host (sender) and the hosts monitoring it, acquire dr,send and must store all transferred packets. The sender stores the file in a network record dr,receive. The write process itself is the bottle-neck. The sending and reception are independent. The buffer of the network card is not fast enough to store the complete data (dr,receive≤dr,send). For the monitoring hosts, the problem occurs if the local system load is high or an additional network transfer is in progress. While receiving a file, the host (receiver) and the monitoring hosts also have that latter problem. To solve this problem the network acquire can be adapted. Thus, not the complete frame is progressed. Only the beginning of the frame dr,1..b (a defined number b of bytes) is recorded and stored. This part has all necessary information to extract the used protocols (dr,1..b→dr´). It is done by a coupling to the system load. For the analysis of the communication, the complete data (here the file) is not required for the analysis. Only if data on the application layer is needed it must be recorded or available for recording. E.g. virus scans should proceeded before a transmission starts on the local host or at a central point in case of a connection to an external system. Missing packets of a large transfer are of lower priority, if the content itself is irrelevant. Packets not belonging to the large transfer must be recorded. This is done by the above mentioned reduction of the frame size to acquire. The redundancy is still given. 3.2

Dynamic Update

A second reason for the use of different sources is the availability of hosts. If a host is temporary not reachable or useable due to extreme high system load, system compromising, hardware problems or network errors, the network traffic must be acquired by other hosts. The redundancy for all hosts must be recreated to a minimum factor of two. Building redundancy is delegated basing on the compound detection. The remaining systems are advised to monitor new hosts by random. At least each host is monitored by a minimum of two compound members.

Redundant Data Acquisition in a Distributed Security Compound

57

In case of a network error, e.g. a connection between sub-networks is broken, independent compounds will be established. After remigration of networks the compound will be recombined and a new random association for monitoring is done. Additionally, an update of the association is done periodically and in case a host joins the compound or is shut down. 3.3

Trusted Relationship

A trust degree is used to include the relationship among the hosts, i.e. which host is allowed to monitor another. This trust level is given in the host configuration. Basing on this value, hosts with the same trust level build a group. Increasing the trust level (↑,>0) results in a lowering of confidential (↓). Only hosts on the same trust level monitor each other to guarantee redundancy. If there are too few hosts in a group (i.e. minimum redundancy of two) hosts from the next lower trust level (higher confidential) take over the monitoring. Table 2. Hosts Rl,j (trust level l, host number j) in a compound associated with trust levels

Trust level

Host R

0

0.1

1

1.1

2

2.1

3

R R

R 0.2 1.2

R

3.1

R

R 0.3

R 0.4

R

1.3

R 3.2

An example of a small compound is given in Table 2. 3

2

1

0

R0.1

R0.4

R1.1

R0.2

R0.3

R1.2

R1.3

Trust level

R2.1

R3.1

R3.2

Fig. 1. Result of associated hosts based on Table 2

58

Thomas Droste

The group of trust level 1 monitors trust level 2 and two compound members in trust level 3 are monitored by the host in trust level 2 (Fig. 1 shows an example), this is done to guarantee the redundancy. The shown example presents only one simple case of a possible association. With each new update of the association (see Sect. 3.2) a new result is randomly forced [7]. For a larger number of hosts per trust level, it is not necessary that lower trust levels monitor higher. Therefore, the groups are independent from each other. To increase the redundancy factor, one host can be monitored by a larger number.

4

Combining Acquired Data

To use the redundancy of the recorded data the single host data dr,j´ is combined at a node to dcombine (see equation 3). The combination process checks every packet for equality with packets from the other hosts dr,j. The result is one single packet stream without redundant packets [5].

dr,1´ t11

dr,2´

dr,3´

dcombine tsync

t21

t31

tsync=t11, ∆t11=0 ∆t21=tsync-t21 ∆t31=tsync-t31

t12

∆t12=∆t11

t22

∆t12=tsync-t12

∆t22=∆t21

t32

∆t32=∆t31 ∆t32=tsync-t32

Fig. 2. Process of combination of (parted) data dr,j´ (j = 1..3) to dcombine with time synchronization

Fig. 2 shows a combination process with synchronization. Here, the data of three hosts are available. The timestamp t11 of the recorded data of host 1 dr,1 is the lowest

Redundant Data Acquisition in a Distributed Security Compound

59

and is used as time base. Beginning with the first packet of host 1 (in dr,1) the synchronization time tsync for the combined data dcombine is set to this time. The later data (from dr,2 and dr,3) are sorted into this time line. A synchronization between an input data for combination (dr,j) and the combined data (dcombine) is done when the first identical packets occur. In the figure the synchronization is shown indirectly by the lines between the combined data and two input data. Each time a new (additional, following) input data from a host is used, a new synchronisation must be done. The former time difference in relation to the combined data is used until a packet for synchronising is available. The combination and sorting process for one single packet can be done in less than 1 ms (on an actual system assembled for usual work). Recorded data of 10.000 packets have a size of 1.5 Mbyte (about 160 byte a packet).

5

Summary & Outlook

The acquisition of data is one step in the security compound. Redundancy is important to guarantee the availability of correct data for analysis [8]. The distributed structure helps but produces a lot of problems [6][14], some shown in this article. The main goal is to have a security compound in the background parallel to usual user work. With this improved security the safety will be increased, too. All components and resources can be observed by adapting the mechanisms of the compound to safety requirements. The implementation of the mechanisms for acquisition and combining data are parted. The acquisition is done by a packet driver with an additional specialized service. Depending on the local system and network load some packets may get lost in a single system. This is compensated by the other systems. The dynamic update is done by an extra service, which adapts to the actually available hosts. Test series verified the implementation. The combining process resulted in correct acquired traffic for each series of measurement. Only at the beginning of combined traffic, gaps occurred in the time line. A more exact synchronization among all hosts solved this problem. For further use, an optimization is necessary to speed up the combining process. With the acquired and combined data the analysis of the traffic can start. Examples are pattern recognition to known attacks (e.g. port scan), anomaly detection (like IDS do) or other forms of analysis. A main advantage is the possibility to have a compound in case the network is parted (malfunction of couple elements). A new security compound is established by the dynamically detection in single network parts. Furthermore, the availability of the complete net-wide network traffic for the analysis is a factor other security systems can not use. The distributed analysis inside the compound needs no additional hardware and is faster (and especially safe due the distributed structure) than an implementation on a single system.

6 1.

References Chapman, D.B., Zwicky, E.D.: Building Internet Firewalls. O´Reilly & Associates Inc. (1995)

60

2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

12. 13. 14.

Thomas Droste

Droste, T.: Data Exchange via Multiple Connections. 4th International Conference on Telecommunications in Modern Satellite, Cable and Broadcasting Services, TELSIKS´99. University of Niš (1999) Proceedings of Papers, vol 1 Droste, T: Sicherheitsdienste in einem Rechnerverbund. In: Horster, P.: Kommunikationssicherheit im Zeichen des Internet. Vieweg & Sohn, Braunschweig (2001) 1-12 Droste, T.: Weighted Communication in a Security Compound. 5th International Conference on Telecommunications in Modern Satellite, Cable and Broadcasting Services, TELSIKS´01. University of Niš (2001) Proceedings of Papers, vol 2 Droste, T., Ruhl, A.: Aufgaben bei verteilter Datenakquisition und dessen Zusammenführung für die Analyse. In: Horster, P.: Enterprise Security. ITVerlag (2002) Droste, T., Vogel, M.: Richtlinien für eine verteilte Sicherheitsinfrastruktur. In: Horster, P.: Enterprise Security. IT-Verlag (2002) Hamburg, D.: Entwurf von Rotationsmechanismen zur verteilten Datenakquisition. Studienarbeit S292, Institute of Computer Science. RuhrUniversity Bochum (2002) Höper, K.: Analyse eines verteilten Datenstroms auf Vollständigkeit. Studienarbeit S293, Institute of Computer Science. Ruhr-University Bochum (2002) Hunt, C.: TCP/IP Network Administration. O´Reilly & Associates Inc., Sebastopol (1994) Naugle, M.G.: Network Protocol Handbook. McGraw-Hill series on computer communication. McGraw-Hill, New York (1994) Schüppel, V.: Entwicklung einer Client-/Server-Applikation zum Informationsaustausch von Systemdaten zwischen entfernten Systemen.. Diplomarbeit D341, Institute of Computer Science. Ruhr-University Bochum (1999) Stevens, W.R.: TCP/IP Illustrated, Volume 1. Addison-Wesley Publ. Company, Reading (1994) Taylor, E.: The McGraw-Hill Internetworking Handbook. McGraw-Hill Inc., New York (1994) Vogel, M.: Entwicklung, Analyse und Definition von Richtlinien für eine verteilte Sicherheitsinfrastruktur. Diplomarbeit D363, Institute of Computer Science. Ruhr-University Bochum (2002)

Survivability Strategy for a Security Critical Process Ferdinand J. Dafelmair TÜV Süddeutschland Westendstrasse 199, 80686 München [email protected] Phone: +49-89-5791-1464 Fax: +49-89-5791-2902

Abstract. Security critical processes in the context of this paper are considered information technology processes that are implemented to achieve a high level of integrity, authenticity and confidentiality of data processing. It’s a matter of fact that high-level security may only be achieved through adequate physical protection. The classical approach is to close away such processes in computing centers protected by physical barriers with high drag factors – well known to cause substantial investment and operational costs. This paper describes a new, recently patented method to protect such a security critical process by different means – not to keep the attacker out but to take the valuables out when the attacker comes in. Practical application of this strategy is detailed giving an example of protecting a Trust Center of a Public Key Infrastructure by such means.

1

Introduction

The operation process of a Trust Center (TC) as heart of a Public Key Infrastructure (PKI) is a typical security critical process. A high-level TC contains at least facilities for Key Generation (KG), where user keys may be generated under well known conditions, a Certification Authority (CA), which issues digital certificates that state relationship between key owner and key and a system that takes care that both the user keys, and the certificates are written to e.g. smart cards as a personal security environment for the PKI user. Additional systems to be protected inside a TC might be the Online Certificate Status Verification Service (OCSP) and the Timestamp Service (TS). These systems use master-keys to digitally sign certificates or sign authoritative answers (OCSP and TS). Therefore a TC usually contains IT-systems for the various services, equipped with special cryptographic processing modules and some kind of machinery that handles the personalization of smart cards, meaning a sub-process where blank cards receive personal data for the PKI user. The smart card may be considered a small data safe by itself protecting the data written to it. Some major security goals of such a TC may be summarized as follows:

S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 61-69, 2002.  Springer-Verlag Berlin Heidelberg 2002

62

Ferdinand J. Dafelmair

SG1: the master-keys1 must remain confidential under any circumstances SG2: key generation of user keys must remain confidential under any circumstances2 SG3: the master-keys may not be replaced by any means SG4: the personalization process of smart cards may not be tampered with

-

From a PKI point of view several more security goals have to be considered but the simplified view is enough to explain the survivability strategy this paper focuses on.

Fig. 1. The main components of the Trust Center Module

2

Logical Protection Substitutes Physical Barriers

The TC processes need careful protection – both information technology protection of data communication and physical protection against tampering with the hardware the processes run on. Physical barriers are the classical mean to avoid attackers tampering 1 2

Those of the CA as well as those of eventually installed OCSP and TS Several ways of key generation are possible, either on smart card or externally with special cryptographic hardware. To avoid any kind of tampering, even key generation on smart card should be done inside secure environment.

Survivability Strategy for a Security Critical Process

63

with the processes run inside the TC behind the barriers. The drag factor of such barriers varies and so do costs. If protection against attackers with a high degree of determination as well as sophisticated equipment is necessary, costs increase dramatically and exceed the costs for information technology protection substantially. To achieve the security goals mentioned above the following alternative strategy may be used [1]: The security critical processes inside the TC are locked away behind lightweight physical barriers that comprise a compact module – the so called Trust Center Module (TCM). The module includes all IT-systems as well as the Smart card Personalization Equipment (CPE) including the Smart card Personalization Machine (CPM). Data that needs to be stored inside the TC for reference or logging is signed and encrypted through auxiliary data signing and enciphering keys. The module is closed during operation and deserted. Blank smart cards are automatically fed into the module through a transport mechanism and automatically returned in personalized form. Full information technology protection is achieved by e.g. firewalls systems and network intrusion detection systems. Figure 1 shows the main components of the TC module. The drag factor of the physical barrier is kept low but sufficiently high to ensure, that enough reaction time remains in case of physical attacks. Typically 1-2 minutes are enough time for reaction. The reaction itself consists of the following steps: -

Forced deletion of the master keys Shutdown of the CA and all other systems that require master keys Invalidation of smart cards currently in the CPM and deactivation of CPM Forced deletion of auxiliary data signing and enciphering keys

This 4 steps of reaction make sure, that the security goals SG1-SG4 are met in case of such physical attacks. The next question is what kind of attacks are considered and how they are detected.

3

Detection – The Basis for Proper Reaction

Physical attacks need to be differentiated into the following two categories: Cat1: Attacks that leave the physical enclosure of the process intact and only try to gain information from electromagnetic emission. Cat2: Attacks that penetrate the physical enclosure to insert probes or tools into the interior or achieve human access. Cat1 Attacks are rendered useless through sophisticated shielding using highly permeable metal and filters for decoupling lines. Cat2 attacks however need to be detected with a high level of reliability. Any deficiency in detection directly questions achievement of the security goals. Therefore diverse basic physical effects are used to detect Cat 2 attacks. Each of the physical criteria that are used to determine Cat 2 attacks are focussed on detection of any kind of enclosure penetration, from laser drilled 10 mils hole up to opening the door. Figure 2 shows, how the walls of the enclosure, including door, floor and top is built to facilitate this detection.

64

Ferdinand J. Dafelmair

The wall consists of a hollow space between an inner and outer alluminum plate which is kept at a low pressure level of around 15 mbar abs. A patented shielding and detection plate (SDP) is located in the middle of the hollow space. The SDP forms a condensor with one electrode grounded and the other at a voltage of 1.5 kV. If the outer plate of the wall gets penetrated, the pressure level in the hollow space increases due to inflowing air. This increase is detected and it is the first criteria for a Cat 2 attack. To successfully penetrate the wall, the SDP, must be penetrated which affects the dielectric of the SDP. Dielectric defects of the SDP cause a discharging current that is the second criteria for a Cat 2 attack. Finally position sensors at the door register any door movement and thus provide the third criteria for a Cat 2 attack. Any of the criteria are measured using 3 redundant sensors. Due to the sophisticated detection technology any kind of attempt to physically penetrate the enclosure gets registered and triggers proper reaction of the internal Security Control System (SCS).

4

Safety Design for Dependable Operation

The Security Control System (SCS) of the TCM is responsible for detecting attacks and carry out the proper reaction to fulfill the security goals. The design of the SCS follows proven design principles from the safety domain. The entire system is comprised out of 3 independent programmable logic controllers (PLC) interconnected to each other to form a 2-out-of-3 system. Such a system fulfills the single failure criterion making sure that despite a single failure in one of the PLCs the functions are still carried out with the high accuracy of a redundant system. Thus the design achieves both, reliability and fail-safe operation, because in case of no 2 PLCs remaining that agree on actions to be taken, the predefined safe state will be enforced by voting safety-relay logic. Data acquisition peripherals as well as the sensors follow this three-train architecture. Once an attack is detected or the SCS is forced into safe state, the relay contacts of the voting logic switch of the key stores for the master keys and the auxiliary data signing and enciphering keys. At the same moment the corresponding systems get a signal that initiates a shutdown of these systems and after a configurable delay time, the power of the systems gets interrupted and the CPM gets blocked. To withstand a total loss of power, the TCM has an internal emergency backup power supply that ensures enough power to achieve a controlled shutdown. In case of total power loss uncontrolled shutdown will take place which still does not violate any of the security goals since keys are solely kept in key storage environments based on voltile memory technology that immediately loose theis information in case of power loss. Important logging information is additionally printed inside the module on nonforgeable paper such that total loss of power does not jeopardize the required traceability of actions. Besides detection of attacks the SCS is in charge of carrying out instrumentation and control functions. These include startup- and ordinary shutdown control, temperature

Survivability Strategy for a Security Critical Process

65

and heat removal control, leakage detection of the water driven heat removal system, and supervision functions for various other parameters. Furthermore the SCS controls logging of security critical and operational events.

5

Closed Automation Provides against Tampering

One major source of security problems is associated with reliability of operational staff. Out of an efficiency point of view it may not be feasible to guarantee continuous mutual supervision of two individual operators according to the 4-eyes principle. Therefore security critical processes and related manufacturing equipment should be designed such that interaction between the operational staff and the equipment is limited to only those actions absolutely and inherently necessary for carrying out the operators tasks. Regarding this principle the smart card personalization machine inside the TCM, where the critical process of smart card personalization takes place, is also located entirely inside the TCM with only a card feeder for blank card input and a card outlet is accessible to the operator. Smart card transport and contacting is closed away inside the TCM and the smart card personalization machine is designed such that long values of Mean Time Between Failure (MTBF) are achieved. This was made possible trough using air flow and gravity as driving force for card movement thus avoiding smart card transportation by contact and limiting moving parts to the absolute minimum. Therefore service may be reduced to once in a year. This high reliable automation in a closed environment is a prerequisite for the implementation of the whole survivability strategy of the TCM since it relies on long term unattended operation of the internal TCM systems since any opening of the door leads to a shutdown of the entire system. Without necessity to allow human interaction at all with systems inside TCM during operation of the TCM, implementation of access control is quite straightforward. There is no differentiation between roles and any normal access is logged using the attack detection systems already explained. Despite there is no way to tamper with the critical processes or the systems they run on, it is crucial to verify the integrity both in hard and software for all the systems inside the TCM before closing the door and starting operation. For practical reasons it is advisable to restrict access to the TCM through some simple methods like a conventional door lock or closed room to provide against disruption of availability. Furthermore it’s good practice to feed integrity status warning messages of the TCM into the facility management system and make sure that proper actions are taken.

6

Verifiable Logging – Proof of Correct Operation

Following a survivability strategy of sensing and active reaction instead of passive protection it is crucial to furnish proofs of correct operation. This is done by different

66

Ferdinand J. Dafelmair

forms of logging. The IT-systems of the PKI3, which are the actual payload of the TCM environment do their own logging. The details of this logging are not to be considered here but it is necessary to mention that these logs are serialized, signed and eventually encrypted to ensure proper level of confidentiality and traceable integrity authenticity and non repudiation. These tamper-protected logs are stored inside the TCM and they are replicated through communication lines to external locations. Logging may be verified at any time by checking their signatures. Logs that document correct operation of the SCS cannot be implemented this way because PLCs can’t carry out cryptographic operations. To avoid additional auxiliary logging systems that introduce new complexity and need to be at least redundant the following method may be used to furnish proof of correct operation. As mentioned before, the TCM is vulnerable only in the shutdown state with door open. As with any other security approach, there need to be finally human beings to take over responsibility for correct operations. In the case of the TCM they are called Security Officers (SO) and there are at least three of them. They act under mutual supervision and they are forced by design to act by mutual consent. They start the TCM operation by verifying the integrity of the installed systems using several auxiliary technologies. During the first system startup of the TCM the also generate the master keys and the auxiliary signing and encryption keys inside the TCM on non forgeable hardware. Now the system is ready for use. To gain verifiable proof of the TCM system integrity over the entire period of operation, the Security officers load serialized paper into redundant printers connected to the PLCs. The serial numbers of the papers are recorded, signed and stored in a safe location. They then trigger the PLC to carry out an integrity self check and record the result together with a timestamp as a first item to the serialized paper. Then they close the door which automatically starts penetration detection. This and all following major incidents are logged by the printers. Next time the TCM is regularly the printers indicate the history of operation. Serialization of printer paper provides against printout counterfeit and redundant printouts level single output failures.

7

Comprehensive MMI Supports Operational Security

As security is not just a matter of dealing with deliberate attacks or technical failures but also with human errors, Operator Interface needs to be paid attention to. As already stated above, human interaction with the security critical process is exactly tailored to the operational task. The complex processing inside the TCM needs a human interface that hides complexity and provides robust and self explaining controls. To solve this problem experience from industrial automation and process control determined the design. It features an industrial Touch Panel for controlling the smart card personalization machine with animated state visualization and a browser based production control system. 3

E.g. The Certification Authority, the Card Personalization Equipment, the Timestamp System and the OCSP System

Survivability Strategy for a Security Critical Process

67

The operator has the sole task of personalization blank smart cards for a lot of already registered users. Therefore a tailored production control system provides him with a list of lots to be processed and some additional information necessary for packaging and delivering of the production. The operator cannot influence any data written to the smart cards nor can he personalize smart cards not already registered. The interface supports atomic transaction processing avoiding unknown intermediate processing states of user entries or lots to be processed. The operator receives visual guidance including animated process visualization that lets him monitor the processing inside the smart card personalization machine even from the browser interface.

8

Three Steps to Survive the Attack

Up to now the explanation of the approach focussed on the detection of attacks, reaching a safe shutdown state, proving correct operation and avoid human errors. The question still has to be solved how survivability is achieved and how the system will regain operational state once it was brought to a shut down. To really survive the attack three principles had to be implemented: Trustworthy Key Backup: The master-keys are the main target of an attack and in order to avoid that an attacker could get access to them, they are destroyed immediately after an attempt of attack has been detected. The security officers however, who act on mutual supervision and act by mutual consent and who initially created the master keys and auxiliary signing and encryption keys using special key management functionality based on cryptographic hardware control the security of the entire system and therefore have the power to recreate deleted keys. To accomplish this, the security officers have the possibility to create a backup of the keys. The design of the built in key management allows them to split the keys and export them to personal smart cards of security officers such that a single security officer only has control over a fraction of the key. Multiple exports are possible to ensure sufficient backup availability. Backups are secured by means of conventional safe storing. Trustworthy Key Restoration The key management functionality also provides the reverse process of restoration of the keys such that security officers may recombine the original keys out of their fractions but only if they act on mutual consent. After key restoration, the system is in the same and fully operational state than originally after the initial key generation during first startup. Trustworthy Cryptography The operation of TC processes as well as many other security critical processes relies on data that must survive attacks and which can vary in size up to quite substantial amounts. To secure such data trustworthy cryptography is applied. The security officers create auxiliary data signing and encryption keys that are treated like master

68

Ferdinand J. Dafelmair

keys. This keys are used to sign and optionally encrypt such data whenever they are created during normal operation. After this the data get replicated to one or more storage locations outside the TCM such that dislocation ensures adequate availability of data. Further protection of this exported data is not required since the data is only accessible through the auxiliary data signing and encryption keys which are kept under non disclosure inside the TCM. In case of attacks that lead to destruction of part of the TCM or data within it, it is still possible to recover data on a second TCM system. The example shows that this new survivability strategy also has to rely on backup strategies in case of disastrous events as well as classical approaches have to do this. The major advantage however is the cost of the backup, which is again only a fraction of the cost of a classical solution.

9

Commercial Aspects

Compared to classical security environments for TCs based on physical barriers with high drag factors, the new approach based on the TCM leads towards substantial cost reduction as follows: • • • • •

Space requirements for TCM compared to classical solutions based on high security computing centers are much lower Construction costs for a TCM are only a fraction of those of a high security computing center Operation costs are extremely low due to automation with only limited requirements for auxiliary operational staff Full Backup solutions require much less investment than with classical solutions Due to deserted operation no trusted staff with security clearance is required for operation

The modular design of the TCM solution allows furthermore extended operation periods that are similar to those of process industry installations and cover at least 10 years because all IT-systems with much shorter innovation cycles may be easily substituted.

10

Conclusion

This paper gave an example on how consequent application of cryptographic technologies has the potential to change traditional paradigms of how to achieve survivability for security critical processes. The principle is for sure not applicable to every security critical process but it shows, how costs can be brought down for such important and fundamental security technologies like a public key infrastructure. Companies that shrank from investing huge amounts into conventional trust center solutions for their own PKI now have a chance to get an adequate solution at a fraction of the costs. They might think even more about how this survivability

Survivability Strategy for a Security Critical Process

69

approach may be extended to other fields of company wide information processing like digital archiving - always keeping in mind the basic principle “If you can’t keep the enemy out, let him in and laugh at him”

References 1. 2.

Deutsches Patent und Markenamt, Patentschrift DE 199 15 668 A1, H04L9/10 Trust-Center-Einheit Deutsches Patent und Markenamt, Patentschrift DE 199 21 170 C2, H04L9/10, Sicherheitselement

Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms for Reliability and Safety Evaluation Klaus Heidtmann Departement of Computer Science, Hamburg University Vogt-Kölln-Str. 30, D-22527 Hamburg, Germany [email protected]

Abstract. The evaluation of system reliability and safety is important for the design of new systems and the improvement or further development of existing systems. Especially the probability that a systems operates (safely) using the probabilities that its components operate is a vital system characteristic and its computation is a nontrivial task. The most often used method to solve this problem is to derive disjoint events from the description of the system structure and to sum up the probabilities of these disjoint events to quantify system reliability or safety. To compute disjoint products as logical representation of disjoint events Abraham's algorithm inverts single variables indicating the state of a component and therefor produces a huge number of disjoint products. To avoid this disadvantage Heidtmann developed a new method which inverts multiple variables at once and results in a much smaller number of disjoint products as confirmed by some examples. This paper quantifies this advantage by statistical methods and statistical characteristics for both algorithms presenting measurements of the number of produced disjoint products and the computation time of both algorithms for a large sample of randomly generated systems. These empirical values are used to investigate the efficiency of both algorithms by statistical means showing that the difference between both algorithm grows exponentially with system size and that Heidtmanns method is significantly superior. The results were obtained using our Java tool for system reliability and safety computation which is available in the WWW.

1

Introduction

Fault trees and reliability networks (also known as two-, K- or multi- terminal networks) illustrate the causal relationship between system and component failures. Both kinds of graphs representing the so called system structure are frequently used for reliability and safety modeling of complex technical systems. The advantage that they posses over Markov chains and stochastic Petri nets is a concise representation S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 70-81, 2002.  Springer-Verlag Berlin Heidelberg 2002

Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms

71

and efficient solution algorithms. The class of algorithms known as sum-of-disjointproducts (SDP) is the most often used for such reliability resp. safety calculations and is therefore an important technique for reliability and safety analysis. It is applied to compute various exact or approximate measures related to the reliability and safety of technical systems like availability, dependability, reliability, performability, safety, and risk [Hei97]. SDP-algorithms play also an important role in the calculation of degrees of support in the context of probabilistic assumption-based reasoning and the Dempster-Shafer theory of evidence [BeK95, Koh95, KoM95]. SDP methods start by generating minpaths for reliability graphs or the mincuts for fault trees. Given the reliabilities of the components and minimal sets of components (called minpath) that can allow a system to operate (safely), an SDP algorithm computes the reliability resp. safety, i.e. the probability that all components in at least one of these sets are operational. The system reliability or safety is the probability of the union of the minimal sets. This is a union of product problem. The idea of SDP is to convert the sum of products into the sum of disjoint products so to that the probability of the sum of products can be expressed as the sum of the probability of each disjoint product. If component failures are statistically independent then the probability of each disjoint product is the product of the corresponding component reliabilities. If this assumption of statistical independence is not valid in practice the result computed under this assumption may serve as an approximate bound. In general, when using the SDP approach, the evaluation is performed in three phases; 1) enumeration of all minimal sets (minpaths or mincuts), 2) computation of the disjoint products by using an SDP algorithm, and 3) calculation of the system reliability measure by assigning component indices to the reliability formula as a (weighted) sum of the disjoint products. Results reported in literature show that usually the time of the second phase is dominant in the total running time needed for evaluation. It is thus important to reduce the amount of the SDP algorithm by obtaining fewer disjoint products resulting in a smaller probabilistic reliability formula, because this reduces the rounding error, the storage space, and the computation time of reliability calculation. That fewer disjoint products result in a smaller probabilistic reliability formula is extremely important in system modeling, when this formula (as a sum of products) is evaluated repeatedly for various combinations of component indices. So the quality of an SDP-algorithm can be determined by the number of disjoint products it generates. As one of the first Abraham introduced an algorithm for the generation of disjoint products using single variable inversion and therefor producing a huge number of disjoint products [Abr79]. Further work on this technique of single variable inversion yielded only marginal improvements. To avoid this disadvantage of producing an immense number of disjoint products Heidtmann presented a fundamentally new approach (sometimes called KDH88) applying inversion to multiple or groupedvariables which he called subproducts [Hei89]. Later a similar but less powerful [LuT98a,b] version was published in [VeT91], where the method of multiple-variable inversion was verified. Heidtmann [Hei95] extended his technique to non-coherent (non-monotone) systems and this algorithm was verified in [BeM96]. The extended sum of disjoint products algorithm is applicable to all coherent and non-coherent system structures. It applies not only to this kind of reliability and safety structures which can be specified in terms of Boolean Logic, but it is also applicable to dynamic

72

Klaus Heidtmann

reliability and safety problems which can be supported by logical extensions like Temporal Logic [Hei91, Hei92, Hei97]. Unfortunately its computational amount grows exponentially with the size of the considered system. Just for specific classes of system structures like k-out-of-n systems [BaH84, Hei86], k-to-l-out-of-n structures [Hei81, Rus87, UpP93], and series-parallel systems linear time algorithms are known [Mis93, Hei95, Hei97]. A lot of comparative computations published in the literature [Hei89, VeT91, Hei95, BeM96, Hei97, LuT98a-c, CDR99] confirm that for both methods the number of produced disjoint products and the computation time grow exponentially with the size of the analyzed system. But these examples also indicate that the newer technique of Heidtmann using multiple variable inversion is superior to approaches considering only single variables like Abraham's algorithm. This was mathematically proved by [And92] in the sense that Abraham's technique is in no case superior to Heidtmann's algorithm. In [BeM96] it is said: "Compared to the algorithm of Abraham Heidtmann's method is considerably more efficient and will generate a much smaller number of disjoint products in most cases. A simple look at the results shows the strong superiority of Heidtmann's algorithm over the algorithm of Abraham, because it produces much less disjoint products in much less time: 29 cases the improvement (reduction) in the number of disjoint products generated is more than 50% and 17 cases it is more than 80%. The improvement becomes larger as the number of system components (edges) increases." These results were based on a very small sample of 35 systems only. Consequently, we want to investigate a much larger sample of systems to answer the following quantitative question with much more confidence: How much better is the newer approach of Heidtmann? Is it significantly superior? Is the trends observed on small samples also valid for a much larger sample? So in this paper we derive statements of statistical validity to answer these questions. This means that we investigate a large and statistically valid sample of systems to obtain results like Heidtmanns algorithm is so and so much better on the average or significantly better than Abrahams method. Reliability and safety computation for large systems impose high storage and computation time requirements on computers. To quantify and characterize these requirements we study the best known sum of disjoint products techniques for a huge number of systems. As results we present detailed measurements and stochastic characteristics of the output of both algorithms. In general the presented results give some insight into the stochastic characteristics of both algorithms and can be applied to design new algorithms and manage the computation process skillfully. First section 2 presents an example to illustrate both methods and especially their difference. Then details of their implementation and utilization from our homepage are discussed. Section 3 presents the experimental environment and describes the performed computational experiments followed by the first results on the number of disjoint products as the characteristic attribute of SDP-algorithms. This is confirmed by the observed computation times. Section 4 regression analysis is applied to the measured values to characterize the increase of the number of disjoint products and computation time by exponential expressions. We apply these expressions for instance to estimate the number of disjoint products and the computation time for larger reliability graphs.

Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms

2

73

Illustration of Both Algorithms and Their Implementation

In order to explain the purpose and the different approach as well as the different results of the two SDP-algorithms compared in this paper, let us start with a short example. Assume that a system with 5 components operates if components 1, 2 and 3 operate. It may also operate if components 4 and 5 operate. So this system has minsets (minpaths) {1,2,3} and {4,5}. For this example system Abrahams method produces the following disjoint events when it makes the last minset {4,5} disjoint to the former one{1,2,3}: A1. Component 1 is not operational, component 4 and 5 are operational. A2. Component 2 is not operational, components 1, 4, and 5 are operational. A3. Component 3 is not operational, components 1, 2, 4, and 5 are operational. In all three cases the first condition represents the single variable inversion (negation) technique. In a formal Boolean Logic notation where the AND-operator (conjunction) is written as a product, these disjoint events were represented by the following disjoint products: ¬x1x4x5, x1¬x2x4x5, x1x2¬x3x4x5 This results in the reliability formulas of Equation 1 for system reliability R depending on component reliabilities r1, r2, r3, r4, r5 in case of statistical independent component failures. For this example system the probabilistic reliability formula implied by Abrahams method consists of 4 summands (s. Equation 1): R = r1r2r3 + (1-r1)r4r5 + r1(1-r2)r4r5 + r1r2(1-r3)r4r5

(1)

Heidtmanns method results in the following single event which is disjoint to minpath {1,2,3}: H1. It is not true that component 1 and 2 and 3 are operational, while component 4 and 5 are operational. Here we invert or negate multiple variables (x1x2x3) or a group of component states (component 1 and 2 and 3 are operational). In a formal notation of Boolean Logic this looks like ¬(x1x2x3)x4x5 (or equivalently like (¬x1∨¬x2∨¬x3)x4x5 after applying the Shannon Inversion Theorem with the OR-Operator ∨ ). This yields the following reliability formula with only two summands (s. Equation 2): R = r1r2r3 + (1-r1r2r3)r4r5

(2)

So far we gave an explanation of both algorithms by example. Detailed textual and formal descriptions can be found in [Hei89, VeT91, Hei95, Hei97]. The last cited reference includes also programs in Pascal. Most implementations of the algorithms use the programming language C [VeT91, SoR91, LuT98a/b, TKK00, Vah98] and some of them are included in tools for reliability analysis, i.e. MOSEL [ABS99,Her00], SHARPE [TrM93,STP95,PTV97], CAREL [SoR91], SyRelAn [Vah95,Vah98] Another implementation uses Common Lisp [BeM96]. The experiments discussed in the following are based on our own implementation in Java. Our implementation, the experiments and the following results refer to the class of systems called reliability graphs. All nodes of these graphs are assumed to be perfectly reliable so that they can't fail and need not be considered in the reliability

74

Klaus Heidtmann

analysis, while the edges may fail so that they represent the components of the system which are susceptible to failure. A reliability graph is said to be operational if and only if all terminal nodes as a marked subset of all nodes are connected via operational edges. So the reliability of a reliability graph is the probability that all of its terminal nodes are connected by paths of operational edges. An algorithm for randomly generating reliability graphs for a given number edges as well as Abraham's and Heidtmann's algorithms were implemented in Java 2 and executed by the Java 2 Runtime Environment. These programs were used for the experiments which were discussed in the following sections. Moreover we integrated these programs as Java applets into a Web-tool named ReNeT (Reliability of Network Topologies) which can be run from our homepage http://www.informatik.unihamburg.de/TKRN/world/tools on your own computer. There is a graphical user interface where you may enter your reliability graph by drawing nodes (black circles for terminal nodes (left mouse bottom) and white circles for others (right mouse bottom)) and connecting them with edges. After drawing you can enter probabilities for component (edge) failures. The program then computes and shows both reliability formulas generated by Abraham's resp. Heidtmann's algorithm as different sums of disjoint products. At last it shows the reliability of the system or reliability graph you entered. The following section presents our comprehensive experimental measurements which were produced by a notebook with Pentium II 366 processor, 64 MB RAM, 128 MB Swap, and SuSE Linux 7.1, Kernel 2.4.0.

3

Results of Measurement

In this section we give first computational results to compare the performance of Heidtmanns algorithm versus the algorithm of Abraham. All together 3200 randomly generated reliability graphs with 5 to 16 unreliable edges were investigated representing 3200 systems with 5 to 16 unreliable components. In more detail, for each number of edges from 5 to 12 we randomly produced and analyzed 400 reliability graphs and for 13 to 16 edges we generated and investigated 100 graphs for each number of edges. First we show the detailed results for reliability graphs with 16 edges. In this case we randomly generated 100 graphs, computed there disjoint products by each of the two algorithms and counted the number of the resulting disjoint products. According to the theoretical result that Abraham's algorithm produces at least as many disjoint products as Heidtmann's method the number of actually computed disjoint products for each of the invested graphs was smaller in case of Heidtmann's algorithm. For Fig. 1 we arranged the resulting values by increasing number of disjoint products with regard to Heidtmann's algorithm (s. Fig. 1). It can be seen that in some cases the Abraham method produces more than twice the number disjoint products than Heidtmanns algorithm. In the worst case Abrahams algorithm produces about 8000 disjoint products whereas only about 2000 disjoint products result from Heidtmann's method, i.e. a third. So we notice from small to large differences in the number of disjoint products for both algorithms. The same applies to the computation time, which can be seen from Fig 2 noticing the logarithmical scale. In single cases, when the number of produced disjoint products is nearly identical for both methods,

Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms

75

Heidtm ann Abraha m

Number of Disjoint Products

8000

6000

4000

2000

0 0

20

40

60

Number of Sample Graph

80

Computation Time in ms (log)

Abraham's algorithm may become a little faster than Heidtmann's method, because the Abraham procedure to derive disjoint products is a little bit simpler. All in all the values of both attributes evaluated by the large sample show the great advantage of Heidtmann's method over Abraham's. Heidtmann Abraham

16 12 8 4 0

20 40 60 80 Number of Sample Graph

Fig. 1. Number of disjoint products (left) and computation time (right) for 100 sample graphs with 16 edges produced by Abrahams and Heidtmanns algorithm

Now we present the mean value of the number of disjoint products and the mean computation time in milliseconds for every sample of 400 resp. 100 graphs with an identical number of edges. These mean values are given in Tab. 1 and illustrated in the following Fig. 2. They seem to grow exponentially. This will be investigated in the following section. Table 1. Empirical mean of the number of disjoint products and the computation time in ms for 400 resp. 100 sample graphs resulting from Abraham's and Heidtmann's algorithm

76

Klaus Heidtmann

Abraham

Heidtmann

10000000 Mean Computation Time in ms (log)

Number of Disjoint Products (log)

Abraham

Heidtmann

10000

1000

100

10

100000

1000

10

1 5

6

7

8

9

10

11

12

13

14

15

16

Number of Edges

0.1 5

6

7

8

9

10

11

12

13

14

15

16

Number of Edges

Fig. 2. Comparison of mean number of disjoint products (left) and mean computation time (right) for both algorithms (Notice the logarithmical scale !)

To show the influence of different operating systems on the computation time Table 2 includes the empirical mean values of computation time in milliseconds for 100 sample graphs with 10 edges and both algorithms. Table 2. Empirical mean of the computation time (ms) on computers with different operating systems for 100 sample graphs with 10 edges

Operating System Linux Windows NT Solaris

4

Computation Abraham 173,7 114,7 203,8

Time (ms) Heidtmann 65,3 94,0 124,2

Statistical Comparison

To see the increase of the mean value of the number of disjoint products and the mean computation time with increasing number of edges we illustrate the values of Tab. 1 by the following Fig. 3. Here it is obvious that both values for Heidtmann's algorithm follow exponential distributions. The similar figure of Abraham's method which increases much more rapidly is not presented here. So the measured results lead to the hypothesis that neither the number of disjoint products produced nor the computation time follow a normal distribution. The corresponding statistical tests (Kolmogoroff-Smirnov) confirmed this hypothesis. The regression analysis of SPSS (Software Packet of Statistical Standard-Software) was used to compute an approximation of the mean value of the number of disjoint

Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms

77

products depending on the number of edges n. It yields the following exponential functions: 0.0106 exp(0.5594 n) for Heidtmann's algorithm as seen in Fig.3 (left) and 0.0869 exp(0.6276 n) for Abraham's technique. A similar approximation of the computation time yields 0.0015 exp(1.0839 n) for Heidtmann's algorithm as seen in Fig.3 (right) and 0.0011 exp(1.1212 n) for Abraham's method Using these expressions we can estimate the number of disjoint products and the computation time for reliability graphs with more than 16 edges by regression analysis without explicit generation of the graphs and their further investigation. So for systems with 17 to 20 components and both algorithms the estimated number of disjoint products and the estimated computation time are given in Table 3. Here the immensely increasing superiority of Heidtmann's technique over the method of Abraham is obvious. observed exponential

observed exponential 80000 Mean Computation Time in ms

Mean Number of Disjoint Products

800

600

400

200

60000

40000

20000

0 5

6

7

8

9

10

11

12

Number of Edges

13

14

15

16

0 5

6

7

8

9

10 11 12 13 14 15 16

Number of Edges

Fig. 3. Mean numbers of disjoint products (left) and computation time (right) for sample graphs with 5 to 16 edges produced by Heidtmann's algorithm

As the number of disjoint products and the computation time do not follow normal distributions as was tested with the Kolmogoroff-Smirnov-Test we applied the Wilcoxon-Test for related samples. It is clear that for a specific reliability graph the number of disjoint products produced by the Abraham algorithm and the corresponding number of Heidtmann's algorithm are related. The same applies to the computation time of both algorithms applied to the same reliability graph. So the number of disjoint products and the computation time can be arranged in pairs, where each pair belongs to the same reliability graph. So we applied the Wilcoxon-Test to the samples of 400 randomly generated reliability graphs with 5 to 12 and to the samples of 100 randomly generated graphs each with 13 to 16 edges. The results of the Wilcoxon-Test shows that for all these 11 samples the values of the number of disjoint products and the computation time differ with high significance. The same results when we apply the Test to the whole sample of 3200 reliability graphs. In all cases the level of significance is Zero, which means high significance. So the

78

Klaus Heidtmann

algorithm of Heidtmann is high significantly superior to Abraham's method as far as the number of produced disjoint products and the computation time is concerned. Table 3. Estimates for the number of disjoint products and for the computation time of reliability graphs with more than 16 edges for both algorithms

Number of Components (Edges)

5

Estimated Number of Disjoint Estimated Computation Time Products (ms) Abraham Heidtmann Abraham Heidtmann

17

3.740

1.444

1.006.48

152.73

18

7.006

2.527

3.384.97

451.53

19

13.124

4.422

11.384.28

1.334.90

20

24.585

7.738

38.287.39

3.946.49

Conclusion and Outlook

This paper presented comprehensive measurements and a detailed stochastic characterization of the output of two frequently used algorithms for reliability and safety computation as an important step of reliability and safety analysis. First the two sum of disjoint products algorithms of Abraham and Heidtmann were explained by an example, which also illustrated the typical difference in the number of disjoint products. This attribute together with the computation time of these two algorithms was measured for 3200 reliability graphs. The results of this measurement were discussed beginning with the illustration of the measured values for 100 randomly generated reliability graphs with 16 edges, which correspond to systems with 16 unreliable components. The number of disjoint products and the computation time grow exponentially with the number of components for both algorithms as well as the difference of their numbers of disjoint products and their computation time. Heidtmann's algorithm was significantly superior with respect to both attributes. Very similar output was observed for 3100 other reliability graphs with 5 to 15 edges. Obviously the single variable inversion technique of Abraham generally produces very large numbers of disjoint products while multiple variable inversion of Heidtmann's method achieves appreciably fewer disjoint products. This is very important as it results in much shorter computation time for the set of disjoint products, additionally reduces the storage space and produces a much smaller reliability formula. Therefore computation time for the evaluation of the reliability formula is reduced as well as the rounding error. No observed values of the performed measurements were normally (Gaussian) distributed. Based on the empirical results the number of disjoint products and the computation time for both algorithms and the their differences were estimated for larger systems by regression analysis. All in all the values of both attributes, i.e. number of disjoint products and computation time, evaluated by a large sample show the great advantage of Heidtmann's algorithm over Abraham's. Because of the exponential growth reliability and safety measures are often approximated for large systems. If only a given subset of a systems minsets is

Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms

79

considered for approximate computation Heidtmann's algorithm computes the approximate value faster than Abraham's method. If special resources like computation time or storage is limited than Heidtmann's technique uses these restricted resources much more efficient than Abraham's algorithm producing closer approximations than Abraham's method with identical resources. The quantification of these advantages as well as the use of both algorithms for approximation purposes in general needs further investigation and will be subject to further studies. The derived stochastic characteristics can be applied to the development of more efficient algorithms for reliability computation so that they produce fewer disjoint products and a smaller reliability formula. In the context of approximation our characterization can be used straight forward to derive some comparative aspects. Furthermore, these results can be applied to estimate characteristic attributes for larger systems, for instance by regression analysis, or to use our Java code to analyze your own systems. In this case their are two ways for your own reliability analyses. On one hand our tool is extremely useful as a Java applet, e.g. when applying it via the WWW directly to your reliability problem executing the reliability computation on your own computer. On the other hand our Java programs can serve as a basis for local installations of both algorithms. In both cases our programs can be used for your own reliability and safety analysis. Moreover, the behavior of the algorithms can be investigated for various systems by means of measurement or the influence of different system structures on the efficiency of the algorithms can be observed. It may also be possible to exploit new areas of application for this efficient SDPalgorithm [YuT98]. Besides coherent and non-coherent system structures as well as the solution of dynamic reliability and safety problems using Temporal Logic [Hei91, Hei92, Hei97] it is important to know and use the algorithm that minimizes the reliability formula (minimal sum of disjoint products) since such formulas play also a central role in probabilistic assumption-based truth maintenance systems [LaL89] and probabilistic assumption-based reasoning [Koh95, KoM95, BeK95]. In many practical applications it is possible to reduce large systems by well known reduction methods [Mis83, Hei97] so that the reduced system can further be analysed by SDP-methods. The often used example of a two terminal ARPA-network with 24 edges (system components) can be reduced to 8 edges by series- and polygon-tochain-reduction [Hei97].

References [Abr79]

Abraham J.A., An improved algorithm for network reliability, IEEE Trans. Reliability Vol. 28, No. 1, 1979 58-61, also in: [RaA90], 89-92 [ABS99] Almasi B., Bolch G., Sztrik J., Modeling Terminal Systems using MOSEL, Proc. Europ. Simulation Symp. ESS'99, Erlangen, Germany, 1999 [And92] Anders J.M., Methods for the reliability analysis of complex binary systems, PhD thesis, Dept. Mathematics, Humboldt-University, Berlin, 1992 [BaH 84] Barlow R.E., Heidtmann K.D., Computing k-out-of-n system reliability, IEEE Trans. Reliability, 33, 3, 1984

80

Klaus Heidtmann

[BeK95] [BeM96] [CDR99] [Hei81] [Hei86] [Hei89] [Hei91]

[Hei92] [Hei95]

[Hei97] [Her00] [Koh95] [KoM95] [LaL89] [LuT98a]

Besnard P., Kohlas J., Evidence Theory based on general consequence relations, Intern. J. Foundation of Computer Science 6, 1995, 119-135 Bertschy R., Monney P.A., A generalization of the algorithm of Heidtmann to non-monotone formulas, J. of Computational and Applied Mathematics, Dec 1996, Vol. 76, No. 1-2, 55-76 Chatelet E., Dutuit Y., Rauzy A., Bouhoufani T., An optimized procedure to generate sums of disjoint products, Reliability Engineering and System Safety, Sept. 1999, Vol. 65, No. 3, 289-294 Heidtmann K.D., A class of noncoherent systems and their reliability analysis, Dig. 11th Ann. Intern. Symp. Fault-Tolerant Computing, FTCS 11, Portland/USA, 1981 Heidtmann K.D., Minset splitting for improved reliability computation, IEEE Trans. Reliability 35, 5, 1986 Heidtmann K.D., Smaller sums of disjoint products by subproduct inversion, IEEE Trans. Reliability 38, 3, 1989, 305-311 Heidtmann K.D., Temporal Logic applied to reliability modeling of faulttolerant systems, Proc. 2nd Intern. Symp. Formal Techniques in RealTime and Fault-Tolerant Systems, Nijmegen/Netherlands, 1992, in: Vytopil J., Lecture Notes in Computer Science, No. 571, Springer, Berlin, 1991 Heidtmann K.D., Deterministic reliability modeling of dynamic redundancy, IEEE Trans. Reliability 41, 3, 1992, 378-385 Heidtmann K.D., Methoden zur Zuverlässigkeitsanalyse unter besonderer Berücksichtigung von Rechnernetzen (Methods for reliability analysis with special emphasis on computer communication networks), Habilitationsschrift, Dept. Comp. Science, Hamburg University, 1995 (in german) Heidtmann K.D., Zuverlässigkeitsbewertung technischer Systeme (Reliability analysis of technical systems), Teubner, Stuttgart, 1997 (in german) Herold H., MOSEL, An Universal Language for Modeling Computer, Communication, and Manufacturing Systems, PhD Thesis, Techn. Faculty, University Eralngen, 2000 Mathematical foundations of evidence theory, in: Coletti G., Dubois D., Scozzafa R., (Eds.), Mathematical Models for Handling Partial Knowledge in Artificial Intelligence, Plenum Press, New York, 1995, 31-64 Kohlas J., Monney P.A., A Mathematical Theory of Hints, An Approach to the Dempster-Shafer Theory of Evidence, Lecture Notes in Economics and Mathematical Systems Vol. 425, Springer, Berlin, 1995 Laskey K.B., Lehner P.E., Assumptions, belief and probabilities, Artificial Intelligence 41, 1989, 65-77 Luo T., Trivedi K.S., An improved multiple variable inversion algorithm for reliability calculation, 10th Intern. Conf. Tools'98, Palma de Mallorca, Spain, Sept. 1998, in: Puigjaner R., Savino N.N., Serra B. (eds.), Computer Performance Evaluation, Modeling Techniques and Tools, Springer, 1998

Statistical Comparison of Two Sum-of-Disjoint-Product Algorithms

81

[LuT98b] Luo T., Trivedi K.S., An improved algorithm for coherent-system reliability, IEEE Trans. Reliability, March 1998, Vol. 47, No. 1, 73-78 [LuT98c] Luo T., Trivedi K.S., Using Multiple Inversion Techniques to Analyze Fault-trees with Inversion Gates, 28Th Ann. Fault Tolerant Computing Symp., FTCS 98, Munich 1998 [Mis93] Misra K.B., New trends in system reliability evaluation, Elsevier Publishers, 1993 [PTV97] Puliafito A., Tomarchio O, Vita L., Porting SHARPE on the Web, Proc. TOOL'97, Saint Malo, June 1997 [RaA90] Rai S., Agrawal D.P., Distributed Computing Network Reliability, IEEE Computer Society Press, Washington, 1990 [Rus87] Rushdi A.M., Efficient computation of k-to-l-out-of-n systems, Reliability Engineering 17, 1987, 157-163 [RVT95] Rai S., Veeraraghavan, Trivedi K.S., A Survey of Efficient Reliability Computation Using Disjoint Products Approach, Networks 25, 3, 1995, 147-163 [SoR91] Soh S., Rai S., CAREL: computer aided reliability estimator for distributed computing networks, IEEE Trans. Parallel and Distributed Systems 2, 2, 1991, 199-213 [STP95] Sahner R., Trivedi K.S., Puliafito A., Performance and Reliability Analysis of Computer Systems - An Example Based Approach Using SHARPE Software Package, Kluwer Academic Publishers, Massachussetts, 1995 [TKK00] Tsuchiya T., Kajikawa T., Kikuno T., Parallelizing SDP (Sum of Disjoint Products) Algorithms for fast reliability analysis, IEICE Trans. Inf. & Syst., Vol. E83, No. 5, May 2000, 1183-1186 [TrM93] Trivedi K.S., Malhotra M., Reliability and Performability Techniques and Tools: A Survey Proc. 7th ITG/GI Conf. Measurement, Modelling and Evaluation of Computer and Communication Systems, Aachen University of Technology, 1993, 27-48 [UpP93] Upadhyaya, Pham, Analysis of a class of noncoherent systems and an architecture for the computation of the system reliability, IEEE Trans. Computers 42, 4, 1993 [Vah95] Vahl A. Reliability Assessment of Complex System Structures – A Software Tool for Design Support, Proc. 9th Symp. Quality and Reliability in Electronics, Relectronic'95, Budapest, 1995, 161-166 [Vah98] Vahl A., Interaktive Zuverlässigkeitsanalyse von FlugzeugSystemarchitekturen, PhD Thesis, Technical University HamburgHarburg, Flugzeug-Systemtechnik, VDI-Verlag, Düsseldorf, 1998 (in german) [VeT91] Veeraraghavan and Trivedi K.S., An improved algorithm for the symbolic reliability Analysis of Networks," IEEE Trans. on Reliability, Vol. 40, No. 3, Aug. 1991, 347-358 [YuT98] Ma Yue, Trivedi K.S., An algorithm for reliability analysis of phased mission systems, Intern. Symposium on Software Reliability Engineering, ISSRE 1998

Safety and Security Analysis of Object-Oriented Models Kevin Lano, David Clark, and Kelly Androutsopoulos Department of Computer Science, King’s College London Strand, London WC2R 2LS, UK Phone: +44 (0)207 2832, Fax: +44 (0)207 2851 [email protected] Abstract. In this paper we review existing approaches for the safety and security analysis of object-oriented software designs, and identify ways in which these approaches can be improved and made more rigorous.

1

Introduction

Object-oriented software is increasingly being used for critical systems: the widespread use of Java for smartcard based security-critical applications in particular is one example where intensive verification and proof techniques have been used [4, 6]. C++ has also been used in safety-critical and safety-related systems, and it seems likely that the use of such languages and methods will increase, as the impact of the standardisation of UML [10] and the convergence of commercial software development on Java and Java-like environments throughout the software industry spreads into the safety-critical systems domain. There are good engineering reasons for this trend, in that the capabilities of developers seem to be generally enhanced through the use of such methods and languages: it becomes easier to analyse and review the software and to detect and correct errors, because of the increased opportunities for modularising and structuring the software into relatively independent subcomponents with restricted interfaces. Java in particular could be regarded as a safe(r) subset of C++, eliminating many of the features, such as pointers and programmer defined memory management, which are a frequent cause of subtle errors in C and C++ programs. It would be direct to adapt the MISRA C rules [3] to Java, indeed many of these rules are already common practice for Java programmers. Assertion-based static analysis tools for Java are now available [11]. In this paper we examine how safety analysis techniques such as HAZOPS and fault tree analysis (FTA) can be adapted to object-oriented system and software modelling notations, particularly UML.

2

Hazard Analysis of Object-Oriented Models

Standards such as [8] recommend that hazard identification, hazard analysis and risk analysis should be carried out for critical systems. Recommended techniques for these processes include HAZOPS [9] and Fault Tree Analysis (FTA). S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 82–93, 2002. c Springer-Verlag Berlin Heidelberg 2002


Safety and Security Analysis of Object-Oriented Models

83

Table 1. 00-58 Guideword Interpretations for Event Guideword No As well as Other than

Interpretation Event does not happen Another event takes place as well An unexpected event occurs instead of the expected event

HAZOPS consists of a process of systematic exploration of analysis and design diagrams and documentation of a system for possible deviations from required behaviour or design intent, and identification of hazards caused by such deviations. Based on a design diagram, the elements of the system are identified, and for each element attributes are identified, for example, the position of a valve. A set of guidewords such as NO , REVERSE , AS WELL AS are then applied to each attribute to identify possible deviations (eg, the valve being open when it should be closed). HAZOPS can be applied at an early stage of system construction, where the main features of a system and intended behaviour are known, but detailed algorithms or decomposition of modules have not been produced. FTA derives a detailed causality structure for each credible hazard produced from HAZOPS, and assigns maximum acceptable probability bounds to events based on the maximum acceptable probabilities of their consequent hazards. Def-Stan 00-58 [9] gives some guidelines for the hazard analysis of state transition diagrams and entity-relationship-attribute models using HAZOPS. These guidelines and the examples given are unclear and ambiguous in some cases, which we discuss below. We provide an alternative and systematic set of guidelines for HAZOPS of UML notations, and give examples of their use. 2.1

State Transition Diagrams

For state transition diagrams Def-Stan 00-58 Part 2 considers the transitions as the basic elements of analysis and the attributes event and action of transitions. For events there are the following guidewords and interpretations (Table 1). However “Event does not happen” is ambiguous – its meaning depends on what the state machine model represents: a specification of a control system,

Table 2. Revised Guideword Interpretations for Event Guideword Interpretations No Event not received by control system: either it occurs but is not transmitted to the controller because of sensor or other failure, or it does not occur even though expected As well as Another event is detected by the control system as well as the intended event Other than An unexpected event is detected instead of the expected event

84

Kevin Lano et al.

Table 3. 00-58 Guideword Interpretations for Action Guideword No As well as Part of Other than

Interpretation No action takes place Additional (unwanted) actions take place An incomplete action is performed An incorrect action takes place

or a description of the equipment under control (EUC). In the former case the guidewords can be alternatively interpreted as follows (Table 2). For example, having commanded a railway switch (points) to change position, the control system expects an event confirming the completion of the close. Suitable action must be taken if this event does not occur within a given time period. An initial HAZOPS would consider deviations at the complete system level, not examining details of the control system behaviour but instead issues of how deviations from design intent in the controlled system can lead to hazards. For example failure of the switch to close can lead to derailment if undetected. At an initial design level HAZOPS can consider the intended state transition behaviour of the control system and identify more specific ways that deviations from design intent can occur. Eg: the switch may actually close but the control system not detect this due to faulty sensors, connections or control logic, etc. A similar distinction is necessary on the output side of a state machine as well. The attribute in this case is the transition action, which has the following guidewords (Table 3). Again we can regard the above as appropriate when considering the overall behaviour of a system, and the following as appropriate when considering deviations of a software control system (Table 4). For states, deviations could be as given in Table 5. Consideration of timing also needs to be relative to either the controlled system or the controller behaviour. A significant time delay between a realworld event and its detection by a controller would be a deviation considered by the latter analysis for example, whereas a railway switch closing more slowly than intended, because of ice, for example, would be a deviation considered by the former.

Table 4. Revised Guideword Interpretations for Action Guideword Interpretations No No action is produced by the controller, or this action is not transmitted to/carried out by actuators As well as Additional (unwanted) actions are generated/performed Part of An incomplete action is generated/performed Other than An incorrect action is generated/performed

Safety and Security Analysis of Object-Oriented Models

85

Table 5. Guideword Interpretations for State Guideword Interpretation No Object not in expected state Other than Object in an unexpected state

2.2

Class Diagrams

Entity-relationship diagrams are considered in section A.5.2 of 00-58, Part 2. However the guideword interpretations suggested tend towards consideration of design flaws of the diagram (eg: “there is a required relationship that is not shown on the diagram”) instead of deviations from design intent of the system described by the diagram. An example of the latter could be: “not all train locations are recorded in the data of the control system” – ie, a discrepancy exists between what the system is supposed to do, according to the diagram, and what it may do in a “part of” deviation. We suggest the following guideword interpretations for relationships (Table 6). For classes we could have the interpretations given in Table 7. For attributes of classes, we could have the interpretations given in Table 8. 2.3

Sequence Diagrams

Sequence diagrams in UML describe the objects and messages involved in a use case (for example, the system reaction to a particular external request or event). Compared to class diagrams and statecharts sequence diagrams are imprecise, representing examples or instances of behaviour which could be more comprehensively and accurately defined in these other models. However in the development process sequence diagrams may precede the construction of statechart models, so may therefore be analysed earlier.

Table 6. Guideword Interpretations for Relationships Guideword Interpretations No No information about this relationship between two objects is recorded by the control system, even though the relation is true in the real world; or the relation does not hold between two real-world objects when it is expected to More/less The number of objects in the relationship with another does not obey the cardinality restrictions expected. This may either be a feature of the real world or erroneous data held by the control system Part of Some semantic constraints of the relation given in the diagram hold, but others do not (either in the real world or in the control system data) Other than The specified relation does not occur between some objects, another unintended relation is present instead between these objects

86

Kevin Lano et al.

Table 7. Guideword Interpretations for Classes Guideword Interpretation No An object is not a member of an expected class More/Less A class has more/fewer instances than expected Part of Some of the class constraints are true, others are not Other than An object is a member of an unintended class

Table 8. Guideword Interpretations for Attributes Guideword Interpretation No An object has no value for this attribute when it should do More/Less An attribute has a higher/lower value than expected (or more/fewer values than expected, if it is multivalued) Part of Some of the attribute constraints are true, others are not Other than Attribute is a member of an incorrect type

The main entities in a sequence diagram are objects and messages. Objects have the following attributes: (i) their (runtime) class; (ii) their lifetime. Messages have the following attributes: (i) data; (ii) time of occurrence; (iii) source object; (iv) destination object; (v) condition; (vi) delay; (vii) duration (in the case of synchronous messages). For each attribute of objects and messages in a sequence diagram we can apply guidewords, as follows. Table 9 considers the time of occurrence of a message. For the attribute of target object we could have the interpretations given in Table 10. Table 11 gives interpretations for message conditions. 2.4

Def-Stan 00-58 Case Studies and Problems

Annex C of 00-58 part 2 illustrates some PES HAZOPS. These examples are unclear in several cases due to omission of the ‘interpretation’ column in the tables. This interpretation is still only implicit in the example dialogues and should be made explicit. For example, “Other information is present in the data flow” in C.5.1. Figure 15 has errors (eg, the conditions on the transitions between

Table 9. Guideword Interpretations for Message Timing Guideword NO/NONE OTHER THAN AS WELL AS MORE THAN LESS THAN SOONER LATER

Interpretation Message not sent when it should be Message sent at wrong time Message sent at correct time and also an incorrect time Message sent later/more often than intended Message sent earlier/less often than intended Message sent earlier within message sequence than intended Message sent later within message sequence than intended

Safety and Security Analysis of Object-Oriented Models

87

Table 10. Guideword Interpretations for Message Destination Guideword NO/NONE OTHER THAN AS WELL AS REVERSE MORE THAN LESS THAN

Interpretation Message not sent when intended (to any destination) Message sent to wrong object Message sent to correct object and also an incorrect object Source and destination objects are reversed Message sent to more objects than intended Message sent to fewer objects than intended

Table 11. Guideword Interpretations for Message Conditions Guideword NO/NONE OTHER THAN REVERSE AS WELL AS

Interpretation Condition not true when intended Condition has unintended truth value Condition has opposite truth value to intended An unintended property is true in addition to the condition

“Creep” and “low speed” are swapped). In D.4.1 the analysis could be more accurately expressed as a deviation OTHER THAN on the Event attribute of the state machine, ie, an incorrect event is detected by the system. One cause of this incorrect event being detected is wheel spin leading to an incorrect high speed measurement. A consequence is that the system will fail to be activated when it should be (because the real speed is ≤ MIN). D.4.2 again concerns the Event attribute on a transition, and guideword NO: failure of the system to register the vehicle becomes present event when it should.

{ (b,l) : located_at & l : DepositBelt => b.pressed } Blank * located_at pressed: 0..n bool 0..1 0..n 0..1

1 Location

0..1 Feedbelt

Press 0..1

Deposit Belt 0..1

Table 0..1

Fig. 1. Analysis Class Diagram for Production Cell

88

Kevin Lano et al.

Table 12. Guideword Interpretations for Case Study Attribute Blank/table relationship

Guideword Interpretations No Blank never placed on table after leaving feed belt. Or system has failed to detect it on table. More 2 or more blanks are on the table. Blank/deposit Part of There is an unpressed belt relationship blank on the deposit belt.

2.5

Case Study: Production Cell

An example of application of the above approach is the following, taken from an analysis of a production cell, in which blanks (car body templates) are moved along a feed belt onto an elevating table to be picked up by a robot arm and then transferred to a press for pressing before being transferred to a deposit belt [5]. Figure 1 shows part of the UML class diagram for this system. Applying HAZOPS to this diagram, using table 6, we could have the analyses given in Table 12. In general either the real world deviates from the model described in the class diagram, and either the software correctly represents this failure, or it does not, or the real world conforms to the model but the software has incorrect knowledge. These three cases may be significantly different in terms of deviation causes and consequences, so should be analysed separately. For instance if a blank has failed to be pressed, and the software fails to detect this, hazards may arise with later processing stages. On the other hand if the blank has been pressed but the software fails to detect this, it may be re-pressed, possibly causing damage to the press. Figure 2 shows the controller state machine for the feed belt. s2 is the blank sensor at the end of the feed belt, stm a signal indicating that the feed belt is safe to move, and bm is the belt motor. Hazard states are indicated by a cross. HAZOPS of this state machine, using tables 2 and 4, identifies the following potential deviations and hazards (Table 13).

Table 13. Guideword Interpretations for Feed belt state machine Attribute Guideword Interpretation and Consequences Event No stmoff not detected when it should be. (for transition Control system leaves motor on, off on on → resulting in hazard state off off on) off off on in EUC. Action Other than bmSeton issued instead of bmSetoff . (for transition EUC stays in state on off on on off on → which is hazardous. on off off )

Safety and Security Analysis of Object-Oriented Models Tuples in order s2_stm_bm stmon

off_off_off

89

Sensor transition: Actuator transition: off_on_off

/bmSeton

/bmSetoff stmoff

off_on_on

off_off_on s2off

s2on

on_on_on on_on_off

/bmSeton

stmoff

stmon on_off_on on_off_off

/bmSetoff

Fig. 2. Controller state machine for Feed belt

3

Security Analysis

Many safety-critical systems have security issues – eg, in a railway network management system, communication between a train coordinator and train drivers must be authenticated to ensure safe operation of the railway. Other systems may not have direct safety implications (eg, an online banking system) but have security aspects with critical consequences. Traditional HAZOPS concerns deviations from intended functionality, in general. For security HAZOPS we want to focus on the relevant components (elements which store, process or transmit data internally, or which receive/transmit data to the external world) and relevant attributes, guidewords and interpretations. Deviation analysis of object-oriented models for security properties can follow the same set of guidewords and interpretations as given above. The elements and attributes of interest will be focussed on security, and similarly for the causes and consequences of deviations. For example in the model of Figure 3 a “part of” deviation could be that some user with a security level below admin is logged into the secure host.

User permissions

*

logged_on

1

Secure Host

{ (user,host): logged_on => user.permissions >= admin }

Fig. 3. Part of Class Diagram of Secure System

90

Kevin Lano et al.

The aim of security HAZOPS is to identify deviations from design intent which have security implications, ie, which affect the systems ability to: – ensure confidentiality and integrity of information it stores/processes/internally transmits (Confidentiality/Integrity) – provide authentication of information it produces (outputs) and to authenticate input information (Authentication) – ensure availability of services/information (Availability) – provide a trace of all user interactions, such as login attempts to the system (Non-repudiation). The team approach and other organisational aspects of HAZOPS defined in Def-Stan 00-58 could still be used, although the range of expertise should be relevant (eg, including experts in the encryption/networking approaches used in the system). The components involved will be: – Physical components: processing nodes (including intermediate relay nodes in a communication network); memory; connectors; input devices (eg, keyboard; smartcard reader; biometric sensor); output devices (eg, CD burner; smartcard writer; VDU) – Information components: file, email, network packet. Subcomponents such as particular record fields/email header, etc. Therefore the guidewords and interpretations could be: – NO/NONE – complete absence of intended CIA/A/NR property for component being considered – LESS – inadequate CIA/A/NR property compared with intention – PART OF – only part of intended CIA/A/NR achieved – OTHER THAN – intended CIA/A/NR property achieved, but some unintended property also present. LATE, EARLY, BEFORE, AFTER, INTERRUPT could also be relevant. The paper [12] gives more focussed guidewords, using the idea of a guidephrase template. We can extend this concept to consider the additional properties of authentication and non-repudiation. CIA/A/NR properties may be lost due either to device behaviour (technical failure/cause) or to human actions. Human actions may either be deliberate hostile actions (by insiders or outsiders) or unintentional human failures (or correct procedures which nonetheless lead to a loss of CIA/A/NR). Negations of CIA/A/NR properties are: disclosure, manipulation (subcases being fabrication, amendment, removal, addition, etc), denial, misauthentication (includes authentication of invalid data and inauthentication of valid data), repudiation. The adapted guidephrase template is given in Table 14. Examples of these and their interpretations could be:

Safety and Security Analysis of Object-Oriented Models

91

Table 14. Revised Guidephrase Template (Pre) Guideword Attribute Deliberate Disclosure Manipulation of COMPONENT by Unintentional Denial Misauthentication Repudiation

(Post) Guideword Insider Outsider Technical behaviour/ functionality

– Unintentional misauthentication of connection request to firewall by technical behaviour. Interpretation (1): firewall authenticates sender of request when it should not. Interpretation (2): firewall does not authenticate a valid sender of request and denies the connection when it should not. – Deliberate disclosure of patient record by insider. Interpretation: staff member provides patient information intentionally to a third party. We could apply this approach to an example of an internet medical analysis system (Figure 4): – The company provides a server to perform analysis of data which customers upload to the website, and download results from. – Data is encrypted by a private key method between the client and server, but stored in decrypted form on the server and the smartcard. – The smartcard reader at the client computer reads data from the smartcard for transmission to the server. – Customers have a password/login for the website, this is checked against their customer ID data on the smartcard (written by the server on registration/initialisation of the card). Only if both agree is the login accepted. – Each customer is allocated a separate directory at the server and cannot load/read the data of any other customer.

Internet

Server

Client PC Data storage Smartcard reader

Fig. 4. Architecture of Medical Analysis System

92

Kevin Lano et al.

An example security HAZOPS analysis from this system is given in Table 15. Detailed risk analysis can then be carried out:

Table 15. Example Analysis of Medical System Guidephrase Unintentional misauthentication of smartcard by technical function Deliberate manipulation of server data by outsider

Interpretation An invalid smartcard is authenticated when it should not be Server data altered by unauthorised person

Causes Software fault in checker, or HW failure in reader Outsider gains login access to server, or via unsecured webpages or scripts

Consequences Valid user can use invalid card: may corrupt data stored on server Analysis data may be altered so incorrect results are given

– Given a specific loss of security situation from the HAZOP, we can compute the approximate likelihoods and severity, and therefore the risk level. – The probability of decryption of encrypted data can be estimated using mathematical theory, other probabilities, of interception, intrusion, denial of service attacks, are less clear, although estimates based on previous experience could be used.

4

Related Work

State machine hazard analysis has been used informally in the HCI field [2] and tool support for generating fault trees from state machines has been developed as part of RSML [7]. The CORAS Esprit project (http://www.nr.no/coras/) is investigating security analysis of object-oriented systems, using scenario analysis. Such analysis could be based on the identification of individual deviations using the techniques give here. Tools for HAZOPS analysis such as PHA-Pro 5 (http://www.woodhill.co.uk/pha/pha.htm) and PHAWorks 5 (http://www.primatech.com/software/phaworks5.htm) deal mainly with process control system HAZOPS support, and do not cover programmable electronic system designs.

5

Conclusion

We have described approaches for HAZOPS of UML notations and for security HAZOPS. These revised guidewords and interpretations have been implemented

Safety and Security Analysis of Object-Oriented Models

93

in a hazard analysis tool for UML class diagrams and E/E/PES P&I diagrams within the RSDS support environment [1].

References [1] K. Androutsopoulos, The RSDS Tool, Department of Computer Science, King’s College, 2001. http://www.dcs.kcl.ac.uk/pg/kelly/Tools/ 93 [2] Alan Dix, Janet Finlay, Gregory Abowd, Russell Beale, Human-Computer Interaction, 2nd Edition, Prentice Hall, 1998. 92 [3] ISO, Guidelines for the Use of the C Language in Vehicle Based Software, ISO TR/15497. Also at: http://www.misra.org.uk/. 82 [4] J. L. Lanet, A. Requet, Formal Proof of Smart Card Applets Correctness, Proceedings of 3rd Smart Card Research and Advanced Application Conference (CARDIS ’98), Sept. 1998. 82 [5] K. Lano, D. Clark, K. Androutsopoulos, P. Kan, Invariant-based Synthesis of Fault-tolerant Systems, FTRTFT 2000, Pune, India, 2000. 88 [6] P. Lartigue, D. Sabatier, The use of the B Formal Method for the Design and Validation of the Transaction Mechanism for Smart Card Applications, Proceedings of FM ’99, pp. 348–368, Springer-Verlag, 1999. 82 [7] Nancy G. Leveson. Designing a Requirements Specification Language for Reactive Systems. Invited talk, Z User Meeting, 1998, Springer Verlag 1998. 92 [8] Ministry of Defence, Defence Standard 00-56, Issue 2, 1996. 82 [9] Ministry of Defence, Defence Standard 00-58, Issue 2, 2000. 82, 83 [10] Rational Software et al, OMG Unified Modeling Language Specification Version 1.4, 2001. 82 [11] K R Leino, J Saxe, R Stata, Checking Java programs with Guarded Commands, in Formal Techniques for Java Programs, technical report 251, Fernuniversit¨ at Hagen, 1999. 82 [12] R. Winther, O-A. Johansen, B. A. Gran, Security Assessments of Safety Critical Systems using HAZOPS, Safecomp 2000. 90

The CORAS Framework for a Model-Based Risk Management Process Rune Fredriksen1 , Monica Kristiansen1 , Bjørn Axel Gran1 , Ketil Stølen2 , Tom Arthur Opperud3 , and Theo Dimitrakos4 1

Institute for Energy Technology, Halden, Norway {Rune.Fredriksen,Monica Kristiansen,Bjorn-Axel Gran}@hrp.no http://www.ife.no 2 Sintef Telecom and Informatics, Oslo, Norway [email protected] http://www.sintef.no 3 Telenor Communications AS R&D, Fornebu, Norway [email protected] http://www.telenor.no 4 CLRC Rutherford Appleton Laboratory (RAL), Oxfordshire, UK [email protected] http://www.rl.ac.uk

Abstract. CORAS is a research and technological development project under the Information Society Technologies (IST) Programme (Commission of the European Communities, Directorate-General Information Society). One of the main objectives of CORAS is to develop a practical framework, exploiting methods for risk analysis, semiformal methods for object-oriented modelling, and computerised tools, for a precise, unambiguous, and efficient risk assessment of security critical systems. This paper presents the CORAS framework and the related conclusions from the CORAS project so far.

1

Introduction

CORAS [1] is a research and technological development project under the Information Society Technologies (IST) Programme (Commission of the European Communities, Directorate-General Information Society). CORAS started up in January 2001 and runs until July 2003. The CORAS main objectives are as follows: – To develop a practical framework, exploiting methods for risk analysis, semiformal methods for object-oriented modelling, and computerised tools, for a precise, unambiguous, and efficient risk assessment of security critical systems. – To apply the framework in two security critical application domains: telemedicine and e-commerce. – To assess the applicability, usability, and efficiency of the framework. – To promote the exploitation potential of the CORAS framework. S. Anderson et al. (Eds.): SAFECOMP 2002, LNCS 2434, pp. 94–105, 2002. c Springer-Verlag Berlin Heidelberg 2002


The CORAS Framework for a Model-Based Risk Management Process

2

95

The CORAS Framework

This section provides a high-level overview of the CORAS framework for a modelbased risk management process. By ”a model-based risk management process” we mean a tight integration of state-of-the-art UML-oriented modelling technology (UML = Unified Modeling Language) [2] in the risk management process. The CORAS model-based risk management process employs modelling technology for three main purposes: – Providing descriptions of the target of analysis at the right level of abstraction. – As a medium for communication and interaction between different groups of stakeholders involved in a risk analysis. – To document results and the assumptions on which these results depend. A model-based risk management process is motivated by several factors: – Risk assessment requires correct descriptions of the target system, its context and all security relevant features. The modelling technology improves the precision of such descriptions. Improved precision is expected to improve the quality of risk assessment results. – The graphical style of UML furthers communication and interaction between stakeholders involved in a risk assessment. This is expected to improve the quality of results, and also speed up the risk identification and assessment process since the danger of wasting time and resources on misconceptions is reduced. – The modelling technology facilitates a more precise documentation of risk assessment results and the assumptions on which their validity depend. This is expected to reduce maintenance costs by increasing the possibilities for reuse. – The modelling technology provides a solid basis for the integration of assessment methods that should improve the effectiveness of the assessment process. – The modelling technology is supported by a rich set of tools from which the risk analysis may benefit. This may improve quality (as in the case of the two first bullets) and reduce costs (as in the case of the second bullet). It also furthers productivity and maintenance. – The modelling technology provides a basis for tighter integration of the risk management process in the system development process. This may considerably reduce development costs and ensure that the specified security level is achieved. The CORAS framework for a model-based risk management process has four main anchor-points, a system documentation framework based on the Reference Model for Open Distributed Processing (RM-ODP) [3], a risk management process based on the risk management standard AS/NZS 4360 [4], a system development process based on the Rational Unified Process (RUP) [5], and a platform

96

Rune Fredriksen et al.

for tool-integration based on eXtensible Markup Language (XML) [6]. In the following we describe the four anchor-points and the model-based risk management process in further detail. 2.1

The CORAS Risk Management Process

The CORAS risk management process provides a sequencing of the risk management process into the following five sub-processes: 1. Context Identification: Identify the context of the analysis that will follow. The approach proposed here is to select usage scenarios of the system under examination. 2. Risk Identification: Identify the threats to assets and the vulnerabilities of these assets. 3. Risk Analysis: Assign values to the consequence and the likelihood of occurrence of each threat identified in sub-process 2. 4. Risk Evaluation: Identify the level of risk associated with the threats already identified and assessed in the previous sub-processes 5. Risk Treatment: Address the treatment of the identified risks. The initial experimentation with UML diagrams can be summarised into the following: 1. UML use case diagrams support the identification of both the users of a system (actors) and the tasks (use cases) they must undertake with the system. UML scenario descriptions can be used to give more detailed input to the identification of different usage scenarios in the CORAS risk management process. 2. UML class/object diagrams identify the classes/objects needed to achieve the tasks, which the system must help to perform, and the relationships between the classes/objects. While class diagrams give the relationships between general classes, object diagrams present the instantiated classes. This distinction could be important when communicating with users of the system.

Sub-process 1: Identify context Sub-process 2: Identify risks Sub-process 3: Analyse Risks Sub-process 4: Risk Evaluation Sub-process 5: Risk Treatment

Fig. 1. Overview over the CORAS risk management process

The CORAS Framework for a Model-Based Risk Management Process

97

3. UML sequence diagrams describe some aspects of system behaviour by e.g. showing which messages are passed between objects and in what order they must occur. This gives a dynamic picture of the system and essential information to the identification of important usage scenarios. 4. UML activity diagrams describe how activities are co-ordinated and record the dependencies between activities. 5. UML state chart diagrams or UML activity diagrams can be used to represent state transition diagrams. The UML state chart diagram may be used to identify the sequence of state transitions that leads to a security break. 2.2

The CORAS System Documentation Framework

The CORAS system documentation framework is based on RM-ODP. RM-ODP defines the standard reference model for distributed systems architecture, based on object-oriented techniques, accepted at the international level. RM-ODP is adopted by ISO (ISO/IEC 10746 series: 1995) as well as by the International Telecommunication Union (ITU) (ITU-T X.900 series: 1995). As indicated by Figure 2, RM-ODP divides the system documentation into five viewpoints. It also provides modelling, specification and structuring terminology, a conformance module addressing implementation and consistency requirements, as well as a distribution module defining transparencies and functions required to realise these transparencies. The CORAS framework extends RM-ODP with: 1. Concepts and terminology for risk management and security. 2. Carefully defined viewpoint-perspectives targeting model-based risk management of security-critical systems. 3. Libraries of standard modelling components. 4. Additional support for conformance checking. 5. A risk management module containing risk assessment methods, risk management processes, and a specification of the international standards on which CORAS is based.

2.3

The CORAS Platform for Tool Integration

The CORAS platform is based on data integration implemented in terms of XML technology. Figure 3 outlines the overall structure. The platform is built up around an internal data representation formalised in XML/XMI (characterised by XML schema). Standard XML tools provide much of the basic functionality. This functionality allows experimentation with the CORAS platform and can be used by the CORAS crew during the trials. Based on the eXtensible Stylesheet Language (XSL), relevant aspects of the internal data representation may be mapped to the internal data representations of other tools (and the other way around). This allows the integration of sophisticated case-tools targeting system development as well as risk analysis tools and tools for vulnerability and treat management.

98

Rune Fredriksen et al.

Viewpoints enterprise

information computation engineering technology

ODP Foundations modelling, specification & structuring terminology

Conformance Module implementation & consistency requirements

Distribution Module transparencies & functions

Fig. 2. The main components of RM-ODP

2.4

The CORAS Model-Based Risk Management Process

The CORAS methodology for a model-based risk management process builds on: – – – – – –

HAZard and OPerability study (HAZOP) [7]; Fault Tree Analysis (FTA) [8]; Failure Mode and Effect Criticality Analysis (FMECA) [9]; Markov analysis methods (Markov) [10]; Goals Means Task Analysis (GMTA) [11]; CCTA Risk Analysis and Management Methodology (CRAMM) [12].

These methods are to a large extent complementary. They address confidentiality, integrity, availability as well as accountability; in fact, all types of risks, threats, hazards associated with the target system can potentially be revealed and dealt with. They also cover all phases in the system development and maintenance process. In addition to the selected methods other methods may also be needed to implement the different sub-processes in the CORAS risk management process. So far two additional methods have been identified. These are Cause-Consequence Analysis (CCA) [13] and Event-Tree Analysis (ETA) [13]. The CORAS risk management process tightly integrates state-of-the-art technology for semiformal object-oriented modelling. Modelling is not only used to provide a precise description of the target system, but also to describe its context and possible threats. Furthermore, description techniques are employed to document the risk assessment results and the assumptions on which these results

The CORAS Framework for a Model-Based Risk Management Process

99

The CORAS platform

XSL

Commercial modelling tools

XML internal representation

X SL

XML tools providing basic functionality

Commercial risk analysis tools

XSL

Commercial vulnerability and treat management tools

Fig. 3. The meta-model of the CORAS platform

depend. Finally, graphical UML-based modelling provides a medium for communication and interaction between different groups of stakeholders involved in risk identification and assessment. The following table gives a brief summary and a preliminary guideline to which methods that should be applied for which sub-process in the CORAS model-based risk management process. This guideline will be updated further during the progress of the CORAS project. Risk management requires a firm but nevertheless easily understandable basis for communication between different groups of stakeholders. Graphical objectoriented modelling techniques have proved well suited in this respect for requirements capture and analysis. We believe they are equally suited as a language for communication in the case of risk management. Entity relation diagrams, sequence charts, dataflow diagrams and state diagrams represent mature paradigms used daily in the IT industry throughout the world. They are supported by a wide set of sophisticated case-tool technologies, they are to a large extent complementary and, together they support all stages in a system development. Policies related to risk management and security are important input to risk assessment of security critical systems. Moreover, results from a risk assessment will often indicate the need for additional policies. Ponder [14] is a very expressive declarative, object-oriented language for specifying security and management policies for distributed systems. Ponder may benefit from an integration with graphical modelling techniques. Although the four kinds of graphical modelling techniques and Ponder are very general paradigms they do not always provide

100

Rune Fredriksen et al.

Table 1. How the RA methods apply to the CORAS risk management process Sub-process Goal Context Identification Identify the context of the analysis (e.g. areas of concern, assets and security requirements). Risk Identification Identify threats. Risk Analysis Find consequence and likelihood of occurence. Risk Evaluation Evaluate risk (e.g. risk level, prioritise, categorise, determine interrelationships and prioritise). Risk Treatment Identify treatment options and assess alternative approaches.

Recommended methods CRAMM, HAZOP

HAZOP FMECA, CCA, ETA CRAMM

HAZOP

the required expressiveness. Predicate logic based approaches like OCL [15] in addition to contract-oriented modelling are therefore also needed. 2.5

The CORAS System Development and Maintenance Process

The CORAS system development and maintenance process is based on an integration of the AS/NZS 4360 standard for risk management and an adaptation of the RUP for system development. RUP is adapted to support RM-ODP inspired viewpoint oriented modelling. Emphasis is placed on describing the evolution of the correlation between risk management and viewpoint oriented modelling throughout the system’s development and maintenance lifecycle. In analogy to RUP, the CORAS process is both stepwise incremental and iterative. In each phase of the system lifecycle, sufficiently refined versions of the system (or its model) are constructed through subsequent iterations. Then the system lifecycle moves from one phase into another. In analogy to the RM-ODP viewpoints, the viewpoints of the CORAS framework are not layered; they are different abstractions of the same system focusing on different areas of concern. Therefore, information in all viewpoints may be relevant to all phases of the lifecycle.

3

Standard Modeling Components

Much is common from one risk assessment to the next. CORAS aims to exploit this by providing libraries of reusable specification fragments targeting the risk management process and risk assessment. These reusable specification fragments are in the following referred to as standard modelling components. They will typically be UML diagrams annotated with constraints expressed in OCL

The CORAS Framework for a Model-Based Risk Management Process

101

(Object Constraint Language), or in for this purpose other suitable specification languages. The process of developing standard modelling components will continue in the CORAS project. In this phase the focus has been to: 1. Build libraries of standard modelling components for the various security models developed in CORAS. 2. Provide guidelines for the structuring and maintenance of standard modelling components. The following preliminary results and conclusions have been reached: 1. Standard modelling components may serve multiple purposes in a process for model-based risk management. They can represent general patterns for security architectures, or security policies. They can also represent the generic parts of different classes of threat scenarios, as well as schemes for recording risk assessment results and the assumptions on which they depend. 2. In order to make effective use of such a library, there is need for a computerised repository supporting standard database features like storage, update, rule-based use, access, search, maintenance, configuration management, version control, etc. 3. XMI offers a standardised textual XML-based representation of UML specifications. Since UML is the main modelling methodology of the CORAS framework and XML has been chosen as the main CORAS technology for tool integration, the repository should support XMI based exchange of models. 4. The UML meta-model is defined in Meta Object Facility (MOF) [16]. In relation to a CORAS repository, MOF may serve as a means to define a recommended subset of UML for expressing standard modelling components, required UML extensions to support a model-based risk management process, as well as the grammar of component packets. The repository should therefore be MOF based. 5. To support effective and smooth development of a consistent library, a single CORAS repository that all partners in the consortium may access via the Internet would be useful. 6. The OMG standards MOF and XMI ensure open access to the library and flexible exchange of standard modelling components between tools. There are already commercial tools for building repositories supporting MOF and XMI on the market; others are under development. The consortium will formalise the library of standard modelling components in terms of MOF and XMI using a suitable for this purpose UML CASE-tool.

4

The CORAS Trials

The trials in CORAS are performed within two different areas: e-commerce and telemedicine. The purpose of the trials is to experiment with all aspects of the

102

Rune Fredriksen et al.

Web Server

Web Client

Application Server

Data Storage

reqLogin() reqLogin() Create(sn) Add(sn) return(status) retLoginPage(sn) retLoginPage(sn)

Fig. 4. An example of the UML sequence diagram used in the trial

framework during its development, provide feedback for improvements and offer an overall assessment. The first e-commerce trial was based on the authentication mechanism. Among other models an indicative UML sequence diagram for starting the FMECA method, see Figure 4, was used. It is important to stress that the sequence diagram presented here is only one example of typical possible behaviours of the system. Scenarios like unsuccessful login, visitor accessing the platform, registration of new user, etc, could also be modelled. A more detailed description of the CORAS trials will be provided in the reports from the CORAS project. This trial was focused on the sub process 2 – identify risks, and to gain familiarity with use of CRAMM, HAZOP, FTA and FMECA for this purpose. The results from the first e-commerce trial are divided into four partly overlapping classes: 1. 2. 3. 4. 4.1

Experiences with the use of the specific risk analysis methods. Experiences from the overall process. Input to changes to the way the trials are performed. Input to minor changes of the CORAS risk management process. Experiences with the Use of the Specific Risk Analysis Methods

The individual methods used during the first e-commerce risk analysis trial session provided the following main results: – CRAMM was useful for identification of important system assets. – HAZOP worked well with security-related guidewords/attributes [17] that reflected the security issues addressed.

The CORAS Framework for a Model-Based Risk Management Process

103

– FTA was useful for structured/systematic risk analysis, but was timeconsuming and might present scalability problems. – FMEA worked well, but has to be well organised before it is applied and it