Identifying Security Requirements Using the Security Quality Requirements Engineering (SQUARE) Method

In this chapter, we describe general issues in developing security requirements, methods that have been useful, and a method (SQUARE) that can be used for eliciting, analyzing, and documenting security requirements for software systems. SQUARE, which was developed by the CERT Program at Carnegie Mellon University’s Software Engineering Institute, provides a systematic approach to security requirements engineering. SQUARE has been used on a number of client projects by Carnegie Mellon student teams, prototype tools have been developed, and research is ongoing to improve this promising method. 701 E. Chocolate Avenue, Suite 200, Hershey PA 17033, USA Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com ITB13356 INFORMATION SCIENCE PUBLISHING This chapter appears in the book, Integrating Security and Software Engineering: Advances and Future Visions edited by Haralambos Mouratidis and Paolo Giorgini © 2007, Idea Group Inc. The SQUARE Method 45 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. ThE IMpoRTAnCE of REQUIREMEnTS EngInEERIng It is well recognized in industry that requirements engineering is critical to the success of any major development project. Several authoritative studies have shown that requirements engineering defects cost 10 to 200 times as much to correct once fielded than if they were detected during requirements development. Other studies have shown that reworking requirements defects on most software development projects costs 40 to 50% of total project effort, and the percentage of defects originating during requirements engineering is estimated at more than 50%. The total percentage of project budget due to requirements defects is 25 to 40%. A recent study found that the return on investment when security analysis and secure engineering practices are introduced early in the development cycle ranges from 12 to 21%, with the highest rate of return occurring when the analysis is performed during application design (Soo Hoo, Sudbury, & Jaquith, 2001). The National Institute of Standards and Technology (NIST) reports that software that is faulty in security and reliability costs the economy $59.5 billion annually in breakdowns and repairs (NIST, 2002). The costs of poor security requirements show that even a small improvement in this area would provide a high value. By the time that an application is fielded and in its operational environment, it is very difficult and expensive to significantly improve its security. Requirements problems are the number one cause of why projects: • Are significantly over budget • Are significantly past schedule • Have significantly reduced scope • Deliver poor-quality applications • Are not significantly used once delivered • Are cancelled Requirements engineering typically suffers from the following major problems: • Requirements identification typically does not include all relevant stakeholders and does not use the most modern or efficient techniques. • Requirements analysis typically is either not performed at all (identified requirements are directly specified without any analysis or modeling) or analysis is restricted to functional requirements, ignoring quality requirements, other non-functional requirements, and architecture, design, implementation, and testing constraints. • Requirements specification is typically haphazard, with specified requirements being ambiguous, incomplete (e.g., non-functional requirements are often missing), inconsistent, not cohesive, infeasible, obsolete, neither testable 24 more pages are available in the full version of this document, which may be purchased using the "Add to Cart" button on the publisher's webpage: www.igi-global.com/chapter/identifying-security-requirementsusing-security/24050