Security Engineering Using Problem Frames

  • Denis Hatebur
  • Maritta Heisel
  • Holger Schmidt
Part of the Lecture Notes in Computer Science book series (LNCS, volume 3995)


We present a method for security engineering, which is based on two special kinds of problem frames that serve to structure, characterize, analyze, and finally solve software development problems in the area of software and system security. Both kinds of problem frames constitute patterns for representing security problems, variants of which occur frequently in practice. We present security problem frames, which are instantiated in the initial step of our method. They explicitly distinguish security problems from their solutions. To prepare the solution of the security problems in the next step, we employ concretized security problem frames capturing known approaches to achieve security. Finally, the last step of our method results in a specification of the system to be implemented given by concrete security mechanisms and instantiated generic sequence diagrams. We illustrate our approach by the example of a secure remote display system.


Security Requirement Sequence Diagram Security Problem Problem Frame Security Engineering 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Anderson, R.: Security Engineering. Wiley, Chichester (2001)Google Scholar
  2. 2.
    Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice. Addison-Wesley, Reading (1998)Google Scholar
  3. 3.
    Blakley, B., Heath, C.: Technical Guide: Security Design Patterns. The Open Group (April 2004),
  4. 4.
    Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Chichester (1996)Google Scholar
  5. 5.
    Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns – Elements of Reusable Object-Oriented Software. Addison Wesley, Reading (1995)MATHGoogle Scholar
  6. 6.
    Hatebur, D., Heisel, M.: Problem Frames and Architectures for Security Problems. In: Winther, R., Gran, B.A., Dahll, G. (eds.) SAFECOMP 2005. LNCS, vol. 3688, pp. 390–404. Springer, Heidelberg (2005)CrossRefGoogle Scholar
  7. 7.
    Hatebur, D., Heisel, M., Schmidt, H.: Using problem frames for security engineering. Technical report, Universität Duisburg-Essen (2006),
  8. 8.
    International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC). Common criteria 2.3. ISO/IEC 15408 (2005),
  9. 9.
    International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC). Common evaluation methodology 2.3. ISO/IEC 18405 (2005),
  10. 10.
    Jackson, M.: Problem Frames. Analyzing and structuring software development problems. Addison-Wesley, Reading (2001)Google Scholar
  11. 11.
    Jackson, M., Zave, P.: Deriving specifications from requirements: an example. In: Proceedings 17th Int. Conf. on Software Engineering, Seattle, USA, pp. 15–24. ACM Press, New York (1995)Google Scholar
  12. 12.
    Lin, L., Nuseibeh, B., Ince, D., Jackson, M., Moffett, J.: Introducing abuse frames for analysing security requirements. In: Proceedings of 11th IEEE International Requirements Engineering Conference (RE 2003), pp. 371–372 (2003) (poster paper)Google Scholar
  13. 13.
    Pfleeger, C.P.: Security in Computing, 3rd edn. Prentice Hall, Englewood Cliffs (2003)Google Scholar
  14. 14.
    Schäfer, G.: Security in Fixed and Wireless Networks. John Wiley & Sons, Ltd, Chichester (2003)CrossRefGoogle Scholar
  15. 15.
    UML Revision Task Force. OMG Unified Modeling Language: Superstructure (August 2005),
  16. 16.
    Weisstein, E.W.: RSA-576 factored. MathWorld Headline News (2003),

Copyright information

© Springer-Verlag Berlin Heidelberg 2006

Authors and Affiliations

  • Denis Hatebur
    • 1
    • 2
  • Maritta Heisel
    • 2
  • Holger Schmidt
    • 2
  1. 1.Institut für technische Systeme GmbHGermany
  2. 2.Faculty of Engineering, Department of Computer Science, Workgroup Software EngineeringUniversity Duisburg-EssenGermany

Personalised recommendations