SQUARE

Principal Investigator: Nancy R. Mead

Note: The SQUARE tool is now available. Learn about the tool and download the files.

Problem Addressed

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 are detected during requirements development [1,2]. A more recent vendor example indicates that it is 100 times cheaper to fix security flaws at requirements time than after a product has been released [3]. 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 [4], and the percentage of defects originating during requirements engineering is estimated at more than 50 percent [5]. The total percentage of project budget due to requirements defects is 25 to 40 percent [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

• projects are significantly over budget, past schedule, have significantly reduced scope, or are cancelled
• development teams deliver poor-quality applications
• products are not significantly used once delivered

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 the 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 get 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.

Top

Research Approach

TThe 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 SQUARE could likely be generalized to any large-scale design project, it was designed for use with information technology systems.

The SQUARE process involves the interaction of a team of requirements engineers and the stakeholders of an IT 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, assets are identified and business and security goals are outlined. Third, 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 spent 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.

The methodology is most effective and accurate when conducted with a team of requirements engineers with security expertise and the stakeholders of the project. 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 Assets and 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.

The SQUARE process is described in a technical report [8] and is suitable for incorporation into development practice. SQUARE is described in the Requirements Engineering section of the Build Security In website [9] and in three books [10, 11, 12]. CERT is currently continuing research and application of the process and is working to develop a robust tool to support each stage of the methodology.

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.

Top

Expected Benefits

When 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.

Top

2008 Accomplishments

In conjunction with CyLab, the SQUARE prototype tool, workshop, tutorial, and educational materials were developed and released. A set of invited talks on SQUARE was delivered at the National Institute for Informatics (NII) in Tokyo. The initial version of SQUARE-Lite, a five-step process extracted from SQUARE, was applied in a client organization. We developed an initial privacy requirements engineering capability and integrated it into the SQUARE prototype tool. A technical note on SQUARE [13] discusses ways of integrating SQUARE into standard life-cycle processes. Papers on life-cycle process integration were also presented at conferences [14, 15].

Top

2009 Plans

We are working with a Carnegie Mellon University Master of Software Engineering Studio Team to develop a robust tool to replace the current prototype tool. We plan to integrate privacy considerations more fully with SQUARE and to extend SQUARE for use in acquisition. We will continue to publish and to take advantage of client opportunities to apply SQUARE in the field.

Top

Instructional Materials

Top

References

[2] McConnell, Steve. “From the Editor - An Ounce of Prevention.” IEEE Software 18, 3 (May 2001): 5-7.

[3] Meftah, B. “Business Software Assurance: Identifying and Reducing Software Risk in the Enterprise.” https://buildsecurityin.us-cert.gov/swa/downloads/Meftah.pdf

[4] Jones, C., ed. Tutorial: Programming Productivity: Issues for the Eighties, 2nd ed. Los Angeles, CA: IEEE Computer Society Press, 1986.

[5] Wiegers, Karl E. Inspecting Requirements (column). StickyMinds, July 30, 2001. < a href="http://www.stickyminds.com">http://www.stickyminds.com.

[6] Leffingwell, D. & Widrig, D. Managing Software Technology– A Unified Approach. Boston, MA: Addison-Wesley, 1999.

[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., & Stehney, T. Security Quality Requirements Engineering (SQUARE) Methodology (CMU/SEI- 2005-TR-009). Software Engineering Institute, Carnegie Mellon University, 2005. http://www.sei.cmu.edu /publications/documents/05.reports/05tr009.html

[9] Department of Homeland Secuirty. Build Security In. https://buildsecurityin.us-cert.gov/ (2009).

[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] Allen, J., Barnum, S., Ellison, R., McGraw, G., & Mead, N. R. Software Security Engineering: A Guide for Project Managers. Addison-Wesley Professional, 2008 (ISBN-13: 978-0-321-50917-8).

[13] Mead, N. R., Viswanathan,V., Padmanabhan, D., & Raveendran, A. Incorporating Security Quality Requirements Engineering (SQUARE) into Standard Life-Cycle Models (CMU/SEI-2008-TN-006). Software Engineering Institute, Carnegie Mellon University, 2008. http://www.sei.cmu.edu /publications/documents/08.reports/08tn006.html

[14] Mead, N. R., Viswanathan, V., & Padmanabhan, D. “Incorporating Security Requirements Engineering into the Dynamic Systems Development Method,” 949–954. COMPSAC (International Computer Software and Applications Conference) 2008, IWSSE Workshop (International Workshop on Security and Software Engineering), July 28, 2008, Turku, Finland. IEEE Computer Society, 2008.

[15] Mead, N. R., Viswanathan, V., & Zhan, J. “Incorporating Security Requirements Engineering into the Rational Unified Process,” 537–542. 2008 International Conference on Information Security and Assurance (ISA), Busan, Korea, April 26–28, 2008. IEEE Computer Society, 2008.

Top