This Article 
   
 Share 
   
 Bibliographic References 
   
 Add to: 
 
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
 
 Search 
   
Security Requirements Engineering: A Framework for Representation and Analysis
January 2008 (vol. 34 no. 1)
pp. 133-153
ASCII Text
x 
 
Charles Haley, Robin Laney, Jonathan Moffett, Bashar Nuseibeh, "Security Requirements Engineering: A Framework for Representation and Analysis," IEEE Transactions on Software Engineering, vol. 34, no. 1, pp. 133-153, January, 2008.
 
 
BibTex
x
 
@article{ 10.1109/TSE.2007.70754,
author = {Charles Haley and Robin Laney and Jonathan Moffett and Bashar Nuseibeh},
title = {Security Requirements Engineering: A Framework for Representation and Analysis},
journal ={IEEE Transactions on Software Engineering},
volume = {34},
number = {1},
issn = {0098-5589},
year = {2008},
pages = {133-153},
doi = {http://doi.ieeecomputersociety.org/10.1109/TSE.2007.70754},
publisher = {IEEE Computer Society},
address = {Los Alamitos, CA, USA},
}
 
 
RefWorks Procite/RefMan/Endnote
x 
 
TY - JOUR
JO - IEEE Transactions on Software Engineering
TI - Security Requirements Engineering: A Framework for Representation and Analysis
IS - 1
SN - 0098-5589
SP133
EP153
EPD - 133-153
A1 - Charles Haley,
A1 - Robin Laney,
A1 - Jonathan Moffett,
A1 - Bashar Nuseibeh,
PY - 2008
KW - Software/Software Engineering
KW - Requirements/Specifications
KW - Security
VL - 34
JA - IEEE Transactions on Software Engineering
ER -
 
This paper presents a framework for security requirements elicitation and analysis, based upon the construction of a context for the system, representation of security requirements as constraints, and satisfaction arguments for the requirements in the system context. The system context is described using a problem-centered notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument is in two parts: a formal argument that the system can meet its security requirements, and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context, or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project.

[1] I. Alexander, “Misuse Cases in Systems Engineering,” Computing and Control Eng. J., vol. 14, no. 1, pp. 40-45, Feb. 2003.
[2] J.H. Allen, “CERT System and Network Security Practices,” Proc. Fifth Nat'l Colloquium Information Systems Security Education, 2001.
[3] R. Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems, 2001.
[4] A.I. Antón and J.B. Earp, “Strategies for Developing Policies and Requirements for Secure E-Commerce Systems,” E-Commerce Security and Privacy, vol. 2, Advances In Information Security, A.K. Ghosh, eds., pp. 29-46, Kluwer Academic, 2001.
[5] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing,” IEEE Trans. Dependable and Secure Computing, vol. 1, no. 1, pp. 11-33, Jan.-Mar. 2004.
[6] T.D. Breaux, M.W. Vail, and A.I. Antón, “Towards Regulatory Compliance: Extracting Rights and Obligations to Align Requirements with Regulations,” Proc. 14th IEEE Int'l Requirements Eng. Conf., pp. 46-55, 2006.
[7] D.F.C. Brewer and M.J. Nash, “The Chinese Wall Security Policy,” Proc. 1989 IEEE Symp. Security and Privacy, pp. 206- 214, 1989.
[8] S.J. Buckingham Shum, “The Roots of Computer Supported Argument Visualization,” Visualizing Argumentation: Software Tools for Collaborative and Educational Sense-Making, P.A. Kirschner, S.J. Buckingham Shum, and C.S. Carr, eds., pp. 3-24, Springer-Verlag, 2003.
[9] J.E. Burge and D.C. Brown, “An Integrated Approach for Software Design Checking Using Design Rationale,” Proc. First Int'l Conf. Design Computing and Cognition, J.S. Gero, ed., pp. 557-576, 2004.
[10] S. Capkun and J.-P. Hubaux, “Securing Position and Distance Verification in Wireless Networks,” Technical Report EPFL/IC/200443, Swiss Federal Inst. of Technology Lausanne, May 2004.
[11] “Australian Technical Standard Order: Airborne Stand-Alone Extended Squitter, Automatic Dependent Surveillance-Broadcast (ADS-B), Transmit Only Equipment,” Australian Civil Aviation Safety Authority, Standard ATSO-C1005, CASA, Dec. 2004.
[12] “CERT/CC Statistics 1988-2005,” Pittsburgh, CERT CC, http://www.cert.org/statscert_stats.html , Feb. 2006.
[13] F. Cervo, “Airborne Separation Assistance Systems,” EUROCONTROL, 2005, Newsletter, http://www.eurocontrol.int/mil/public /standard_page newsletter0605art2.html, Sept. 2006.
[14] H. Chivers and M. Fletcher, “Applying Security Design Analysis to a Service-Based System,” Software: Practice and Experience, vol. 35, no. 9, pp. 873-897, 2005.
[15] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, Non-Functional Requirements in Software Engineering. Kluwer Academic, 2000.
[16] Common Criteria Sponsoring Organizations, “Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model, Version 3.1 Rev 1,” Nat'l Inst. of Standards and Technology CCMB-2006-09-001, Sept. 2006.
[17] Common Criteria Sponsoring Organizations, “Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Components, Version 3.1 Rev 1,” Nat'l Inst. of Standards and Technology CCMB-2006-09-002, Sept. 2006.
[18] Common Criteria Sponsoring Organizations, “Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Components, Version 3.1 Rev 1,” Nat'l Inst. Standards and Technology CCMB-2006-09-003, Sept. 2006.
[19] “Compendium,” http:/www.compendiuminstitute.org/, Compendium Inst., 2005.
[20] J. Conklin, “Dialog Mapping: Reflections on an Industrial Strength Case Study,” Visualizing Argumentation: Software Tools for Collaborative and Educational Sense-Making, P.A. Kirschner, S.J. Buckingham Shum, and C.S. Carr, eds., pp. 117-136, Springer-Verlag, 2003.
[21] E. Dash, “Weakness in the Data Chain,” New York Times, 2005.
[22] R. De Landtsheer and A. van Lamsweerde, “Reasoning About Confidentiality at Requirements Engineering Time,” Proc. 10th European Software Eng. Conf. (ESEC-FSE'05) with 13th ACM SIGSOFT Int'l Symp. Foundations of Software Eng., pp. 41-49, 2005.
[23] P. Devanbu and S. Stubblebine, “Software Engineering for Security: A Roadmap,” The Future of Software Eng., A. Finkelstein, ed., ACM Press, 2000.
[24] “Matter of CardSystems Solutions Inc.,” Washington, D.C., Federal Trade Commission, 2006.
[25] A. Finkelstein and H. Fuks, “Multiparty Specification,” Proc. Fifth Int'l Workshop Software Specification and Design, pp. 185-195, 1989.
[26] D.G. Firesmith, “Common Concepts Underlying Safety, Security, and Survivability Engineering,” Technical Report CMU/SEI-2003-TN-033, Software Eng. Inst., Carnegie Mellon Univ., Dec. 2003.
[27] D.G. Firesmith, “Specifying Reusable Security Requirements,” J.Object Technology, vol. 3, no. 1, pp. 61-75, Jan.-Feb. 2004.
[28] G. Fischer, A.C. Lemke, R. McCall, and A. Morch, “Making Argumentation Serve Design,” Design Rationale Concepts, Techniques, and Use, T. Moran and J. Carroll, eds., pp. 267-293, Lawrence Erlbaum and Assoc., 1996.
[29] P. Giorgini, F. Massacci, J. Mylopoulos, and N. Zannone, “Modeling Security Requirements through Ownership, Permission and Delegation,” Proc. 13th IEEE Int'l Conf. Requirements Eng., pp. 167-176, 2005.
[30] M. Glinz, “Rethinking the Notion of Non-Functional Requirements,” Proc. Third World Congress for Software Quality, vol. II, pp.55-64, 2005.
[31] C.B. Haley, R.C. Laney, and B. Nuseibeh, “Deriving Security Requirements from Crosscutting Threat Descriptions,” Proc. Third Int'l Conf. Aspect-Oriented Software Development, pp. 112-121, 2004.
[32] C.B. Haley, R.C. Laney, J.D. Moffett, and B. Nuseibeh, “The Effect of Trust Assumptions on the Elaboration of Security Requirements,” Proc. 12th Int'l Requirements Eng. Conf., pp. 102-111, 2004.
[33] C.B. Haley, J.D. Moffett, R. Laney, and B. Nuseibeh, “Arguing Security: Validating Security Requirements Using Structured Argumentation,” Proc. Third Symp. Requirements Eng. for Information Security with the 13th Int'l Requirements Eng. Conf., 2005.
[34] C.B. Haley, R.C. Laney, J.D. Moffett, and B. Nuseibeh, “Arguing Satisfaction of Security Requirements,” Integrating Security and Software Eng.: Advances and Future Vision, H. Mouratidis and P.Giorgini, eds., pp. 16-43, Idea Group, 2006.
[35] C.B. Haley, J.D. Moffett, R. Laney, and B. Nuseibeh, “A Framework for Security Requirements Engineering,” Proc. 2006 Software Eng. for Secure Systems Workshop with the 28th Int'l Conf. Software Eng., pp. 35-41, 2006.
[36] C.B. Haley, R.C. Laney, J.D. Moffett, and B. Nuseibeh, “Using Trust Assumptions with Security Requirements,” Requirements Eng. J., vol. 11, no. 2, pp. 138-151, Apr. 2006.
[37] C.L. Heitmeyer, “Applying “Practical” Formal Methods to the Specification and Analysis of Security Properties,” Proc. Int'l Workshop Information Assurance in Computer Networks: Methods, Models, and Architectures for Network Computer Security, pp. 84-89, 2001.
[38] ISO/IEC, “Information Technology—Security Techniques—Evaluation Criteria for IT Security—Part 1: Introduction and General Model,” ISO/IEC, Geneva, Switzerland, Int'l Standard 15408-1, Dec. 1999.
[39] ISO/IEC, “Information Technology—Security Techniques—Evaluation Criteria for IT Security—Part 2: Security Functional Requirements,” ISO/IEC, Geneva, Switzerland, Int'l Standard 15408-2, Dec. 1999.
[40] ISO/IEC, “Information Technology—Security Techniques—Evaluation Criteria for IT Security—Part 3: Security Assurance Requirements,” ISO/IEC, Geneva, Switzerland, Int'l Standard 15408-3, Dec. 1999.
[41] M. Jackson, Software Requirements and Specifications. Addison Wesley, 1995.
[42] M. Jackson, Problem Frames. Addison Wesley, 2001.
[43] E. Jonsson, “An Integrated Framework for Security and Dependability,” Proc. 1998 Workshop New Security Paradigms, pp. 22-29, 1998.
[44] E. Kavakli, “Goal-Oriented Requirements Engineering: A Unifying Framework,” Requirements Eng. J., vol. 6, no. 4, pp. 237-251, Jan. 2002.
[45] T.P. Kelly, “Arguing Safety—A Systematic Approach to Safety Case Management,” D.Phil dissertation, Univ. of York, 1999.
[46] G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques. John Wiley and Sons, 1998.
[47] A. van Lamsweerde, “Goal-Oriented Requirements Engineering: A Guided Tour,” Proc. Fifth IEEE Int'l Symp. Requirements Eng., pp.249-263, 2001.
[48] A. van Lamsweerde, “Elaborating Security Requirements by Construction of Intentional Anti-Models,” Proc.e 26th Int'l Conf. Software Eng., pp. 148-157, 2004.
[49] S. Lautieri, D. Cooper, and D. Jackson, “SafSec: Commonalities Between Safety and Security Assurance,” Constituents of Modern System-Safety Thinking: Proc. 13th Safety-Critical Systems Symp., F.Redmill and T. Anderson, eds., pp. 65-78, 2005.
[50] J. Lee and K.-Y. Lai, “What's in Design Rationale?” Human-Computer Interaction, vol. 6, nos. 3-4, pp. 251-280, 1991.
[51] Y. Lee, J. Lee, and Z. Lee, “Integrating Software Lifecycle Process Standards with Security Engineering,” Computers and Security, vol. 21, no. 4, pp. 345-355, 2002.
[52] N.G. Leveson, “Software Safety: Why, What, and How,” ACM Computing Surveys, vol. 18, no. 2, pp. 125-163, June 1986.
[53] L. Liu, E. Yu, and J. Mylopoulos, “Security and Privacy Requirements Analysis within a Social Setting,” Proc. 11th IEEE Int'l Requirements Eng. Conf., pp. 151-161, 2003.
[54] J. McDermott and C. Fox, “Using Abuse Case Models for Security Requirements Analysis,” Proc. 15th Computer Security Applications Conf., pp. 55-64, 1999.
[55] N.R. Mead, E.D. Hough, and T.R. Stehney II, “Security Quality Requirements Engineering (SQUARE) Methodology,” CMU/SEI, Technical Report CMU/SEI-2005-TR-009, ESC-TR-2005-009, Nov. 2005.
[56] J.D. Moffett, J.G. Hall, A. Coombes, and J.A. McDermid, “A Model for a Causal Logic for Requirements Engineering,” Requirements Eng., vol. 1, no. 1, pp. 27-46, Mar. 1996.
[57] J.D. Moffett, C.B. Haley, and B. Nuseibeh, “Core Security Requirements Artefacts,” Technical Report 2004/23, Dept. of Computing, The Open Univ., June 2004.
[58] H. Mouratidis, P. Giorgini, and G. Manson, “Integrating Security and Systems Engineering: Towards the Modelling of Secure Information Systems,” Proc. 15th Conf. Advanced Information Systems Eng., pp. 63-78, 2003.
[59] J. Mylopoulos, A. Borgida, M. Jarke, and M. Koubarakis, “Telos: Representing Knowledge about Information Systems,” ACM Trans. Information Systems, vol. 8, no. 4, pp. 325-362, Oct. 1990.
[60] J. Mylopoulos, L. Chung, and B. Nixon, “Representing and Using Nonfunctional Requirements: A Process-Oriented Approach,” IEEE Trans. Software Eng., vol. 18, no. 6, pp. 483-497, June 1992.
[61] S.E. Newman and C.C. Marshall, “Pushing Toulmin Too Far: Learning from an Argument Representation Scheme,” Technical Report SSL-92-45, Xerox PARC, 1991.
[62] NIST, An Introduction to Computer Security: The NIST Handbook, Nat'l Inst. of Standards and Technology (NIST), special publication SP 800-12, Oct. 1995.
[63] B. Nuseibeh, “Weaving Together Requirements and Architectures,” Computer, vol. 34, no. 3, pp. 115-117, Mar. 2001.
[64] C.P. Pfleeger and S.L. Pfleeger, Security in Computing. Prentice Hall, 2002.
[65] C. Potts and G. Bruns, “Recording the Reasons for Design Decisions,” Proc. 10th Int'l Conf. Software Eng., pp. 418-427, 1988.
[66] B. Ramesh and V. Dhar, “Supporting Systems Development by Capturing Deliberations during Requirements Engineering,” IEEE Trans. Software Eng., vol. 18, no. 6, pp. 498-510, June 1992.
[67] “Software Assurance: A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software,” version 1.05.245, S.T. Redwine Jr., ed., Dept. of Homeland Security, Aug. 2006.
[68] J. Rushby, “Security Requirements Specifications: How and What,” Proc. Symp. Requirements Eng. for Information Security, 2001.
[69] Senior Officials Group-Information Systems Security, “Information Technology Security Evaluation Criteria (ITSEC),” version1.2, Dept. of Trade and Industry, June 1991.
[70] G. Sindre and A.L. Opdahl, “Eliciting Security Requirements by Misuse Cases,” Proc. 37th Int'l Conf. Technology of Object-Oriented Languages and Systems, pp. 120-131, 2000.
[71] E.H. Spafford, “The Internet Worm Program: An Analysis,” ACM SIGCOMM Computer Comm. Rev., vol. 19, no. 1, pp. 17-57, Jan. 1989.
[72] “The Chaos Report,” research report, Standish Group, 1995.
[73] “Chaos: A Recipe for Success,” research report, Standish Group, 1999.
[74] “Extreme Chaos,” research report, Standish Group, 2001.
[75] O. Tettero, D.J. Out, H.M. Franken, and J. Schot, “Information Security Embedded in the Design of Telematics Systems,” Computers and Security, vol. 16, no. 2, pp. 145-164, 1997.
[76] K. Thompson, “Reflections on Trusting Trust,” Comm. ACM, vol. 27, no. 8, pp. 761-763, Aug. 1984.
[77] S.E. Toulmin, The Uses of Argument. Cambridge Univ. Press, 1958.
[78] S.E. Toulmin, R.D. Rieke, and A. Janik, An Introduction to Reasoning. Macmillan, 1979.
[79] J. Viega, T. Kohno, and B. Potter, “Trust (and Mistrust) in Secure Applications,” Comm. ACM, vol. 44, no. 2, pp. 31-36, Feb. 2001.
[80] J. Viega and G. McGraw, Building Secure Software: How to Avoid Security Problems the Right Way. Addison Wesley, 2002.
[81] M. Watson, UK ADS-B in a Radar Environment, EUROCONTROL, 2006, presentation slides, http://www.eurocontrol.int/cascade/gallery/ content/public/documents/Presentations/ Session %202%20-%20Trials%20and%20Implementations Watson%20-%20UK%20ADS-B%20in%20a%20radar%20environment.pdf , 2007.
[82] L. Zhuang, F. Zhou, and J.D. Tygar, “Keyboard Acoustic Emanations Revisited,” Proc. 12th ACM Conf. Computer and Comm. Security, pp. 373-382, 2005.

Index Terms:
Software/Software Engineering, Requirements/Specifications, Security
Citation:
Charles Haley, Robin Laney, Jonathan Moffett, Bashar Nuseibeh, "Security Requirements Engineering: A Framework for Representation and Analysis," IEEE Transactions on Software Engineering, vol. 34, no. 1, pp. 133-153, Jan. 2008, doi:10.1109/TSE.2007.70754
Usage of this product signifies your acceptance of the Terms of Use.