 |
|  |
SQUARERequirements Engineering for Improved System SecurityPrincipal Investigator: Nancy R. Mead Problem AddressedResearch Approach Expected Benefits 2007 Accomplishments 2008 Plans Instructional Materials References Problem AddressedIt 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 are detected during requirements development [1,2]. Other studies have shown that reworking requirements, design, and code defects on most software development projects costs 40 to 50 percent of total project effort [3], and the percentage of defects originating during requirements engineering is estimated at more than 50 percent [4]. The total percentage of project budget due to requirements defects is 25 to 40 percent [5].An earlier 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 percent, with the highest rate of return occurring when the analysis is performed during application design [6]. The National Institute of Standards and Technology (NIST) reports that software faulty in security and reliability costs the economy $59.5 billion annually in breakdowns and repairs [7]. The costs of poor security requirements make apparent that even a small improvement in this area will provide a high value. By the time an application is fielded and in its operational environment, it is very difficult and expensive to significantly improve its security. Requirements problems are among the top causes of why
These days we have the further problem that the environment in which we do requirements engineering has changed, resulting in an added element of complexity. Software development occurs in a dynamic environment that changes while projects are still in development, with the result that requirements are in flux from the beginning. This can be due to conflicts between stakeholder groups, rapidly evolving markets, the impact of tradeoff decisions, and so on. When security requirements are considered at all during the system life cycle, they tend to be general lists of security features such as password protection, firewalls, virus detection tools, and the like. These are, in fact, not security requirements at all but rather implementation mechanisms that are intended to satisfy unstated requirements, such as authenticated access. As a result, security requirements that are specific to a system and that provide for protection of essential services and assets are often neglected. In addition, the attacker perspective is not considered, with the result that security requirements, when they exist, are likely to be incomplete. We believe that a systematic approach to security requirements engineering will help to avoid the problem of generic lists of features and to take into account the attacker perspective. In reviewing requirements documents, we typically find that security requirements, when they exist, are in a section by themselves and have been copied from a generic set of security requirements. The requirements elicitation and analysis that is needed to define a better set of security requirements seldom takes place. Much requirements engineering research and practice has addressed the capabilities that the system will provide. So while significant attention is given to the functionality of the system from the user's perspective, little attention is given to what the system should not do. In one discussion on requirements prioritization for a specific large system, ease of use was assigned a higher priority than security requirements. Security requirements were in the lower half of the prioritized requirements. This occurred in part because the only security requirements that were considered had to do with access control. Research ApproachThe Software Engineering Institute's CERT Program has developed a methodology to help organizations build security into the early stages of the production life cycle. The Security Quality Requirements Engineering (SQUARE) methodology consists of nine steps that generate a final deliverable of categorized and prioritized security requirements. Although the SQUARE methodology could likely be generalized to any large-scale design project, it was designed for use with information technology systems. The SQUARE process is most effective when conducted with a team of requirements engineers with security expertise and the stakeholders of the project. It begins with the requirements engineering team and project stakeholders agreeing on technical definitions that serve as a baseline for all future communication. Next, business and security goals are outlined. Then artifacts and documentation are created, which are necessary for a full understanding of the relevant system. A structured risk assessment determines the likelihood and impact of possible threats to the system. Following this work, the requirements engineering team determines the best method for eliciting initial security requirements from stakeholders. This determination depends on several factors, including the stakeholders involved, the expertise of the requirements engineering team, and the size and complexity of the project. Once a method has been established, the participants rely on artifacts and risk assessment results to elicit an initial set of security requirements. Two subsequent stages are devoted to categorizing and prioritizing these requirements for management's use in making tradeoff decisions. Finally, an inspection stage is included to ensure the consistency and accuracy of the security requirements that have been generated. SQUARE's nine discrete steps are outlined in Table 1. Each step identifies the necessary inputs, major participants, suggested techniques, and final output. Generally, the output of each step serves as the sequential input to the ensuing steps, though some steps may be performed in parallel. For instance, it might be more efficient for the requirements engineering team to perform Step 2 (Identify Security Goals) and Step 3 (Develop Artifacts) simultaneously, since to some extent they are independent activities. The output of both steps, however, is required for Step 4 (Perform Risk Assessment). In principle, Steps 1-4 are actually activities that precede security requirements engineering but are necessary to ensure that it is successful.
Table 1: Security Requirements Elicitation and Analysis Process
The SQUARE process has been baselined. Several case studies with real-world clients have shown that the methodology holds good promise for incorporation into industry practice, and we are working informally with additional industry clients. The current model is summarized in Table 1. CERT is currently continuing research and application of the process and is working in parallel to create a CASE tool to support each stage of the methodology. Expected BenefitsWhen SQUARE is applied, the user should expect to have identified, documented, and inspected relevant security requirements for the system or software that is being developed. SQUARE may be more suited to a system under development or one undergoing major modification than one that has already been fielded, although it has been used both ways.2007 AccomplishmentsThe SQUARE baseline was defined in a technical report [8]. SQUARE was also described in the requirements engineering section of the Build Security In web site [9], and in two books [10, 11]. In conjunction with Carnegie Mellon University's CyLab, the prototype tool was completed and released. Also in conjunction with Cylab, workshop, tutorial, and educational materials on SQUARE were produced. The tutorial was presented at the CyLab subscribers' meeting. A Distinguished Lecture on SQUARE was delivered at Nortel. The initial version of SQUARE-Lite, a four-step process extracted from SQUARE, was developed and is being applied in a client organization. A technical note on SQUARE [12] discussed ways of comparing SQUARE with other security requirements engineering methods. Papers on the cost/benefit aspects of SQUARE and on security requirements elicitation were also published [13, 14].2008 PlansWe are working with two client organizations to incorporate SQUARE into their development processes. We will seek to work with a commercial vendor to further develop the tool as a commercial product. SQUARE will be further documented in a chapter of a book based on the Build Security In web site. The book is titled Secure Software Engineering: A Guide for Project Managers and will be published by Addison-Wesley in the first half of 2008.Instructional MaterialsWorkshop, tutorial, and academic educational materials on SQUARE are available for download.References[1] Boehm, B. W. & Papaccio, P. N. “Understanding and Controlling Software Costs.” IEEE Transactions on Software Engineering SE-4, 10 (Oct.1988): 1462-77.[2] McConnell, Steve. “From the Editor - An Ounce of Prevention.” IEEE Software 18, 3 (May 2001): 5-7. [3] Jones, C., ed. Tutorial: Programming Productivity: Issues for the Eighties, 2nd ed. Los Angeles, CA: IEEE Computer Society Press, 1986. [4] Wiegers, Karl E. Inspecting Requirements (column). StickyMinds, July 30, 2001. < a href="http://www.stickyminds.com">http://www.stickyminds.com. [5] Leffingwell, D. & Widrig, D. Managing Software Technology– A Unified Approach. Boston, MA: Addison-Wesley, 1999. [6] Soo Hoo, Kevin; Sudbury, Andrew W.; & Jaquith, Andrew R. “Tangible ROI through Secure Software Engineering.” Secure Business Quarterly 1, 2 (2001). [7] National Institute of Standards and Technology. “Software Errors Cost U.S. Economy $59.5 Billion Annually” (NIST 2002- 10). http://www.nist.gov/public_affairs/releases/n02-10.htm (2002). [8] Mead, N. R. & Hough, E. D. “Security Requirements Engineering for Software Systems: Case Studies in Support of Software Engineering Education,” 149-156. 19th Conference on Software Engineering Education & Training. Turtle Bay, HI, April 19-21, 2006. New York, NY: IEEE Computer Society, 2006. [9] Department of Homeland Secuirty. Build Security In. https://buildsecurityin.us-cert.gov/ (2008). [10] Mead, N. R.; Davis, N.; Dougherty, C.; & Mead, R. Ch. 8, “Recommended Practices,” 275-308. Secure Coding in C and C++. Robert Seacord. Upper Saddle River, NJ: Addison Wesley, 2005. [11] Mead, N. R. Ch. 3, “Identifying Security Requirements Using the SQUARE Method,” 44-69. Integrating Security and Software Engineering: Advances and Future Visions, H. Mouratidis & P. Giorgini. Hershey, PA: Idea Group, 2006, (ISBN: 1-59904-147-2). [12] Mead, N. R.; Hough, E.; & Stehney, T. Security Quality Requirements Engineering (SQUARE) Methodology (CMU/SEI-2005-TR-009). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005. http://www.sei.cmu.edu/publications/documents/05.reports/05tr009.html. [13] Caulkins, J., Hough, E. D., Mead, N. R., & Osman, H. "Optimizing Investments in Security Countermeasures: A Practical Tool for Fixed Budgets." IEEE Security & Privacy 5, 5 (September/October 2007). [14] Mead, N. R. "Experiences in Eliciting Security Requirements." CrossTalk 19, 12 (December 2006): 14-19. Disclaimers and copyright information
Last updated January 17, 2008. |
