Using trust assumptions with security requirements

Assumptions are frequently made during requirements analysis of a system about the trustworthiness of its various components (including human components). These trust assumptions, whether implicit or explicit, affect the scope of the analysis, derivation of security requirements, and in some cases how functionality is realized. This paper presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the secure electronic transaction specification.

[1]  Ian F. Alexander,et al.  Initial industrial experience of misuse cases in trade-off analysis , 2002, Proceedings IEEE Joint International Conference on Requirements Engineering.

[2]  João Araújo,et al.  Modularisation and composition of aspectual requirements , 2003, AOSD '03.

[3]  Tadayoshi Kohno,et al.  Trust (and mistrust) in secure applications , 2001, CACM.

[4]  Marco Pistore,et al.  Model checking early requirements specifications in Tropos , 2001, Proceedings Fifth IEEE International Symposium on Requirements Engineering.

[5]  Simon Buckingham Shum,et al.  The Roots of Computer Supported Argument Visualization , 2003, Visualizing Argumentation.

[6]  Barry W. Boehm,et al.  Using WinWin Quality Requirements Management Tools: A Case Study , 2001, Ann. Softw. Eng..

[7]  Ana Moreira,et al.  Integrating the NFR framework in a RE model , 2004 .

[8]  Andreas L. Opdahl,et al.  Eliciting security requirements with misuse cases , 2004, Requirements Engineering.

[9]  Vasant Dhar,et al.  Supporting Systems Development by Capturing Deliberations During Requirements Engineering , 1992, IEEE Trans. Software Eng..

[10]  John A. Clark,et al.  Writing Effective Security Abuse Cases , 2004 .

[11]  Eric S. K. Yu,et al.  Towards modelling and reasoning support for early-phase requirements engineering , 1997, Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering.

[12]  Bashar Nuseibeh,et al.  Picking Battles: The Impact of Trust Assumptions on the Elaboration of Security Requirements , 2004, iTrust.

[13]  Luiz Marcio Cysneiros,et al.  Designing for privacy and other competing requirements , 2002 .

[14]  Axel van Lamsweerde,et al.  From system goals to intruder anti-goals: attack generation and resolution for security requirements engineering , 2003 .

[15]  Morris Sloman,et al.  Trust Management Tools for Internet Applications , 2003, iTrust.

[16]  Q. He.  A Framework for Modeling Privacy Requirements in Role Engineering , 2003 .

[17]  Bashar Nuseibeh,et al.  Deriving security requirements from crosscutting threat descriptions , 2004, AOSD '04.

[18]  Monroe County,et al.  Second Draft for Review , 2007 .

[19]  ZavePamela.  Classification of research efforts in requirements engineering , 1997 .

[20]  John Mylopoulos,et al.  Requirements Engineering Meets Trust Management: Model, Methodology, and Reasoning , 2004, iTrust.

[21]  Raymond McCall,et al.  Making Argumentation Serve Design , 1996, Hum. Comput. Interact..

[22]  Michael Jackson,et al.  Four dark corners of requirements engineering , 1997, TSEM.

[23]  Bashar Nuseibeh,et al.  Arguing security: validating security requirements using structured argumentation , 2005 .

[24]  M. Jarke,et al.  Requirements modeling for organization networks: a (dis)trust-based approach , 2001, Proceedings Fifth IEEE International Symposium on Requirements Engineering.

[25]  Haralambos Mouratidis,et al.  Analysing Security Requirements of Information Systems Using Tropos , 2003, ICEIS.

[26]  David G. Ullman,et al.  Design rationale: Concepts, techniques, and use , 1997 .

[27]  Bashar Nuseibeh,et al.  The effect of trust assumptions on the elaboration of security requirements , 2004, Proceedings. 12th IEEE International Requirements Engineering Conference, 2004..

[28]  Bashar Nuseibeh,et al.  Introducing abuse frames for analysing security requirements , 2003, Proceedings. 11th IEEE International Requirements Engineering Conference, 2003..

[29]  Ian Sommerville,et al.  Requirements Engineering: Processes and Techniques , 1998 .

[30]  Constance L. Heitmeyer.  Applying Practical Formal Methods to the Specification and Analysis of Security Properties , 2001, MMM-ACNS.

[31]  Haralambos Mouratidis,et al.  Integrating Security and Systems Engineering: Towards the Modelling of Secure Information Systems , 2003, CAiSE.

[32]  Ian F. Alexander,et al.  Modelling the Interplay of Conflicting Goals with Use and Misuse Cases , 2002, GBPM.

[33]  N. Mamode,et al.  Trust and mistrust , 1994 .

[34]  John Mylopoulos,et al.  Security and privacy requirements analysis within a social setting , 2003, Proceedings. 11th IEEE International Requirements Engineering Conference, 2003..

[35]  Axel van Lamsweerde,et al.  Goal-Oriented Requirements Engineering: A Guided Tour , 2001, RE.

[36]  Charles P. Pfleeger,et al.  Security in computing , 1988 .

[37]  Axel van Lamsweerde,et al.  Requirements engineering in the year 00: a research perspective , 2000, Proceedings of the 2000 International Conference on Software Engineering. ICSE 2000 the New Millennium.

[38]  John P. McDermott,et al.  Abuse-case-based assurance arguments , 2001, Seventeenth Annual Computer Security Applications Conference.

[39]  Stephen Fickas,et al.  Goal-Directed Requirements Acquisition , 1993, Sci. Comput. Program..

[40]  Donald Firesmith,et al.  Common Concepts Underlying Safety, Security, and Survivability Engineering , 2003 .

[41]  Jintae Lee,et al.  What's in Design Rationale? , 1991, Hum. Comput. Interact..

[42]  Premkumar T. Devanbu,et al.  Software engineering for security: a roadmap , 2000, ICSE '00.

[43]  H. Fuks,et al.  Multiparty specification , 1989, IWSSD '89.

[44]  John Mylopoulos,et al.  Requirement Engineering Meets Security: A Case Study on Modelling Secure Electronic Transactions by VISA and Mastercard , 2003, ER.

[45]  John Mylopoulos,et al.  Capturing more world knowledge in the requirements specification , 1982, ICSE '82.

[46]  Axel van Lamsweerde,et al.  Handling Obstacles in Goal-Oriented Requirements Engineering , 2000, IEEE Trans. Software Eng..

[47]  Matthias Jarke,et al.  Telos: representing knowledge about information systems , 1990, TOIS.

[48]  Ken Thompson,et al.  Reflections on trusting trust , 1984, CACM.

[49]  David C. Brown,et al.  AN INTEGRATED APPROACH FOR SOFTWARE DESIGN CHECKING USING DESIGN RATIONALE , 2004 .

[50]  Ramon Prudencio S. Toledo.  Visualizing Argumentation: Software Tools for Collaborative and Educational Sense-Making , 2005, Inf. Vis..

[51]  Axel van Lamsweerde,et al.  Elaborating security requirements by construction of intentional anti-models , 2004, Proceedings. 26th International Conference on Software Engineering.

[52]  John P. McDermott,et al.  Using abuse case models for security requirements analysis , 1999, Proceedings 15th Annual Computer Security Applications Conference (ACSAC'99).

[53]  Lin Liu,et al.  Modelling Trust for System Design Using the i* Strategic Actors Framework , 2000, Trust in Cyber-societies.

[54]  Colin Potts,et al.  Recording the reasons for design decisions , 1988, Proceedings. [1989] 11th International Conference on Software Engineering.

[55]  João Araújo,et al.  Early aspects: a model for aspect-oriented requirements engineering , 2002, Proceedings IEEE Joint International Conference on Requirements Engineering.

[56]  Bashar Nuseibeh,et al.  Core Security Requirements Artefacts , 2004 .