iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: https://unpaywall.org/10.1007/S00766-004-0194-4
Eliciting security requirements with misuse cases | Requirements Engineering Skip to main content

Advertisement

Log in

Eliciting security requirements with misuse cases

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

Use cases have become increasingly common during requirements engineering, but they offer limited support for eliciting security threats and requirements. At the same time, the importance of security is growing with the rise of phenomena such as e-commerce and nomadic and geographically distributed work. This paper presents a systematic approach to eliciting security requirements based on use cases, with emphasis on description and method guidelines. The approach extends traditional use cases to also cover misuse, and is potentially useful for several other types of extra-functional requirements beyond security.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Subscribe and save

Springer+ Basic
$34.99 /Month
  • Get 10 units per month
  • Download Article/Chapter or eBook
  • 1 Unit = 1 Article or 1 Chapter
  • Cancel anytime
Subscribe now

Buy Now

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Fig. 1
Fig. 2

Similar content being viewed by others

Notes

  1. Although the definitions and the metamodel in this section are aligned with the UML, misuse cases do not inherently depend on the UML and can augment other use case techniques equally well.

  2. For simplicity, we will use the term action sequence in this paper, although we often talk about sequences of both actions and interactions. Some authors prefer the term “step” where we use action.

  3. A corresponding abstract metaclass Actor Or Misuser is also possible.

  4. “Mitigate” replaces the “prevent” and “detect” relationships, and “threaten” replaces the “extend” and “include” relationships defined in [17], following a suggestion made by Alexander [22] in both cases.

  5. The common criteria is intended as a security evaluation standard, but because it is organized according to classes, families, and components of security criteria, and because security criteria can be seen as operational security goals, the common criteria also entails a typology of security goals.

  6. Most of the techniques and methods proposed in this paper may apply equally well to unintentional harm, but that would lead us into the area of safety requirements. The definition of misuse cases given in Sect. 2 explicitly allows for both intentional and inadvertent—or unintentional—misuse.

  7. Project 508011 INTEROP (Interoperability Research for networked enterprises, applications, and software) is a network of excellence under the sixth framework program (IST). It has 50 partners from various European countries.

  8. The CORAS project (IST-2000-25031) addressed risk assessment of security critical systems. It had 11 partners from four countries (UK, Germany, Greece, and Norway). The technical coordinator was SINTEF (N) and the administrative coordinator was Telenor (N). The project was successfully completed in September 2003.

  9. The design angle is particularly evident in [20], where assurance arguments are used to show that the design really satisfies the requirements.

  10. Finally, there are differences in the textual templates: our template describes misuse case actions, exceptions, mitigations, etc. in more detail, whereas McDermott and Fox’ [19] templates provide more detail about the attacker.

References

  1. Jacobson I et al (1992) Object-oriented software engineering: a use case driven approach. Addison-Wesley, Boston

  2. Constantine LL, Lockwood LAD (1999) Software for use: a practical guide to the models and methods of usage-centered design. ACM Press, New York

    Google Scholar 

  3. Cockburn A (2001) Writing effective use cases. Addison-Wesley, Boston

  4. Rumbaugh J (1994) Getting started: using use cases to capture requirements. J Object Orient Prog 7(5):8–23

    Google Scholar 

  5. Kulak D, Guiney E (2000) Use cases: requirements in context. ACM Press, New York

    Google Scholar 

  6. Weidenhaupt K et al (1998) Scenario usage in system development: a report on current practice. IEEE Software 15(2):34–45

    Article  Google Scholar 

  7. Arlow J (1998) Use cases, UML visual modelling and the trivialisation of business requirements. Req Eng 3(2):150–152

    Google Scholar 

  8. Lilly S (1999) Use case pitfalls: top 10 problems from real projects using use cases. In: Proceedings of TOOLS USA 1999, IEEE Computer Society, Santa Barbara, California

  9. Anton AI et al (2001) Deriving goals from a use case based requirements specification. Req Eng 6(1):63–73

    Google Scholar 

  10. CCIMB (1999) Common criteria for information technology security evaluation. Technical report, CCIMB-99–031, Common Criteria Implementation Board

  11. ECMA (1999) ECMA protection profile: E-COFC public business class. Technical report, TR/78, ECMA International, Geneva, Switzerland

    Google Scholar 

  12. Crook R et al (2002) Security requirements engineering: when anti-requirements hit the fan. In: Proceedings of the 10th anniversary IEEE international requirements engineering conference (RE‘02), Essen, Germany

  13. Pohl K (1994) The three dimensions of requirements engineering: a framework and its applications. Inform Syst 19(3):243–258

    Article  Google Scholar 

  14. Loucopoulos P, Karakostas V (1995) Systems requirements engineering. McGraw-Hill, London

  15. Kotonya G, Sommerville I (1997) Requirements engineering: processes and techniques. Wiley, Chichester

    Google Scholar 

  16. Mylopoulos J, Chung L, Yu E (1999) From object-oriented to goal-oriented requirements analysis. Commun ACM 42(1):31–37

    Article  Google Scholar 

  17. Sindre G, Opdahl AL (2000) Eliciting security requirements by misuse cases. In: Proceedings of TOOLS Pacific 2000, Sydney, Australia

  18. Sindre G, Opdahl AL (2001) Templates for misuse case description. In: Proceedings of the 7th international workshop on requirements engineering: foundation for software quality (REFSQ’01), Interlaken, Switzerland

  19. McDermott J, Fox C (1999) Using abuse case models for security requirements analysis. In: Proceedings of the 15th annual computer security applications conference (ACSAC’99), Phoenix, Arizona

  20. McDermott J (2001) Abuse-case-based assurance arguments. In: Proceedings of the 17th annual computer security applications conference (ACSAC’01), New Orleans, Los Angeles

  21. Potts C (2001) Scenario noir (panel statement, p 2). In: Proceedings of the symposium on requirements engineering for information security (SREIS’01), Indianapolis

  22. Alexander IF (2002) Initial industrial experience of misuse cases in trade-off analysis. In: Proceedings of the 10th anniversary IEEE international requirements engineering conference (RE’02), Essen, Germany

  23. Alexander IF (2002) Modelling the interplay of conflicting goals with use and misuse cases. In: Proceedings of the 8th international workshop on requirements engineering: foundation for software quality (REFSQ’02), Essen, Germany

  24. Alexander IF (2003) Misuse cases, use cases with hostile intent. IEEE Software 20(1):58–66

    Article  Google Scholar 

  25. Ellison R et al (1999) Survivable network system analysis: a case study. IEEE Software 16(4):70–77

    Article  Google Scholar 

  26. Firesmith D (2003) Security use cases. J Object Tech 2(3):53–64

    Google Scholar 

  27. OMG (2003) Unified modeling language, version 1.5. Object Management Group, Inc. http://www.uml.org. Cited 21 Nov 2003

  28. Sindre G, Opdahl AL, Breivik GF (2002) Generalization/specialization as a structuring mechanism for misuse cases. In: Proceedings of the 2nd symposium on requirements engineering for information security (SREIS’02), Raleigh, North Carolina

  29. Kruchten P (2000) The rational unified process—an introduction. Addison-Wesley, Boston

  30. Sindre G, Firesmith D, Opdahl AL (2003) A reuse-based approach to determining security requirements. In: Proceedings of the 9th international workshop on requirements engineering: foundation for software quality (REFSQ’03), Klagenfurt, Austria

  31. Viega J, McGraw G (2002) Building secure software: how to avoid security problems the right way. Addison-Wesley, Boston

    Google Scholar 

  32. Andress M (2002) Surviving security: how to integrate people, process, and technology. Sams Publishing, Indianapolis

    Google Scholar 

  33. Devanbu PT, Stubblebine S (2000) Software engineering for security: a roadmap. In: Proceedings of the 22nd international conference on software engineering (ICSE 2000), future of software engineering track, Limerick, Ireland

  34. Carroll JM, Swatman PA (1999) Managing the RE process: lessons from commercial practice. In: Proceedings of the 5th international workshop on requirements engineering: foundations of software quality (REFSQ’99), Heidelberg, Germany

  35. den Braber F et al (2002) Model-based risk management using UML and UP. In: Proceedings of the 13th IRMA international conference: issues and trends of information technology management in contemporary organizations (IRMA’2002), Seattle, Washington

  36. Houmb S-H et al (2002) Towards a UML profile for model-based risk assessment. In: Proceedings of the UML’2002 satellite workshop on critical systems development with UML (CSD-UML’02), Dresden, Germany

  37. Breivik GF (2002) Abstract misuse patterns—a new approach to security requirements. Masters thesis, Department of Information Science, University of Bergen

  38. OWASP (2001) Application security attack components. The open web application security project. http://www.owasp.org/asac/. Cited 21 Sept 2002

  39. Hickey A, Davis AM (2003) Elicitation technique selection: how do experts do it? In: Proceedings of the 11th IEEE international requirements engineering conference (RE’03), Monterey, California

  40. Coughlan J, Macredie RD (2002) Effective communication in requirements elicitation: a comparison of methodologies. Req Eng 7:47–60

    Article  Google Scholar 

  41. Potts C (1995) Using schematic scenarios to understand user needs. In: Proceedings of the ACM symposium on designing interactive systems: processes, practices, and techniques (DIS’95), Ann Arbor, Michigan

  42. Anton AI, Earp JB (2000) Strategies for developing policies and requirements for secure electronic commerce systems. In: Proceedings of the 1st ACM workshop on security and privacy in e-commerce, Athens, Greece

  43. van Lamsweerde A, Letier E (2000) Handling obstacles in goal-oriented requirements engineering. IEEE T Software Eng 26(10):978–1005

    Article  Google Scholar 

  44. Maiden NAM et al (1998) CREWS-SAVRE: systematic scenario generation and use. In: Proceedings of the 3rd IEEE international conference on requirements engineering (ICRE’98), Colorado Springs, Colorado

  45. Rolland C, Souveyet C, Achour-Salinesi CB (1998) Guiding goal models using scenarios. IEEE T Software Eng 24(12):1055–1071

    Article  Google Scholar 

  46. Achour-Salinesi CB et al (1999) Guiding use case authoring: results from an empirical study. In: Proceedings of the 4th international symposium on requirements engineering (RE’99), Limerick, Ireland

  47. Abrahamsson P et al (2003) New directions on agile methods: a comparative analysis. In: Proceedings of the 25th international conference on software engineering (ICSE’03), Portland, Oregon

  48. Liu L et al (2003) Security and privacy requirements analysis within a social setting. In: Proceedings IEEE international conference on requirements engineering (RE’03), Monterey, California

  49. Amoroso EJ (1994) Fundamentals of computer security technology. Prentice-Hall, Englewood Cliffs

  50. Schneier B (2000) Secrets and lies: digital security in a networked world. Wiley, Chichester

    Google Scholar 

  51. Moberg F (2000) Security analysis of an information system using an attack tree-based methodology. Masters thesis, Chalmers University of Technology

  52. Chung L et al (2000) Non-functional requirements in software engineering. Kluwer, Boston

  53. Lutz RR (2000) Software engineering for safety: a roadmap. In: Finkelstein A (ed) The future of software engineering, ACM Press, New York

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Guttorm Sindre.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Sindre, G., Opdahl, A.L. Eliciting security requirements with misuse cases. Requirements Eng 10, 34–44 (2005). https://doi.org/10.1007/s00766-004-0194-4

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-004-0194-4

Keywords

Navigation