Skip to main content
Log in

Automating trade-off analysis of security requirements

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

Abstract

A key aspect of engineering secure systems is identifying adequate security requirements to protect critical assets from harm. However, security requirements may compete with other requirements such as cost and usability. For this reason, they may only be satisfied partially and must be traded off against other requirements to achieve “good-enough security”. This paper proposes a novel approach to automate security requirements analysis in order to determine maximum achievable satisfaction level for security requirements and identify trade-offs between security and other requirements. We also propose a pruning algorithm to reduce the search space size in the analysis. We represent security concerns and requirements using asset, threat, and goal models, initially proposed in our previous work. To deal with uncertainty and partial requirements, satisfaction security concerns are quantified by leveraging the notion of composite indicators, which are computed through metric functions based on range normalisation. An SMT solver (Z3) interprets the models and automates the execution of our analyses. We illustrate and evaluate our approach by applying it to a substantive example of a service-based application for exchanging emails.

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

Access this article

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

Instant access to the full article PDF.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8

Similar content being viewed by others

Notes

  1. The root goals of Figs. 4 and 6 must be considered as sharing the same “father” goal, which has been omitted in the paper.

  2. A complete formalisation of the case study can be found at https://sites.google.com/site/resexperiments/.

  3. \(R\) cannot include AGGR refinements since, from a modelling point of view, aggregation of domain assumptions, which are boolean variables, is meaningless.

  4. The complete set of experiments can be found at https://sites.google.com/site/resexperiments/.

  5. http://research.microsoft.com/en-us/um/redmond/projects/z3/mcmaster07.pdf.

References

  1. Amyot D, Ghanavati S, Horkoff J, Mussbacher G, Peyton L, Yu ESK (2010) Evaluating goal models within the goal-oriented requirement language. Int J Intell Syst 25(8):841–877

    Article  Google Scholar 

  2. Asnar Y, Giorgini P, Mylopoulos J (2011) Goal-driven risk assessment in requirements engineering. Requir Eng 16(2):101–116

    Article  Google Scholar 

  3. Barone D, Jiang L, Amyot D, Mylopoulos J (2011) Reasoning with key performance indicators. In: Proceedings of the 4th IFIP WG 8.1 working conference on the practice of enterprise modeling, Springer, Berlin, pp 82–96

  4. Boehm B, Bose P, Horowitz E, Lee MJ (1994) Software requirements as negotiated win conditions. In: Proceeding of the 1st international requirements engineering conference, pp 74–83

  5. Cailliau A, van Lamsweerde A (2013) Assessing requirements-related risks through probabilistic goals and obstacles. Requir Eng 18(2):129–146

    Article  Google Scholar 

  6. De Moura L, Bjørner N (2008) Z3: an efficient SMT solver. In: Proceedings of the 14th international conference on tools and algorithms for the construction and analysis of systems, pp 337–340

  7. Elahi G, Yu ESK (2007) A goal oriented approach for modeling and analyzing security trade-offs. In: Proceedings of the 26th international conference on conceptual modeling. Springer, Berlin, pp 375–390

  8. Feather MS, Cornford SL, Hicks KA, Kiper JD, Menzies T (2008) A broad, quantitative model for making early requirements decisions. IEEE Softw 25(2):49–56

    Article  Google Scholar 

  9. Firesmith D (2004) Specifying reusable security requirements. J Object Technol 3(1):61–75

    Article  Google Scholar 

  10. Franqueira VNL, Tun TT, Yu Y, Wieringa R, Nuseibeh B (2011) Risk and argument: a risk-based argumentation method for practical security. In: Proceedings of the 19th international requirements engineering conference, pp 239–248

  11. Giorgini P, Massacci F, Mylopoulos J, Zannone N (2005) Modeling security requirements through ownership, permission and delegation. In: Proceedings of the 13th international requirements engineering conference. IEEE Computer Society, pp 167–176

  12. Giorgini P, Mylopoulos J, Nicchiarelli E, Sebastiani R (2003) Formal reasoning techniques for goal models. In: Spaccapietra S, March S, Aberer K (eds) Journal on data semantics I. Lecture notes in computer science. Springer, Heidelberg, pp 1–20

    Chapter  Google Scholar 

  13. Glinz M (2007) On non-functional requirements. In: Proceedings of the 15th international requirements engineering conference. IEEE Computer Society, pp 21–26

  14. Haley CB, Laney RC, Moffett JD, Nuseibeh B (2008) Security requirements engineering: a framework for representation and analysis. IEEE Trans Softw Eng 34(1):133–153

    Article  Google Scholar 

  15. Heaven W, Letier E (2011) Simulating and optimising design decisions in quantitative goal models. In: Proceedings of the 19th international requirements engineering conference, pp 79–88

  16. Hoffman S (2012) Kaspersky: malware attachments up 50 percent. http://channelnomics.com/2012/08/24/kaspersky-malicious-attachments-50-percent/

  17. Horkoff J, Yu ESK (2013) Comparison and evaluation of goal-oriented satisfaction analysis techniques. Requir Eng 18(3):199–222

    Article  Google Scholar 

  18. Houmb S, Georg G, Jürjens J, France R (2007) An integrated security verification and security solution design trade-off analysis approach. In: Integrating security and software engineering: advances and future visions, pp 190–219

  19. In HP, Olson D (2004) Requirements negotiation using multi-criteria preference analysis. J Univ Comput Sci 10(4):306–325

    Google Scholar 

  20. ISO/IEC 13335–1:2004: Information Technology (2008) Security techniques—management of information and communications technology security—part 1: concepts and models for information and communications technology security management. http://www.iso.org/iso/catalogue_detail.htm?csnumber=39066

  21. Jürjens J (2002) UMLsec: extending UML for secure systems development. In: Proceedings of the 5th international conference on the unified modeling language, pp 412–425

  22. Kaiya H, Horai H, Saeki M (2002) AGORA: attributed goal-oriented requirements analysis method. In: Proceedings of the 20th international requirements engineering conference

  23. Karlsson J, Ryan K (1997) A cost-value approach for prioritizing requirements. IEEE Softw 14(5):67–74

    Article  Google Scholar 

  24. Lawrence C, Nixon BA, Mylopoulos J (1999) Non-functional requirements in software engineering. Kluwer, Dordrecht

    MATH  Google Scholar 

  25. Lee S (2011) Probabilistic risk assessment for security requirements: a preliminary study. In: Proceedings of the 5th international conference on secure software integration and reliability improvement. IEEE Computer Society, pp 11–20

  26. Letier E, van Lamsweerde A (2004) Reasoning about partial goal satisfaction for requirements and design engineering. In: Proceedings of the international symposium on foundation of software engineering, pp 53–62

  27. Liu L, Yu ESK, Mylopoulos J (2003) Security and privacy requirements analysis within a social setting. In: Proceedings of the 11th international requirements engineering conference. IEEE Computer Society, pp 151–161

  28. Lodderstedt T, Basin DA, Doser J (2002) SecureUML: a UML-based modeling language for model-driven security. In: Proceedings of the 5th international conference on the unified modeling language, pp 426–441

  29. Łukasiewicz J (1970) Selected works by Jan Łukasiewicz, chap. on three-valued logic. North-Holland, Amsterdam

    Google Scholar 

  30. McDermott JP, Fox C (1999) Using abuse case models for security requirements analysis. In: Proceedings of the 15th annual computer security applications conference. IEEE Computer Society, pp 55–64

  31. Messaging Anti-Abuse Working Group (MAAWG): Email Metrics Program: The Network Operators’ Perspective, Report 15—first, second and third quarter 2011 (2012). http://www.maawg.org/sites/maawg/files/news/MAAWG_2011_Q1Q2Q3_Metrics_Report_15.pdf

  32. Mills E (2010) The unvarnished truth about unsecured Wi-Fi. http://news.cnet.com/8301-27080_3-20021188-245.html

  33. Mouratidis H, Giorgini P (2007) Secure tropos: a security-oriented extension of the tropos methodology. Int J Softw Eng Knowl Eng 17(2):285–309

    Article  Google Scholar 

  34. Nieuwenhuis R, Oliveras A (2006) On SAT modulo theories and optimization problems. In: Proceedings of the 9th international conference on theory and applications of satisfiability testing, pp 156–169

  35. Pfleeger CP, Pfleeger SL (2003) Security in computing. Prentice Hall Professional, Englewood Cliffs

    MATH  Google Scholar 

  36. Salehie M, Pasquale L, Inah O, Ali R, Nuseibeh B (2012) Requirements-driven adaptive security: protecting variable assets at runtime. In: Proceedings of the 20th international requirements engineering conference. IEEE Computer Society, pp 111–120

  37. Stoneburner G, Goguen A, Feringa A (2002) Risk management guide for information technology systems. Nist Spec Publ 800(30):800–830

    Google Scholar 

  38. Tracy M, Jansen W, Bisker S (2002) Guidelines on electronic mail security. NIST Special Publication, Gaithersburg, pp 45–800

    Book  Google Scholar 

  39. US General Services Administration: Email as a Service (EaaS) Blanket Purchase Agreement (BPA) Requirements Document. (2013). www.gsa.gov/portal/content/112223

  40. van Lamsweerde A (2004) Elaborating security requirements by construction of intentional anti-models. In: Proceedings of the 26th international conference on software engineering. IEEE Computer Society, pp 148–157

  41. van Lamsweerde A (2009) Requirements engineering—from system goals to UML models to software specifications. Wiley, London

    Google Scholar 

  42. Wunder J, Halbardier A, Waltermire D (2011) Specification for asset identification 1.1. Tech. Rep. 7693, NIST

  43. Yen J, Tiao W (1997) A systematic tradeoff analysis for conflicting imprecise requirements. In: Proceedings of the 3rd international symposium on requirements engineering, pp 87–96

  44. Zadeh LA (1965) Fuzzy sets. Inf Control 8(3):338–353

    Article  MathSciNet  MATH  Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Paola Spoletini.

Appendix: Strength levels of security controls

Appendix: Strength levels of security controls

Figure 9 and Table 7 describe the meaning of different strength levels that can be assigned to those security controls that cannot just be enabled/disabled. We assume that a security control with strength level equal to \(0\) is disabled. \({SC}_1\) aims to limit the duration of a session related to the usage of the email service; increasing strength levels are associated with progressively decreasing session lengths, which are expressed in minutes (min). \({SC}_4\) aims to apply multi-factors authentication, and its strength level depends on the number of authentication factors adopted. Increasing strength levels are associated with an increasing number of factors. \({SC}_5\) aims to increase the frequency of credential renewal; increasing strength levels are associated with progressively increasing frequencies, which are expressed in days. \({SC}_8\) aims to encrypt transmitted email messages; increasing strength levels are associated with increasing encryption key lengths. \({SC}_{12}\) and \({SC}_{13}\) aim to apply patch updates to the retrieval and SMTP email server, respectively. Increasing strength levels are associated with progressively increasing frequencies of patch updates, which are expressed in days. \({SC}_{14}\) and \({SC}_{15}\) aim to filter incoming email messages depending on its sender and content, respectively. When a low strength level is applied (\(0.3\)), suspicious messages, i.e. those matching the filtering conditions, are only required to be reviewed by its recipients, without being blocked. When a medium strength level is applied (0.6), suspicious messages are put in quarantine. While when a high strength level is assigned (1.0), suspicious messages are blocked without requiring the recipient authorisation. Finally, \({SC}_{16}\) aims to avoid short password; increasing strength levels are associated with progressively increasing password lengths.

Fig. 9
figure 9

Meaning of strength level of security controls SC1, SC5, SC12, SC13, and SC16

Table 7 Meaning of strength levels (sl) of security controls SC4, SC8, SC14, and SC15

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Pasquale, L., Spoletini, P., Salehie, M. et al. Automating trade-off analysis of security requirements. Requirements Eng 21, 481–504 (2016). https://doi.org/10.1007/s00766-015-0229-z

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-015-0229-z

Keywords

Navigation