Identifying Security Requirements and Privacy Concerns in Digital Health Applications

  • Gerd Stefan Brost
  • Mario Hoffmann


Security and privacy by design are important paradigms for establishing high protection levels in the eHealth domain. This means that security requirements and privacy concerns are considered and analyzed from the very beginning of any system design. For a reliable and robust system architecture and specification we recommend a four-step approach: (1) Decompose the system and identify the assets on the basis of the multilateral security concept, i.e., taking all participants of an eHealth scenario as potential attackers into account; (2) evaluate threats based on STRIDE for a holistic and systematic modelling of threats; (3) define use case-specific security requirements and privacy concerns as well as their relevance; and (4) mitigate threats by deciding what countermeasures should be implemented. After the introduction of each step this chapter illustrates the practical use in a step-by-step walkthrough with a real-world eHealth scenario and discusses advantages of security and privacy by design as well as its limitations.


  1. 1.
  2. 2.
    Lymberis A, De Rossi DE (2004) Wearable eHealth systems for personalised health management: state of the art and future challenges. Ios Press, AmsterdamGoogle Scholar
  3. 3.
    Vital Wave Consulting (2009) mHealth for development: the opportunity of mobile technology for healthcare in the developing world. United Nations Foundation, Washington, DCGoogle Scholar
  4. 4.
    Ruotsalainen P, Blobel B, Seppälä A (2012) A conceptual framework and principles for trusted pervasive health. J Med Internet Res 14:e52CrossRefGoogle Scholar
  5. 5.
    Hsu C-L, Lee M-RS-H (2013) The role of privacy protection in healthcare informatipn systems adoption. J Med Syst 37(5):1–12Google Scholar
  6. 6.
    Cavoukian A, Chanliau M (2013) Privacy and security by design: a convergence of paradigmsGoogle Scholar
  7. 7.
    Müller G, Rannenberg K (2004) Multilateral security in communications. Addison-Wesley, Reading, MAGoogle Scholar
  8. 8.
    Anderson RJ (2008) Security engineering: a guide to building dependable distributed systems. Wiley, New York, NYGoogle Scholar
  9. 9.
    McCumber J (1991) Information systems security: a comprehensive model. Proceedings of the 14th national computer security conference, Washington, DC, 1–4 October 1991Google Scholar
  10. 10.
    Zhou J, Gollmann D (1996) Observations on non-repudiation. In: Advances in cryptology. Springer, New York, NYGoogle Scholar
  11. 11.
  12. 12.
    McDermott J, Fox C (1999) Using abuse case models for security requirements analysis. 15th Annual computer security applications conference. Phoenix, ArizonaGoogle Scholar
  13. 13.
    Sindre G, Opdahl A (2005) Eliciting security requirements with misuse cases. Requir Eng 10:34–44CrossRefGoogle Scholar
  14. 14.
    Dolev D, Yao A (1983) On the security of public key protocols. In: Information theory. IEEE, Washington, DC, pp 198–208Google Scholar
  15. 15.
    Roscoe, B. (2003). The attacker in ubiquitous computing environments: formalising the threat model. Proc. of the 1st Intl workshop on formal aspects in security and trust, ItalyGoogle Scholar
  16. 16.
    Schneier B (1999) Attack trees. Dobb J 24:21–29Google Scholar
  17. 17.
    Tatat Ü, Karabacak B (2012) An hierarchical asset valuation method for information security risk analysis. International conference on information society, 25–28 June 2012, London, pp 286–291.Google Scholar
  18. 18.
    Firesmith DG (2003) Engineering security requirements. J Obj Tech 2:53–68Google Scholar
  19. 19.
    BSI (2014) Kryptographische Verfahren: Empfehlungen und Schlüssellängen.Google Scholar
  20. 20.
    ENISA (2013) Algorithms, key size and parameters reportGoogle Scholar
  21. 21.
    Barker E, Roginsky A (2011) Transitions: recommendation for the use of cryptographic algorithms and key lenghts. NIST, Gaithersburg, MDGoogle Scholar
  22. 22.
    Fricker S, Thümmler C (2014) Technical requirements and architecture report including open call requirements. Technical Report. Accessed on 1 May, 2014, from
  23. 23.
    Fricker S, Gorschek T, Byman C, Schmidle A (2010) Handshaking with implementation proposals: Negotiating requirements understanding. IEEE Software 27(2):72–80Google Scholar

Copyright information

© Springer International Publishing Switzerland 2015

Authors and Affiliations

  1. 1.Fraunhofer AISECMunichGermany

Personalised recommendations